Core Web Vitals là gì? LCP, INP, CLS và cách cải thiện tốc độ website

Ba chỉ số đo trải nghiệm thực tế của người dùng, ngưỡng cần đạt, cách đọc báo cáo cho đúng và những cách cải thiện mà website doanh nghiệp làm được ngay.

Tác giả: Đội ngũ chuyên môn SEOWEBSITE.VNĐăng ngày Cập nhật 11 phút đọc

Bạn đã bao giờ bấm vào một kết quả tìm kiếm, chờ ba bốn giây vẫn chỉ thấy màn hình trắng, rồi bấm nút quay lại để chọn trang khác chưa? Hoặc đang định bấm vào nút "Gọi ngay" thì một tấm ảnh quảng cáo bất ngờ hiện lên đẩy cả trang xuống, khiến bạn bấm nhầm vào chỗ khác? Đó chính là những trải nghiệm mà Core Web Vitals được tạo ra để đo lường.

Core Web Vitals là bộ ba chỉ số do Google đưa ra để đánh giá trải nghiệm người dùng trên một trang web, dựa trên dữ liệu thực tế từ những người đã truy cập trang đó. Bài viết này giải thích từng chỉ số bằng ngôn ngữ dễ hiểu, cách đo cho đúng, và những cách cải thiện mà một website doanh nghiệp có thể áp dụng.

Ba chỉ số và ngưỡng đạt chuẩn

Chỉ sốĐo điều gìTốtCần cải thiệnKém
LCP (Largest Contentful Paint)Thời gian hiển thị phần nội dung lớn nhất trên màn hình đầu≤ 2,5 giây2,5 đến 4 giây> 4 giây
INP (Interaction to Next Paint)Độ trễ từ lúc người dùng thao tác đến khi trang phản hồi trên màn hình≤ 200 ms200 đến 500 ms> 500 ms
CLS (Cumulative Layout Shift)Mức độ xô lệch bố cục bất ngờ trong khi dùng trang≤ 0,10,1 đến 0,25> 0,25

Một trang được xem là đạt khi ít nhất 75% lượt truy cập thực tế nằm trong ngưỡng tốt ở cả ba chỉ số. Con số 75% này có ý nghĩa: Google không nhìn vào trường hợp trung bình hay trường hợp tốt nhất, mà muốn đa số người dùng, kể cả những người dùng điện thoại cũ và mạng chậm, đều có trải nghiệm ổn. Dữ liệu được tính riêng cho điện thoại và máy tính, nên một trang có thể đạt trên máy tính nhưng không đạt trên điện thoại.

LCP: trang có tải nhanh không?

LCP đo thời gian từ lúc người dùng bắt đầu mở trang đến khi phần nội dung lớn nhất trên màn hình đầu hiển thị xong. Trên đa số website doanh nghiệp, phần lớn nhất này là ảnh banner ở đầu trang, đôi khi là đoạn tiêu đề lớn hoặc một khung video.

Lý do Google chọn đo phần lớn nhất thay vì đo lúc trang tải xong hoàn toàn khá hợp lý. Người dùng không cần mọi thứ tải xong mới bắt đầu đọc. Họ chỉ cần thấy nội dung chính xuất hiện để biết mình đã vào đúng chỗ. Một trang hiện tiêu đề và ảnh chính sau 1,5 giây nhưng vẫn tải ngầm vài đoạn mã theo dõi ở cuối thì vẫn cho cảm giác nhanh.

INP: trang có phản hồi ngay khi bấm không?

INP đo độ trễ giữa lúc người dùng tương tác với trang, như bấm nút, chạm vào menu, gõ vào ô nhập liệu, và lúc trang thể hiện phản hồi trên màn hình. Chỉ số này xét toàn bộ các lần tương tác trong suốt quá trình người dùng ở trên trang, rồi lấy một giá trị đại diện cho những lần chậm nhất.

INP chính thức thay thế chỉ số FID cũ kể từ ngày 12 tháng 3 năm 2024. FID chỉ đo lần tương tác đầu tiên và chỉ đo phần chờ trước khi trình duyệt bắt đầu xử lý, nên nhiều website có FID rất đẹp nhưng người dùng vẫn thấy trang ì ạch. INP khắt khe hơn và phản ánh trải nghiệm thật sát hơn.

Ví dụ dễ thấy nhất là menu trên điện thoại. Người dùng chạm vào biểu tượng ba gạch, nếu menu mất gần một giây mới mở ra, họ sẽ chạm thêm lần nữa, rồi menu vừa mở đã đóng lại. Đó là một INP kém, và nó gây khó chịu hơn nhiều so với việc trang tải chậm thêm nửa giây.

CLS: bố cục có bị xô lệch không?

CLS đo mức độ các phần tử trên trang bị dịch chuyển bất ngờ khi người dùng không hề thao tác gì. Tình huống điển hình là bạn đang đọc một đoạn văn thì ảnh phía trên mới tải xong, đẩy đoạn văn xuống dưới và bạn mất chỗ đang đọc. Tệ hơn, bạn định bấm một nút thì nút đó bị đẩy đi và bạn bấm trúng một quảng cáo.

Chỉ số CLS không có đơn vị giây hay mili giây, mà là một con số tính từ diện tích phần bị dịch chuyển và khoảng cách dịch chuyển. Bạn không cần nhớ công thức, chỉ cần biết dưới 0,1 là tốt và mục tiêu tốt nhất là gần bằng 0.

Core Web Vitals ảnh hưởng thứ hạng đến đâu?

Google xác nhận Core Web Vitals là một phần trong các tín hiệu mà hệ thống xếp hạng sử dụng. Nhưng Google cũng nói rõ rằng nội dung phù hợp và hữu ích vẫn quan trọng hơn, và một trang có trải nghiệm chưa hoàn hảo vẫn có thể xếp hạng cao nếu nội dung của nó là tốt nhất cho truy vấn.

Nói cách khác, đạt điểm tốt không tự động đưa trang lên đầu, và điểm chưa tốt cũng không tự động đẩy trang xuống. Tác động của Core Web Vitals lên thứ hạng thường rõ nhất khi các trang cạnh tranh có nội dung tương đương nhau.

Trong thực tế các dự án, chúng tôi thấy tốc độ tác động mạnh nhất lên tỷ lệ chuyển đổi chứ không phải thứ hạng. Một trang chậm khiến một phần khách thoát ra trước khi kịp đọc nội dung hay để lại số điện thoại. Với website bán hàng hay dịch vụ, cải thiện tốc độ thường mang lại thêm đơn hàng từ chính lượng truy cập đang có, trước cả khi thứ hạng thay đổi.

Đo bằng công cụ nào cho đúng?

Có hai loại dữ liệu cần phân biệt rõ, vì nhầm lẫn giữa chúng là nguyên nhân của rất nhiều tranh cãi không cần thiết.

Dữ liệu thực tế được thu thập từ những người dùng Chrome thật đã truy cập trang của bạn, gồm đủ loại điện thoại, mạng 4G, wifi, ở nhiều nơi khác nhau. Đây là dữ liệu Google dùng. Bạn xem nó trong báo cáo Core Web Vitals của Google Search Console, hoặc ở phần trên cùng của PageSpeed Insights nếu trang có đủ lượt truy cập.

Dữ liệu phòng thí nghiệm là kết quả của một lần chạy thử trong điều kiện giả lập, như phần điểm số từ 0 đến 100 trong PageSpeed Insights. Dữ liệu này hữu ích để tìm nguyên nhân và kiểm tra nhanh sau khi sửa, nhưng nó chỉ là một lần thử trên một cấu hình giả định.

Điểm 100/100 trong phần thử nghiệm của PageSpeed Insights không phải mục tiêu. Chúng tôi từng gặp nhiều chủ website trả thêm tiền chỉ để có con số đẹp trong khi dữ liệu thực tế đã đạt từ lâu. Điều quan trọng là dữ liệu thực tế nằm trong ngưỡng tốt.

Ngoài hai công cụ trên, lập trình viên có thể dùng thẻ Performance trong Chrome DevTools để tìm chính xác đoạn mã nào gây chậm. Với website nhỏ chưa đủ lượt truy cập để có dữ liệu thực tế, kết quả thử nghiệm là nguồn tham khảo duy nhất, nhưng nên chạy vài lần và nhìn vào các chỉ số cụ thể thay vì con số điểm tổng.

Lỗi thường gặp và cách sửa

Khi LCP chậm

Nguyên nhân phổ biến nhất là ảnh banner quá nặng. Nhiều website dùng nguyên ảnh chụp từ máy ảnh hoặc ảnh thiết kế xuất ra vài megabyte rồi để trình duyệt tự thu nhỏ. Cách sửa là nén ảnh sang định dạng WebP hoặc AVIF, xuất đúng kích thước cần dùng, và cung cấp nhiều kích thước khác nhau cho điện thoại và máy tính.

Lỗi thứ hai trái ngược với lời khuyên thường nghe: ảnh banner bị đặt chế độ tải chậm. Tải chậm, hay lazy load, rất tốt cho ảnh nằm phía dưới, nhưng nếu áp dụng cho ảnh ở màn hình đầu thì trình duyệt sẽ chờ một lúc mới tải ảnh quan trọng nhất. Nhiều plugin tối ưu trên WordPress tự động bật tải chậm cho mọi ảnh và gây ra đúng lỗi này. Ảnh ở màn hình đầu nên được tải ngay, có thể thêm thuộc tính fetchpriority="high" để báo trình duyệt ưu tiên.

Lỗi thứ ba nằm ở máy chủ. Nếu máy chủ mất hơn một giây chỉ để bắt đầu trả về trang, mọi tối ưu phía sau đều bị kéo chậm theo. Bộ nhớ đệm trang, mạng phân phối nội dung (CDN) và gói hosting có tài nguyên phù hợp là những cách xử lý. Với website ở Việt Nam phục vụ khách Việt Nam, đặt máy chủ trong nước hoặc dùng CDN có điểm phân phối gần cũng giúp giảm độ trễ đáng kể.

Cuối cùng là font chữ. Website tải font từ nhiều nguồn bên ngoài, mỗi font lại tải đủ chín độ đậm, sẽ chậm hơn đáng kể so với website tự lưu font trên máy chủ và chỉ tải những độ đậm thực sự dùng.

Khi INP cao

INP cao thường do trình duyệt bị quá tải bởi mã JavaScript, khiến nó không kịp phản hồi thao tác của người dùng. Thủ phạm quen thuộc trên website doanh nghiệp Việt là quá nhiều mã bên thứ ba cùng chạy: khung chat, nút Zalo, mã theo dõi quảng cáo của ba bốn nền tảng, công cụ ghi lại phiên truy cập, cửa sổ bật lên thu thập email.

Cách xử lý đầu tiên là rà soát và gỡ bỏ những thứ không còn dùng. Rất nhiều website vẫn chạy mã theo dõi của một chiến dịch quảng cáo đã kết thúc từ hai năm trước. Với những mã còn cần, có thể trì hoãn tải sau khi trang đã hiển thị xong. Những hiệu ứng đơn giản như menu trượt, nút cuộn lên đầu trang nên được viết bằng CSS hoặc mã gọn nhẹ thay vì kéo theo cả một thư viện lớn.

Khi CLS cao

Nguyên nhân phổ biến nhất là ảnh và khung quảng cáo không khai báo kích thước. Trình duyệt không biết ảnh cao bao nhiêu nên tạm để khoảng trống bằng 0, khi ảnh tải xong mới đẩy nội dung bên dưới xuống. Cách sửa rất đơn giản: thêm thuộc tính width và height cho mọi ảnh, hoặc dùng thuộc tính CSS aspect-ratio để giữ chỗ trước.

Nguyên nhân thứ hai là thanh thông báo, banner khuyến mãi hay hộp đồng ý cookie được chèn vào đầu trang sau khi trang đã hiển thị. Nên đặt sẵn chỗ cho chúng hoặc hiển thị dạng nổi phía trên nội dung, không đẩy nội dung xuống.

Nguyên nhân thứ ba ít người để ý là font chữ. Khi font chính tải xong và thay thế font tạm, kích thước chữ thay đổi khiến các dòng nhảy lên nhảy xuống. Dùng font-display: swap kèm một font dự phòng có kích thước gần giống sẽ giảm hiện tượng này.

Lưu ý riêng cho website WordPress

Phần lớn website doanh nghiệp Việt Nam chạy trên WordPress, và nền tảng này có những vấn đề đặc trưng. Giao diện mua sẵn thường tích hợp rất nhiều tính năng, kéo theo mã CSS và JavaScript cho cả những tính năng bạn không dùng. Các trình dựng trang kéo thả tiện lợi nhưng tạo ra cấu trúc HTML lồng nhau nhiều lớp. Mỗi plugin thêm vào lại mang theo mã riêng của nó.

Lời khuyên của chúng tôi là trước khi cài thêm plugin tối ưu tốc độ, hãy thử gỡ bớt plugin. Một website có bốn mươi plugin thì việc cài thêm plugin thứ bốn mươi mốt để tăng tốc thường chỉ giải quyết được phần ngọn. Sau khi đã tinh gọn, một plugin bộ nhớ đệm tốt kết hợp với hosting phù hợp thường đủ để đạt ngưỡng tốt cho phần lớn website doanh nghiệp.

Quy trình cải thiện khuyến nghị

Thay vì sửa mọi thứ cùng lúc, chúng tôi thường làm theo trình tự sau. Bắt đầu bằng việc mở báo cáo Core Web Vitals trong Search Console để biết nhóm trang nào đang có vấn đề và vấn đề nằm ở chỉ số nào. Chọn một trang tiêu biểu trong nhóm đó, chạy PageSpeed Insights để xem gợi ý cụ thể. Sửa những lỗi có tác động lớn nhất trước, thường là ảnh và mã bên thứ ba. Kiểm tra lại bằng dữ liệu thử nghiệm để chắc chắn đã cải thiện, rồi chờ khoảng bốn tuần để dữ liệu thực tế trong Search Console cập nhật.

Khoảng chờ bốn tuần là điều nhiều người bỏ qua. Dữ liệu thực tế được tổng hợp theo chu kỳ 28 ngày, nên sửa xong hôm nay không có nghĩa ngày mai báo cáo sẽ chuyển sang màu xanh. Search Console có nút "Xác thực bản sửa lỗi" để theo dõi quá trình này.

Tối ưu Core Web Vitals là một hạng mục trong dịch vụ audit và SEO kỹ thuật của chúng tôi. Nếu bạn muốn biết website mình đang chậm ở đâu, hãy gửi địa chỉ website để nhận đánh giá sơ bộ.

Nguồn tham khảo

Về đội ngũ biên soạn

Bài viết do đội ngũ chuyên môn của SEOWEBSITE.VN (Công ty TNHH Dịch vụ AlphaIQ) biên soạn từ kinh nghiệm triển khai SEO cho khách hàng từ năm 2016, đối chiếu với tài liệu chính thức của Google Search Central.

Cách chúng tôi viết và cập nhật nội dung

Bài viết liên quan