Tối ưu Core Web Vitals, đưa LCP, INP, CLS về vùng tốt

Web22 tối ưu Core Web Vitals như một dịch vụ ngách trong nhóm bảo trì và vận hành website Web22 đang nhận, tách riêng để đi sâu đúng ba chỉ số kỹ thuật bên dưới, thay vì gộp chung mọi việc tốc độ vào một trang.

Core Web Vitals gồm ba chỉ số phản ánh ba khía cạnh khác nhau của trải nghiệm: tải có nhanh không, bấm có mượt không, bố cục có nhảy lung tung không.

Google chấm dựa trên người dùng Chrome thật, lấy mốc 75% nhanh nhất, nghĩa là phần lớn khách phải thấy trang chạy mượt thì mới được tính đạt. Quan trọng: cả ba chỉ số đều phải “tốt” thì trang mới qua, chỉ cần một cái kém là chưa đạt.

Đây là phần kỹ thuật sâu của dịch vụ tối ưu hiệu năng website.

LCP (Largest Contentful Paint) đo thời gian phần tử lớn nhất trong màn hình đầu hiện ra, thường là ảnh bìa hoặc tiêu đề lớn. Nói nôm na: bao lâu thì khách thấy được “thứ chính” của trang.

• Tốt: dưới 2,5 giây · Cần cải thiện: 2,5–4 giây · Kém: trên 4 giây.

Web22 tối ưu LCP bằng cách: ưu tiên tải sớm ảnh bìa, xuất ảnh định dạng nhẹ đúng kích thước, để phần định kiểu cần thiết hiện trước, và giảm thời gian máy chủ phản hồi (bằng bộ nhớ đệm và mạng phân phối). Đây thường là chỉ số dễ cải thiện rõ nhất.

INP (Interaction to Next Paint) đo độ trễ từ lúc khách bấm, chạm hay gõ đến khi giao diện phản hồi. Đây là chỉ số thay thế cho FID cũ kể từ tháng 3 năm 2024, nhiều nơi ở Việt Nam vẫn nhắc FID là đã lỗi thời. INP khó đạt hơn FID vì nó soi toàn bộ tương tác trong cả phiên, không chỉ lần đầu.

• Tốt: dưới 200 mili-giây · Cần cải thiện: 200–500 mili-giây · Kém: trên 500 mili-giây.

Web bị INP kém thường vì JavaScript chạy quá nặng làm nghẽn lúc khách bấm. Web22 sửa bằng cách chia nhỏ các tác vụ nặng, hoãn và làm nhẹ mã bên thứ ba (như mã chat, quảng cáo, theo dõi), để mỗi cú bấm được phản hồi nhanh. Đây là chỉ số khó nhất hiện nay nên cần làm kỹ.

CLS (Cumulative Layout Shift) đo mức bố cục xê dịch bất ngờ khi tải, kiểu bạn định bấm nút thì trang nhảy một cái làm bấm trượt. Cảm giác này rất khó chịu và hay khiến khách bấm nhầm.

• Tốt: dưới 0,1 · Cần cải thiện: 0,1–0,25 · Kém: trên 0,25.

Web22 sửa CLS bằng cách đặt sẵn kích thước cho mọi ảnh, video và khung nhúng, chừa chỗ cho nội dung tải sau (như quảng cáo, banner), và tải font sao cho chữ không nhảy khi font thật hiện ra. Phần lớn CLS xử lý dứt điểm được.

Đây là điều quyết định nhưng hay bị bỏ qua. Có hai loại dữ liệu:

• Dữ liệu người dùng thật (field), gom từ người dùng Chrome thật trong 28 ngày gần nhất. Đây mới là cái Google dùng để xếp hạng.
• Dữ liệu đo thử (lab), như Lighthouse: máy chạy mô phỏng một lần trong điều kiện cố định, dùng để chẩn đoán và lặp lại được.

Vì vậy một trang đạt điểm Lighthouse cao chót vót vẫn có thể trượt Core Web Vitals của người dùng thật. Và sau khi sửa xong, dữ liệu người dùng thật cũng cập nhật chậm vì nó cuốn theo cửa sổ 28 ngày, đừng sốt ruột khi Search Console chưa đổi ngay. Cách đo và đọc đúng hai loại dữ liệu này được giải thích thêm trong phần audit tốc độ của dịch vụ tối ưu hiệu năng website.

Web22 sửa theo trình tự từ gốc xuống ngọn: giảm độ trễ phản hồi từ máy chủ trước (vì nó ảnh hưởng mọi thứ), rồi tới LCP, rồi INP, cuối cùng là CLS. Sửa khâu thượng nguồn thường kéo theo cải thiện hạ nguồn, nên đi đúng thứ tự đỡ tốn công hơn là nhảy lung tung.

Web22 nhận gói đưa cả ba chỉ số Core Web Vitals về vùng tốt với chi phí từ 2.000.000đ, sửa theo thứ tự gốc trước rồi mới tới LCP, INP, CLS. Mức phí cuối cùng phụ thuộc mức độ nghẽn thật của từng web, Web22 đo và báo giá cụ thể sau khi kiểm tra dữ liệu người dùng thật.

Gói này nằm trong phạm vi hẹp hơn dịch vụ tối ưu hiệu năng website nói chung, nơi Web22 xử lý toàn bộ tốc độ tải trang chứ không chỉ riêng ba chỉ số Core Web Vitals.