Điểm PageSpeed cao không luôn có nghĩa website nhanh với mọi khách truy cập. Để đo đáng tin cậy, hãy bắt đầu bằng PageSpeed Insights, phân biệt Lab Data và Field Data, dùng Lighthouse hoặc Chrome DevTools để tìm nguyên nhân, rồi kiểm tra lại cả chỉ số lẫn chức năng.
Quy trình này phù hợp với người mới và không yêu cầu cài hàng loạt công cụ. Bạn cần một URL công khai, trình duyệt Chrome nếu muốn dùng DevTools, và quyền truy cập Search Console chỉ khi muốn theo dõi dữ liệu của website. Mục tiêu không phải là đạt điểm 100, mà là giúp nội dung chính xuất hiện nhanh, trang phản hồi tốt, bố cục ổn định và giảm tài nguyên không cần thiết.
Ba khía cạnh cần đo trước khi tối ưu
Hiệu suất website không chỉ là thời gian tải toàn bộ trang. Hãy bắt đầu bằng ba câu hỏi:
- Nội dung chính đã xuất hiện chưa? Largest Contentful Paint (LCP) phản ánh thời điểm phần tử nội dung lớn nhất trong vùng nhìn ban đầu hiển thị.
- Trang có phản hồi khi người dùng bấm hoặc nhập liệu không? Interaction to Next Paint (INP) phản ánh độ trễ phản hồi của các tương tác.
- Bố cục có bị nhảy không? Cumulative Layout Shift (CLS) phản ánh mức độ ổn định hình ảnh trong quá trình tải.
Theo hướng dẫn Web Vitals, ngưỡng mục tiêu ở bách phân vị thứ 75 là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. Đây là mục tiêu đánh giá phần lớn người dùng, không phải cam kết mọi thiết bị đều đạt cùng kết quả; các ngưỡng có thể được cập nhật theo tài liệu chính thức (theo web.dev).
Hiệu suất cũng cần được xem cùng khả năng sử dụng. Website nhanh nhưng chữ khó đọc, nút bấm quá nhỏ hoặc bố cục khó dùng trên màn hình cảm ứng vẫn tạo ra trải nghiệm kém. Xem thêm cách kiểm tra website trên điện thoại.
Chọn công cụ theo câu hỏi cần trả lời
| Công cụ | Dữ liệu chính | Nên dùng khi nào? | Giới hạn |
|---|---|---|---|
| PageSpeed Insights | Lighthouse và dữ liệu người dùng thật từ CrUX | Kiểm tra nhanh một URL công khai | Field Data có thể chưa có với website mới hoặc ít dữ liệu |
| Lighthouse | Kiểm tra mô phỏng về Performance, Accessibility, Best Practices và SEO | Tìm cơ hội tối ưu trong môi trường tương đối kiểm soát | Kết quả thay đổi theo thiết bị, mạng, trình duyệt và tình trạng máy |
| Chrome DevTools Performance | Dấu vết CPU, mạng, kết xuất, long task và tương tác | Chẩn đoán nguyên nhân sâu hơn | Cần biết cách đọc bản ghi và nên kiểm tra nhiều tình huống |
| CrUX hoặc Search Console | Dữ liệu trải nghiệm từ người dùng thật | Đánh giá website đang hoạt động ngoài thực tế | Không phải URL hoặc website nào cũng đủ dữ liệu |
PageSpeed Insights: điểm bắt đầu
Mở PageSpeed Insights, nhập URL đầy đủ của trang cần kiểm tra và xem riêng hai phần Field Data và Lab Data. PageSpeed Insights kết hợp dữ liệu người dùng thật từ Chrome User Experience Report (CrUX) với phân tích mô phỏng do Lighthouse thực hiện (theo developers.google.com).
- Field Data: cho biết người dùng thật đã trải nghiệm trang như thế nào trong giai đoạn dữ liệu được thu thập.
- Lab Data: tái hiện một điều kiện kiểm tra cụ thể để tìm cơ hội tối ưu và chẩn đoán kỹ thuật.
Hai phần cho kết quả khác nhau không nhất thiết là lỗi. Lab Data dùng môi trường mô phỏng, còn Field Data tổng hợp nhiều thiết bị, mạng và bối cảnh. Vì vậy, một trang có điểm Lighthouse cao vẫn có thể khiến một nhóm người dùng gặp LCP hoặc INP kém.
Lighthouse: tìm cơ hội tối ưu
Lighthouse có thể chạy trong PageSpeed Insights, Chrome DevTools, dòng lệnh hoặc dưới dạng mô-đun Node.js. Khi đọc báo cáo, hãy mở chi tiết từng mục thay vì chỉ nhìn điểm tổng. Cảnh báo về ảnh ngoài vùng nhìn, CSS chặn hiển thị hoặc JavaScript làm tăng thời gian xử lý thường hữu ích hơn một điểm số đơn lẻ (theo developer.chrome.com).
Chrome DevTools: xác định nguyên nhân
Trên máy tính có Chrome, mở trang cần kiểm tra ở cửa sổ ẩn danh nếu muốn giảm ảnh hưởng của tiện ích mở rộng. Nhấn F12 hoặc Ctrl + Shift + I trên Windows/Linux, chọn Performance, rồi bấm ghi bản thu. Tải lại trang hoặc thực hiện một thao tác cụ thể như mở menu, tìm kiếm hay gửi biểu mẫu; sau đó dừng bản ghi.
- Main thread: tìm tác vụ dài khiến trình duyệt không kịp phản hồi.
- Network: tìm tài nguyên tải lâu, dung lượng lớn hoặc đến từ quá nhiều miền.
- Rendering và Layout: kiểm tra việc tính toán lại bố cục hoặc vẽ lại quá nhiều.
- Tương tác: thử thao tác thật vì vấn đề INP có thể chỉ xuất hiện sau khi cuộn, mở bộ lọc hoặc nhập dữ liệu.
DevTools cho phép ghi hồ sơ CPU và phân tích điểm nghẽn trong thời gian chạy; Performance Monitor còn hiển thị CPU, bộ nhớ JavaScript, số nút DOM và số lần tính toán bố cục (theo developer.chrome.com).
Quy trình đo và tối ưu có thể lặp lại
1. Chọn URL và ghi đường cơ sở
Chọn ít nhất một URL đại diện cho mỗi loại trang quan trọng: trang chủ hoặc trang đích, bài viết hoặc danh mục, trang sản phẩm hoặc biểu mẫu, và trang có nhiều ảnh, quảng cáo, video hay mã theo dõi.
Ghi ngày kiểm tra, URL, loại thiết bị, LCP, INP, CLS, TTFB, dung lượng tải xuống, số yêu cầu mạng và cảnh báo chính. Đo cùng một URL vài lần trong điều kiện gần tương đương rồi ghi nhận xu hướng thay vì kết luận từ một lần chạy duy nhất.
2. Phân loại nguyên nhân trước khi sửa
| Dấu hiệu | Nguyên nhân cần kiểm tra | Việc đầu tiên nên làm |
|---|---|---|
| LCP cao | Ảnh đầu trang lớn, máy chủ phản hồi chậm, CSS hoặc tài nguyên quan trọng bị trì hoãn | Xác định phần tử LCP, kiểm tra TTFB, kích thước ảnh và tài nguyên chặn hiển thị |
| INP cao | JavaScript chạy lâu, tác vụ dài, quá nhiều trình xử lý sự kiện hoặc mã bên thứ ba | Ghi Performance trace, tìm long task và giảm việc trên main thread |
| CLS cao | Ảnh, quảng cáo, iframe hoặc nội dung động không có kích thước dự kiến | Dành sẵn không gian trước khi tài nguyên tải |
| TTFB cao | Máy chủ, truy vấn cơ sở dữ liệu, bộ nhớ đệm hoặc vị trí máy chủ | Kiểm tra thời gian phản hồi HTML trước khi sửa giao diện |
3. Tối ưu hình ảnh
Xuất ảnh gần với kích thước hiển thị, nén trước khi tải lên và dùng định dạng phù hợp. Với ảnh ngoài vùng nhìn ban đầu, có thể dùng loading="lazy"; không nên trì hoãn ảnh đang tạo ra LCP vì nội dung chính có thể xuất hiện muộn (theo web.dev).
<!-- Ảnh trong vùng nhìn đầu tiên: thay URL và alt bằng dữ liệu thật -->
<img src="hero.webp"
width="1200"
height="630"
alt="Mô tả ngắn cho ảnh đầu trang"
fetchpriority="high">
<!-- Ảnh bên dưới vùng nhìn đầu tiên -->
<img src="bai-viet-1.webp"
width="800"
height="450"
loading="lazy"
alt="Mô tả ngắn cho ảnh">Đoạn mã trên được đặt trong HTML hoặc mẫu giao diện nơi ảnh được xuất ra. Thay hero.webp, bai-viet-1.webp và nội dung alt bằng tài nguyên thật. width và height giúp trình duyệt giữ chỗ, giảm nguy cơ CLS.
4. Giảm JavaScript và tài nguyên bên thứ ba
Kiểm tra thư viện, plugin, quảng cáo, công cụ phân tích, cửa sổ trò chuyện, bản đồ nhúng và tập lệnh A/B testing. Mã bên thứ ba có thể tạo thêm kết nối, tải thêm mã, chiếm thời gian xử lý và trì hoãn hiển thị (theo web.dev).
- Xóa mã không còn dùng thay vì chỉ trì hoãn tất cả.
- Chỉ tải tính năng khi cần, chẳng hạn tải bản đồ sau khi người dùng bấm mở.
- Dùng
defercho tập lệnh không cần chạy trước khi HTML được phân tích. - Không cài hai công cụ cùng chức năng nếu không có lý do rõ ràng.
- Sau khi thay đổi, kiểm tra đăng nhập, biểu mẫu, thanh toán và theo dõi chuyển đổi.
5. Xử lý CSS chặn hiển thị
CSS thường chặn hiển thị vì trình duyệt cần xây dựng CSSOM trước khi tạo cây kết xuất. Hãy loại bỏ CSS không dùng, tách CSS chỉ dành cho trang hoặc thành phần đặc biệt, và gửi CSS thiết yếu sớm (theo web.dev).
Không nên tự động đưa toàn bộ CSS vào nội tuyến. Cách này có thể làm HTML phình to và làm bộ nhớ đệm kém hiệu quả. Hãy so sánh kích thước, thời gian tải và chức năng trước–sau.
6. Kiểm tra máy chủ, bộ nhớ đệm và CDN
Nếu TTFB cao, tối ưu ảnh hoặc JavaScript phía trình duyệt không giải quyết được thời gian chờ máy chủ. Kiểm tra bộ nhớ đệm cho HTML, CSS, JavaScript và ảnh tĩnh; truy vấn cơ sở dữ liệu; tải máy chủ; nén phản hồi; HTTP/2 hoặc HTTP/3; HTTPS; và khoảng cách giữa máy chủ, CDN và nhóm người dùng chính.
Nếu không quản trị máy chủ, hãy gửi các số liệu TTFB, URL và thời điểm kiểm tra cho đơn vị hosting. Trước khi thay đổi bộ nhớ đệm, ghi lại nội dung nào được lưu, thời gian hết hạn và cách xóa cache. Sau khi phát hành, xóa cache theo đúng quy trình rồi kiểm tra lại.
Ví dụ: trang bài viết có LCP cao
Ví dụ giả định: PageSpeed Insights cho thấy LCP kém, CLS ổn; phần tử LCP là ảnh tiêu đề có dung lượng lớn và chỉ được phát hiện sau khi JavaScript chạy.
- Xuất ảnh gần với kích thước hiển thị lớn nhất cần hỗ trợ.
- Chuyển sang định dạng phù hợp và nén ảnh.
- Đưa URL ảnh vào HTML ban đầu thay vì chèn bằng JavaScript.
- Không đặt
loading="lazy"cho ảnh tiêu đề. - Dành sẵn
widthvàheight. - Đo lại cùng URL và loại thiết bị.
Nếu LCP vẫn cao, kiểm tra tiếp TTFB và CSS chặn hiển thị. Không chuyển ngay sang sửa JavaScript nếu bản ghi cho thấy phần lớn thời gian nằm ở máy chủ hoặc quá trình tải ảnh.
Kiểm tra, ghi nhận và rollback sau khi sửa
Trước khi sửa plugin, mã giao diện, cấu hình bộ nhớ đệm hoặc tập lệnh, hãy sao lưu hoặc lưu phiên bản hiện tại và ghi rõ thay đổi. Với website có staging, thử ở staging trước; nếu không có, thay đổi từng nhóm nhỏ vào thời điểm có thể theo dõi lỗi.
- Chạy lại cùng URL bằng công cụ và điều kiện gần tương đương.
- So sánh LCP, INP, CLS, TTFB và dung lượng tải xuống.
- Mở trang trên thiết bị di động thật nếu website phục vụ người dùng di động.
- Thử cuộn, mở menu, gửi biểu mẫu, tìm kiếm, thêm sản phẩm hoặc thanh toán.
- Kiểm tra lỗi JavaScript, ảnh không tải, bố cục bị nhảy và mã theo dõi.
- Nếu lỗi xuất hiện, khôi phục phiên bản hoặc thuộc tính vừa thay đổi, xóa cache theo quy trình của nền tảng, rồi đo và thử lại.
Dữ liệu người dùng thật thường không thay đổi ngay sau khi sửa. CrUX chỉ bao gồm những URL hoặc origin đáp ứng điều kiện dữ liệu nhất định, nên hãy dùng Lab Data để kiểm tra nhanh sau triển khai và theo dõi Field Data theo thời gian (theo developer.chrome.com). Search Console có thể hỗ trợ theo dõi báo cáo Core Web Vitals ở cấp website khi website đã được xác minh và có dữ liệu.
Lỗi người mới thường mắc
- Chỉ nhìn điểm Performance: điểm tổng không thay thế dữ liệu người dùng thật.
- Lazy-load mọi ảnh: ảnh LCP có thể tải muộn.
- Cài thêm plugin mà không đo lại: plugin giảm kích thước ảnh nhưng có thể thêm JavaScript hoặc yêu cầu mạng.
- Xóa mã theo cảnh báo mà không thử chức năng: biểu mẫu, thanh toán hoặc phân tích có thể hỏng.
- Sửa nhiều thứ cùng lúc: khó biết thay đổi nào có tác dụng hoặc gây lỗi.
- Đồng nhất tốc độ với SEO: nội dung, khả năng thu thập dữ liệu, tính hữu ích và khả năng sử dụng vẫn cần đánh giá riêng.
Nếu tối ưu website nội dung, hãy kết hợp kiểm tra tốc độ với hướng dẫn SEO và tối ưu website cho người mới.
Lộ trình tối thiểu
- Chọn ba đến bốn URL đại diện.
- Đo bằng PageSpeed Insights và lưu LCP, INP, CLS, TTFB cùng cảnh báo.
- Đối chiếu Field Data với Lab Data nếu có.
- Ưu tiên một nguyên nhân lớn nhất: ảnh, máy chủ, JavaScript hoặc tài nguyên chặn hiển thị.
- Sửa một nhóm vấn đề, kiểm tra chức năng và đo lại.
- Dùng DevTools khi báo cáo tổng quát chưa đủ rõ.
- Theo dõi CrUX hoặc Search Console sau khi thay đổi ổn định.
Nếu hoàn thành các bước trên, bạn đã có đường cơ sở, nguyên nhân ưu tiên, thay đổi có kiểm soát và bằng chứng để quyết định bước tiếp theo. Không cần theo đuổi điểm số tuyệt đối nếu trải nghiệm thực tế và chức năng của website đã được cải thiện phù hợp.
Nguồn tham khảo
- About PageSpeed Insights — Google for Developers.
- Lighthouse — Chrome for Developers.
- Web Vitals — web.dev.
- Performance panel: Analyze your website’s performance — Chrome DevTools.
- Third-party JavaScript performance — web.dev.
- Browser-level image lazy loading for the web — web.dev.
- Render-blocking CSS — web.dev.
- Overview of CrUX — Chrome for Developers.
