Tốc độ website và Core Web Vitals: đo cái gì, sửa cái gì

Google công bố rõ ba chỉ số dùng để đánh giá trải nghiệm trang, gọi là Core Web Vitals. Chúng đo được, so sánh được, và bạn tự kiểm tra được trong năm phút.

Bài này giải thích ba chỉ số đó bằng ngôn ngữ thường, và quan trọng hơn: khi một chỉ số xấu thì thực tế phải sửa cái gì.

Đo trước đã

Vào PageSpeed Insights của Google, dán URL của bạn, chọn tab Mobile — không phải Desktop. Google xếp hạng theo bản mobile, nên chỉ số desktop gần như không có ý nghĩa.

Chú ý phần ở trên cùng: nếu website bạn có đủ lượt truy cập, Google hiển thị dữ liệu người dùng thật trong 28 ngày qua. Đó là số Google dùng, không phải điểm mô phỏng ở dưới. Nếu chỉ có phần mô phỏng, website bạn chưa đủ lưu lượng — vẫn dùng được để sửa lỗi, nhưng đừng coi là số thật.

Ba chỉ số

LCP — Largest Contentful Paint

Nó đo gì: thời gian tới lúc phần tử lớn nhất trong màn hình đầu hiện ra. Thường là ảnh banner hoặc tiêu đề lớn.

Ngưỡng: dưới 2,5 giây là tốt. Trên 4 giây là kém.

Nguyên nhân phổ biến, theo thứ tự hay gặp:

1. Ảnh banner quá nặng. Đây là nguyên nhân số một, chiếm phần lớn các trường hợp. Ảnh 3MB làm LCP không thể tốt.
2. Ảnh banner được tải bằng JavaScript. Trình duyệt phải chạy JS mới biết cần tải ảnh, nên mất thêm một vòng.
3. Server chậm. Nếu thời gian tới byte đầu tiên đã trên 1 giây thì mọi thứ sau đó đều muộn.
4. Font chặn hiển thị chữ. Tiêu đề không hiện ra cho tới khi font tải xong.

Sửa gì: nén ảnh banner xuống dưới 200KB ở định dạng WebP, khai báo chiều rộng và chiều cao, và đặt thuộc tính ưu tiên tải cho đúng ảnh đó. Ba việc này giải quyết phần lớn trường hợp.

INP — Interaction to Next Paint

Nó đo gì: khi khách bấm hoặc gõ, mất bao lâu để trang phản hồi. Chỉ số này đã thay thế FID từ năm 2024.

Ngưỡng: dưới 200 mili giây là tốt. Trên 500 là kém.

Nguyên nhân phổ biến: quá nhiều JavaScript chạy cùng lúc. Thường tới từ ba nguồn: mã theo dõi quảng cáo, plugin chat, và các thư viện hiệu ứng.

Sửa gì: đếm số mã theo dõi đang chạy trên trang. Nhiều website có Google Analytics, Google Ads, Facebook Pixel, TikTok Pixel và một chatbot cùng lúc — năm thứ, và thường chỉ hai thứ được dùng thật. Bỏ những cái không ai xem báo cáo.

CLS — Cumulative Layout Shift

Nó đo gì: nội dung nhảy bao nhiêu trong lúc tải. Đây là chỉ số khách cảm nhận rõ nhất — bạn định bấm một nút, ảnh tải xong, nút nhảy xuống, bạn bấm vào cái khác.

Ngưỡng: dưới 0,1 là tốt. Trên 0,25 là kém.

Nguyên nhân phổ biến, và đây là chỉ số dễ sửa nhất:

1. Ảnh không khai báo kích thước. Trình duyệt không biết chừa chỗ bao nhiêu, nên khi ảnh tải xong nó đẩy mọi thứ xuống.
2. Banner hoặc thông báo chèn vào đầu trang sau khi tải.
3. Font thay thế có kích cỡ khác font thật, làm chữ đổi chiều cao khi font tải xong.

Sửa gì: khai báo width và height cho mọi ảnh. Riêng việc này thường đưa CLS về mức tốt.

Thứ tự nên sửa

Nếu cả ba đều kém, sửa theo thứ tự này — đây là thứ tự theo tỷ lệ công sức trên kết quả:

1. Nén ảnh và khai báo kích thước. Ảnh hưởng cả LCP và CLS, và là việc dễ nhất.
2. Bỏ mã theo dõi không dùng. Ảnh hưởng INP, mất mười phút.
3. Kiểm tra thời gian phản hồi server. Nếu trên 600ms, đổi hosting rẻ hơn mọi việc tối ưu khác.
4. Xem lại font. Giới hạn còn một hoặc hai font, tự host thay vì gọi từ Google Fonts.

Một điều cần nói thẳng

Core Web Vitals là tín hiệu xếp hạng, nhưng là tín hiệu nhẹ. Một trang nội dung tốt và chậm vẫn xếp trên một trang nội dung kém và nhanh.

Lý do thật để quan tâm không phải Google — mà là khách. Ở Việt Nam phần lớn khách vào bằng 4G, và một trang mất năm giây trên 4G bị đóng trước khi hiện ra. Bạn mất khách đó dù xếp hạng thế nào.

Cách chúng tôi xử lý phần này

Mọi mẫu chúng tôi bán được đo trên mạng 4G mô phỏng trước khi phát hành, với ảnh xuất WebP nhiều kích thước, kích thước khai báo sẵn, font tự host, và ảnh đầu trang được đặt ưu tiên tải.

Bạn có thể tự kiểm tra: lấy URL bất kỳ trong phần demo của chúng tôi, dán vào PageSpeed Insights, chọn Mobile. Nếu có mẫu nào không đạt, nhắn Zalo cho chúng tôi biết — chúng tôi sửa và phát hành bản cập nhật, miễn phí, vì cập nhật là trọn đời.