Cách đọc báo cáo Lighthouse mà không hoảng

Quy tắc đầu tiên: điểm số không phải là trang web của bạn

Mở một báo cáo Lighthouse lần đầu tiên, bạn sẽ gặp ngay một bức tường đầy con số, các hộp được mã hóa bằng màu và những cảnh báo về những thứ bạn chưa từng nghe tới. Phản ứng tự nhiên là hoảng. Điểm số màu đỏ. Có mười bảy bài kiểm tra thất bại. Chắc chắn trang web đang hỏng?

Có lẽ là không. Lighthouse là một công cụ chẩn đoán, không phải bảng điểm. Điểm số là một benchmark tổng hợp chạy trong điều kiện phòng thí nghiệm—thường trên kết nối bị giới hạn tốc độ, mô phỏng một điện thoại tầm trung từ năm 2017. Nó cho bạn biết trang web hoạt động thế nào trong kịch bản cụ thể đó, chứ không phải người dùng thật trải nghiệm nó ra sao ngoài thực tế.

Điều này quan trọng vì hầu hết các đội ngũ bị ám ảnh bởi điểm số và bỏ lỡ bối cảnh. Điểm 65 có thể hoàn toàn ổn với một ứng dụng web phức tạp có dữ liệu thời gian thực. Điểm 95 vẫn có thể mang lại trải nghiệm kém nếu tối ưu sai thứ. Điểm số là điểm khởi đầu để điều tra, không phải thước đo thành công.

Nên đọc gì trước: Core Web Vitals

Hãy bỏ qua điểm hiệu năng tổng thể. Cuộn xuống phần Metrics và nhìn vào ba con số: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) và Interaction to Next Paint (INP). Đây là Core Web Vitals, và chúng là những chỉ số hiệu năng duy nhất Google dùng làm tín hiệu xếp hạng.

• LCP đo thời gian cần để phần tử hiển thị lớn nhất được render. Mục tiêu: dưới 2,5 giây. Nếu bạn vượt quá 4 giây, người dùng đang phải chờ quá lâu để thấy nội dung có ý nghĩa.
• CLS đo độ ổn định thị giác—trang nhảy dịch bao nhiêu khi tải. Mục tiêu: dưới 0,1. Nếu bạn vượt quá 0,25, người dùng có thể vô tình bấm nhầm vì các nút đã di chuyển.
• INP đo độ phản hồi—trang phản ứng nhanh thế nào với nhấp chuột, chạm và gõ phím. Mục tiêu: dưới 200ms. Nếu bạn vượt quá 500ms, trang web sẽ có cảm giác ì ạch.

Ba chỉ số này có tương quan với sự khó chịu thực tế của người dùng. Hãy sửa chúng trước khi lo bất cứ điều gì khác.

Opportunities và Diagnostics: biết sự khác biệt

Lighthouse chia các phát hiện thành hai nhóm: Opportunities và Diagnostics. Opportunities được xếp hạng theo mức tiết kiệm thời gian ước tính. Diagnostics là ngữ cảnh bổ sung—những thứ có thể là vấn đề, hoặc cũng có thể không.

Hãy bắt đầu với Opportunities. Nếu Lighthouse nói "Eliminate render-blocking resources" có thể tiết kiệm 1,2 giây, đó là một cải thiện cụ thể. Nếu nó nói "Reduce unused JavaScript" có thể tiết kiệm 0,1 giây, việc refactor có lẽ không đáng.

Diagnostics thì khó hơn. "Avoid an excessive DOM size" nghe có vẻ tệ, nhưng nếu CLS của bạn ổn và INP nhanh, một DOM lớn có thể không gây hại cho ai. Diagnostics là manh mối, không phải mệnh lệnh. Hãy điều tra những mục khớp với các chỉ số thực tế của bạn.

Những bài kiểm tra bạn thường có thể bỏ qua

Một số cảnh báo của Lighthouse là dấu tích cũ hoặc quá nghiêm khắc. Dưới đây là những cảnh báo gây hoảng không cần thiết nhiều nhất:

• "Does not use passive listeners to improve scrolling performance" — Đây là một tối ưu hóa rất nhỏ, hiếm khi tạo khác biệt đáng kể. Trừ khi bạn có bằng chứng về cuộn trang bị giật, hãy bỏ qua.
• "Image elements do not have explicit width and height" — Điều này quan trọng với CLS, nhưng chỉ khi hình ảnh gây ra dịch chuyển bố cục. Nếu CLS của bạn đã tốt, đừng refactor chỉ vì bài kiểm tra này.
• "Serve images in next-gen formats" — Đúng, WebP và AVIF nhỏ hơn. Nhưng nếu hình ảnh của bạn đã được tối ưu và LCP nhanh, đây là điều nên có, không phải khủng hoảng.
• "Avoid enormous network payloads" — Lighthouse đánh dấu mọi thứ trên 1,6 MB. Nhưng một trang 2 MB tải nhanh vẫn tốt hơn một trang 500 KB chặn render. Hãy tập trung vào cách các byte được phân phối, không chỉ tổng dung lượng.

Làm gì khi mọi thứ đều đỏ

Nếu điểm Lighthouse của bạn dưới 50 và hầu hết bài kiểm tra đều thất bại, có lẽ bạn đang gặp một trong ba nguyên nhân gốc sau:

1. Font chưa được tối ưu. Web fonts vẫn là cải thiện hiệu năng dễ nhất trên hầu hết trang web. Kiểm tra xem bạn có đang tải sáu độ đậm font trong khi chỉ dùng hai, hoặc gửi WOFF thay vì WOFF2 hay không.
2. CSS và JavaScript chặn render. Nếu First Contentful Paint (FCP) của bạn vượt quá 3 giây, có thứ gì đó đang ngăn trình duyệt vẽ nội dung. Hãy tìm các file CSS lớn hoặc script đồng bộ trong <head>.
3. Hình ảnh quá lớn. Nếu phần tử LCP của bạn là một hình ảnh và nó nặng 4 MB, đó chính là vấn đề. Hãy nén nó, lazy-load hình ảnh bên dưới màn hình đầu tiên và dùng cú pháp hình ảnh responsive.

Sửa một trong các vấn đề này rồi chạy lại Lighthouse. Bạn thường sẽ thấy điểm tăng 20-30 điểm. Sau đó xử lý vấn đề tiếp theo.

Dữ liệu phòng thí nghiệm và dữ liệu thực tế: bước kiểm chứng thực tế

Lighthouse chạy trong phòng thí nghiệm. Nó mô phỏng kết nối chậm và thiết bị chậm, nhưng không thể mô phỏng hành vi người dùng thật—cách mọi người cuộn, họ nhấp vào gì, hay họ có đang dùng Wi-Fi chập chờn không.

Để kiểm chứng thực tế, hãy so sánh kết quả Lighthouse của bạn với dữ liệu thực tế từ Chrome User Experience Report (CrUX). CrUX cho thấy người dùng Chrome thật trải nghiệm trang web của bạn như thế nào trong 28 ngày gần nhất. Nếu Lighthouse nói LCP của bạn là 4 giây nhưng CrUX hiển thị 2 giây, hãy tin CrUX. Nếu cả hai đều xấu, bạn có vấn đề thật sự.

Bạn có thể tìm dữ liệu CrUX trong PageSpeed Insights (phiên bản web của Lighthouse) hoặc trong Google Search Console dưới mục "Core Web Vitals." Nếu có sự lệch nhau, hãy điều tra lý do. Có thể người dùng thật của bạn đang ở trên mạng nhanh hơn. Có thể Lighthouse đang kiểm tra một bản dev build chưa tối ưu.

Khi nào nên chạy lại Lighthouse

Lighthouse có nhiễu. Chạy ba lần liên tiếp, bạn sẽ nhận ba điểm số khác nhau, ngay cả trên cùng một trang. Điều này xảy ra vì hiệu năng luôn biến động—các tiến trình nền, dao động mạng và heuristic của trình duyệt đều ảnh hưởng đến kết quả.

Để có baseline ổn định, hãy chạy Lighthouse ở chế độ ẩn danh với mọi extension bị tắt, hoặc dùng CLI với flag --preset=desktop để có kết quả nhất quán hơn. Chạy ba lần và lấy trung bình điểm số. Nếu bạn thấy dao động mạnh (hơn 10 điểm), có điều gì đó khác đang sai—có thể server chậm, hoặc trang đang tải các tài nguyên khác nhau mỗi lần.

Chạy lại Lighthouse sau mỗi thay đổi đáng kể. Triển khai chiến lược font mới? Kiểm tra LCP. Lazy-load hình ảnh? Kiểm tra CLS. Thêm script bên thứ ba? Kiểm tra INP. Hiệu năng không phải là một lần sửa rồi xong; đó là một ngân sách bạn phải bảo vệ.

Những công cụ giúp bạn hành động theo phát hiện của Lighthouse

Lighthouse cho bạn biết điều gì chậm. Không phải lúc nào nó cũng cho bạn biết cách sửa. Để làm điều đó, bạn cần thêm công cụ:

• WebPageTest cung cấp góc nhìn dạng filmstrip về cách trang tải, từng khung hình một. Rất cần thiết để chẩn đoán vấn đề LCP và CLS.
• Chrome DevTools Performance panel cho bạn thấy chính xác JavaScript nào đang chặn main thread. Dùng nó để tìm nguồn gốc của điểm INP kém.
• Công cụ nén hình ảnh cho phép bạn tối ưu hình ảnh trực tiếp trong trình duyệt, nhanh hơn và riêng tư hơn so với tải lên dịch vụ bên thứ ba. Xử lý hình ảnh phía client là một lợi thế về quyền riêng tư vì hình ảnh của bạn không bao giờ rời khỏi máy.

Lighthouse là điểm khởi đầu. Những công cụ này giúp bạn hoàn tất công việc.

Những điểm chính

• Điểm Lighthouse của bạn là benchmark trong phòng thí nghiệm, không phải thước đo trải nghiệm người dùng ngoài đời thực. Hãy so sánh với dữ liệu thực tế từ CrUX trước khi hoảng.
• Tập trung vào Core Web Vitals (LCP, CLS, INP) trước. Đây là các chỉ số có tương quan với sự khó chịu của người dùng và tác động SEO.
• Ưu tiên Opportunities theo mức tiết kiệm thời gian ước tính. Bỏ qua Diagnostics không khớp với các vấn đề hiệu năng thực tế của bạn.
• Một số bài kiểm tra—như passive listeners hoặc định dạng hình ảnh thế hệ mới—chỉ là tối ưu hóa rất nhỏ. Hãy sửa những vấn đề lớn trước.
• Chạy Lighthouse ba lần và lấy trung bình kết quả. Hiệu năng luôn biến động, và một lần chạy đơn lẻ có thể gây hiểu lầm.

FAQ

Q: Vì sao điểm Lighthouse của tôi thay đổi mỗi lần chạy?
A: Lighthouse đo hiệu năng trong các điều kiện biến động—tốc độ mạng, tải CPU và heuristic của trình duyệt đều ảnh hưởng đến kết quả. Hãy chạy ba lần ở chế độ ẩn danh và lấy trung bình điểm số để có baseline ổn định hơn.

Q: Tôi nên tối ưu cho mobile hay desktop trước?
A: Mobile. Lighthouse mặc định dùng mô phỏng mobile vì phần lớn lưu lượng web là mobile, và thiết bị mobile chậm hơn. Nếu điểm mobile của bạn tốt, điểm desktop thường cũng sẽ ổn.

Q: Điểm Lighthouse của tôi là 95, nhưng trang web vẫn có cảm giác chậm. Có gì sai?
A: Lighthouse đo quá trình tải trang, không phải tính tương tác sau khi tải. Hãy kiểm tra điểm INP và dùng Chrome DevTools Performance panel để phân tích điều gì xảy ra khi người dùng nhấp hoặc cuộn. Bạn có thể có vấn đề JavaScript mà Lighthouse không bắt được.

Q: Tôi có cần điểm 100 hoàn hảo không?
A: Không. Điểm 90+ là xuất sắc. Theo đuổi 100 thường đồng nghĩa với việc tối ưu những thứ không quan trọng với người dùng. Hãy tập trung vào các chỉ số thực—LCP, CLS, INP—và bỏ qua điểm số.

Q: Tôi có thể tin Lighthouse nếu dùng nhiều script bên thứ ba không?
A: Lighthouse sẽ đánh dấu script bên thứ ba là vấn đề, nhưng không phải lúc nào cũng phân biệt được đâu là cần thiết và đâu là không cần thiết. Dùng các bài kiểm tra "Avoid enormous network payloads" và "Reduce JavaScript execution time" để xác định thủ phạm lớn nhất, rồi quyết định liệu chúng có đáng giữ lại không.

Nguồn

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org