Trả lời nhanh: Core Web Vitals là bộ ba chỉ số Google dùng đo cảm giác thật của khách trên trang của bạn, gom từ người dùng Chrome thực trong 28 ngày: LCP, bao lâu thì thấy nội dung chính (đạt: dưới 2,5s); INP, bấm/gõ có phản hồi nhạy không (dưới 200ms); CLS, trang có nhảy layout làm bấm nhầm không (dưới 0,1). Đạt cả ba = tín hiệu xếp hạng thuận lợi + khách bớt bỏ đi. Xem của site mình: Search Console → Core Web Vitals, hoặc PageSpeed Insights phần dữ liệu thực.
Google nói chuyện với chủ site bằng ba chữ viết tắt lạnh lùng, LCP, INP, CLS, nhưng đằng sau là ba câu phàn nàn rất người: "mãi chẳng thấy gì", "bấm mà nó đơ", "đang bấm thì nó nhảy". Bài này dịch từng chỉ số sang trải nghiệm thật, chỉ chỗ xem số của site bạn, và việc gì đáng sửa trước, viết cho chủ web không chuyên kỹ thuật vẫn hành động được.
- LCP <2,5s: khối nội dung lớn nhất màn hình đầu phải hiện sớm, thường là ảnh bìa/tiêu đề
- INP <200ms: mọi cú bấm trong suốt phiên phải có phản hồi tức thì, kẻ thù là JavaScript chen ngang
- CLS <0,1: không để nút/chữ trượt chỗ vì ảnh, quảng cáo, font nạp muộn chen vào
- Số lấy từ người dùng thật 28 ngày, sửa xong phải kiên nhẫn chờ chu kỳ cập nhật
LCP: 'Mãi chẳng thấy gì' - và móng của nó là máy chủ
LCP tính đến lúc khối nội dung lớn nhất trong màn hình đầu hiện xong, ảnh bìa bài viết, ảnh sản phẩm, hay khối tiêu đề. Chuỗi thời gian của nó: máy chủ trả byte đầu (TTFB) → tải HTML → phát hiện ảnh → tải ảnh → vẽ. Ba đòn cải thiện theo thứ tự:
- Móng, TTFB: máy chủ ì thì mọi thứ sau muộn theo; cache + máy tốt + đặt gần khách (cả một bài riêng về TTFB trong cụm này).
- Ảnh LCP được ưu ái: đúng kích cỡ, nén WebP, không lazy-load ảnh đầu trang (lazy-load là cho ảnh dưới màn hình!), thêm fetchpriority=high.
- Đừng bắt khách chờ font/script mới thấy chữ: font-display swap, script nặng đẩy xuống.
INP: 'Bấm mà nó đơ' - kẻ thù là JavaScript tham việc
INP đo độ trễ từ cú bấm/gõ đến khung hình phản hồi kế tiếp, suốt cả phiên, lấy gần-như-tệ-nhất. Thủ phạm quen mặt: trang chất chồng script bên thứ ba (chat, tracking, quảng cáo), mỗi cú bấm phải chờ đám script đó nhả CPU. Đòn hiệu quả cho người không chuyên: kiểm kê và cắt, mở danh sách plugin/mã nhúng, mỗi thứ tự hỏi "có ra đơn không?", không thì gỡ; thứ giữ lại cho nạp trễ sau tương tác đầu. Trang WooCommerce bấm 'thêm giỏ' mà đơ nửa giây là mất tiền thật, INP chính là con số của cảm giác đó.
CLS: 'Đang bấm thì nó nhảy' - bệnh của chỗ trống không đặt trước
Layout nhảy khi phần tử nạp muộn chen vào mà không được chừa chỗ trước: ảnh không khai kích thước, banner quảng cáo, thông báo cookie đẩy cả trang xuống. Thuốc rẻ mà dứt: mọi ảnh có width/height (theme tử tế và trình soạn hiện đại tự làm), khối quảng cáo/embed đặt trong khung kích thước cố định, popup đè lên trang thay vì chen vào dòng chảy. CLS về 0 gần như tuyệt đối khả thi với web bán hàng thường, chỉ số dễ đạt điểm tuyệt đối nhất bộ ba.
Xem số của site mình và nhịp làm việc
- Search Console → Core Web Vitals: nhìn cả site theo nhóm URL, màu đỏ/cam/xanh, bắt đầu từ nhóm đỏ đông trang nhất.
- PageSpeed Insights từng URL: phần "người dùng thực tế" phía trên là số thật; phần điểm Lighthouse bên dưới chỉ là chẩn đoán (bài PSI trong cụm nói kỹ cách đọc không bị lừa).
- Nhịp: sửa một nhóm việc → chờ chu kỳ 28 ngày → nhìn lại. Số thật đổi chậm, đó là bình thường, đừng sửa loạn xạ giữa chừng rồi không biết đòn nào trúng.
Ba chỉ số, ngưỡng và nguyên nhân thường gặp
| Chỉ số | Ngưỡng tốt | Nguyên nhân hay gặp nhất | Việc sửa hiệu quả nhất |
|---|---|---|---|
| Thời gian hiện nội dung chính | dưới 2,5 giây | Máy chủ trả byte đầu chậm, ảnh lớn không tối ưu | Đặt máy chủ gần khách, nén ảnh, dùng định dạng ảnh hiện đại |
| Độ trễ khi người dùng tương tác | dưới 200 ms | Mã chạy trên trình duyệt làm quá nhiều việc | Bỏ bớt tập lệnh không cần, chia nhỏ việc nặng |
| Độ dịch chuyển bố cục | dưới 0,1 | Ảnh và quảng cáo không đặt sẵn chỗ | Khai kích thước cho mọi ảnh và khung nhúng |
Đo trên chính trang của bạn
# Thoi gian may chu tra byte dau tien, nen doi vi day la mong cua chi so dau
curl -o /dev/null -s -w "ket noi %{time_connect}s | byte dau %{time_starttransfer}s | tong %{time_total}s\n" \
https://trangcuaban.vn/
# Do tu nhieu diem, chay lai vai lan de thay dao dong
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "%{time_starttransfer}s\n" https://trangcuaban.vn/
done
# Xem kich thuoc trang tai ve
curl -sI https://trangcuaban.vn/ | grep -i "content-encoding\|content-length"Con số byte đầu tiên là nền móng: nếu nó đã là 1,5 giây thì mọi tối ưu ảnh và mã đều không cứu nổi chỉ số đầu. Với khách hàng Việt Nam, đặt máy chủ trong nước thường cắt được 150 tới 250 ms ngay lập tức.
Nhịp làm việc thực dụng
- Lấy số thật từ người dùng thật trong công cụ quản trị tìm kiếm, không chỉ chạy công cụ đo trong phòng thí nghiệm. Hai loại số này thường khác nhau khá xa.
- Sửa theo thứ tự tác động: thời gian máy chủ phản hồi trước, rồi ảnh, rồi mã chạy trên trình duyệt.
- Sửa một thứ mỗi lần và đo lại, để biết cái gì có tác dụng.
- Xem lại số mỗi tháng, vì thêm một công cụ theo dõi hay một khung nhúng mới là số tụt lại.
Một điều cần nói rõ: các chỉ số này ảnh hưởng tới thứ hạng nhưng ở mức nhỏ so với chất lượng nội dung. Đừng bỏ ba tháng để tối ưu từ mức khá lên mức rất tốt trong khi nội dung chưa trả lời đúng câu hỏi người dùng.
Câu hỏi thường gặp
Không đạt Core Web Vitals có bị Google phạt không?
Không có 'án phạt', nó là một trong nhiều tín hiệu xếp hạng, sức nặng vừa phải. Nhưng tác động gián tiếp rất thật: trang ì làm khách thoát, tỷ lệ chuyển đổi rơi, cái giá đó lớn hơn chuyện thứ hạng.
Site tôi ít khách, không có dữ liệu thì đo kiểu gì?
CrUX cần đủ mẫu; site nhỏ dựa vào lab (Lighthouse) + tự đo TTFB. Chuẩn đơn giản: TTFB dưới 200ms, ảnh nén tử tế, ít script rác, ba thứ đó đạt thì khi có traffic, số thật thường tự đẹp.
Ba chỉ số nên ưu tiên cái nào trước?
Nhìn màu trong Search Console, đỏ đâu sửa đó. Nếu cùng đỏ: LCP trước (ảnh hưởng cảm nhận đầu tiên và thường dính lỗi máy chủ dễ sửa nhất), rồi INP, CLS thường nhanh gọn cuối cùng.
Thuê VPS xịn có tự đạt Core Web Vitals không?
Máy tốt lo được phần móng (TTFB → LCP), phần nặng ký nhất nhưng không phải tất cả: ảnh, script, layout vẫn là việc trên trang. Công thức đủ: nền nhanh + trang gọn.
