Nếu bạn đang chạy Ads đều, traffic vẫn có, nhưng tỷ lệ chuyển đổi thấp, khách vào rồi thoát nhanh, hoặc đội sales than “lead kém chất lượng” — rất có thể vấn đề không nằm ở content hay ngân sách, mà nằm ở trải nghiệm trên trang: tải chậm, bấm lag, giao diện nhảy loạn trên mobile.
Core Web Vitals (CWV) là bộ chỉ số Google dùng để đo trải nghiệm người dùng thực tế về:
- tốc độ tải nội dung chính (LCP)
- độ mượt khi tương tác (INP)
- độ ổn định giao diện (CLS) (Google Help)
Điểm quan trọng cho chủ doanh nghiệp: Google nói rõ không có một “tín hiệu page experience” duy nhất. Core Web Vitals được dùng bởi hệ thống xếp hạng, nhưng tối ưu CWV không đảm bảo lên top nếu nội dung không liên quan hoặc không đủ tốt. Ngược lại, trong thị trường cạnh tranh, UX tốt giúp bạn giữ khách, tăng tin tưởng và tăng tỷ lệ chuyển đổi. (Google for Developers)
Xem thêm Gói SEO thử nghiệm 30 ngày – dành cho người chưa từng làm SEO
Core Web Vitals là gì và vì sao chủ doanh nghiệp phải quan tâm?
Hãy hiểu CWV như “sức khỏe vận hành của website”:
- Website tải nhanh → khách thấy “đang hoạt động”, đỡ sốt ruột
- Website bấm mượt → khách dễ đặt lịch/điền form/mua hàng
- Website không nhảy bố cục → khách không bấm nhầm, không khó chịu
Google Search Console (GSC) đo CWV bằng dữ liệu người dùng thật (field data) và gom theo nhóm URL (URL group). Đồng nghĩa: bạn sửa đúng “template” là cải thiện được hàng loạt trang. (Google Help)
Bảng tiêu chuẩn Core Web Vitals (ngưỡng Tốt – Cần cải thiện – Kém)
Dưới đây là ngưỡng mà chính báo cáo Core Web Vitals trong GSC dùng để phân loại:
| Chỉ số | Tốt (Good) | Cần cải thiện | Kém (Poor) |
|---|---|---|---|
| LCP | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| INP | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS | ≤ 0.1 | ≤ 0.25 | > 0.25 |
(Google Help)
Lưu ý quan trọng: GSC hiển thị theo 75% lượt truy cập trong 28 ngày gần nhất cho từng nhóm URL. Vì vậy bạn sửa hôm nay, chưa chắc ngày mai “xanh” ngay trong GSC — cần thời gian dữ liệu tích lũy. (Google Help)
3 chỉ số “sinh tử” (giải thích kiểu chủ doanh nghiệp)
LCP (Largest Contentful Paint): Khách có “thấy nội dung chính” nhanh không?
LCP trông như thế nào trong mắt khách?
- Mở trang dịch vụ mà màn hình trắng/khung trống lâu
- Hình banner/ảnh sản phẩm/khối nội dung lớn hiện chậm
- Khách chưa kịp đọc đã thoát → đặc biệt trên 4G, giờ cao điểm
Vì sao LCP thường “đỏ”?
Ba nhóm nguyên nhân hay nhất:
- Server phản hồi chậm (TTFB cao): hosting yếu, không cache, quá nhiều plugin
- Ảnh/hero quá nặng: banner full HD nhưng không nén, không đúng kích thước
- Render-blocking: CSS/JS chặn hiển thị (thường do theme nặng, nhiều script)
“Quick wins” LCP (chủ doanh nghiệp có thể yêu cầu làm ngay)
- Nén & chuyển ảnh hero sang WebP/AVIF, đúng kích thước thật (đừng tải 3000px rồi hiển thị 900px)
- Bật cache + nếu có điều kiện dùng CDN cho ảnh
- Giảm “đồ trang sức” trên trang: slider, animation, pop-up nặng
Checklist yêu cầu dev/đơn vị làm web (không cần bạn hiểu code)
- Ảnh hero có lazy-load đúng chỗ (hero thường không nên lazy quá mức)
- Có preload hợp lý cho asset quan trọng (ảnh/ font/ CSS critical)
- Giảm plugin/đoạn mã marketing “đè” tốc độ (chat widget, heatmap, tracking trùng lặp)
Xem thêm SEO là gì? Hướng dẫn cơ bản về Search Engine Optimization
INP (Interaction to Next Paint): Website có “bấm là ăn” hay bấm bị lag?
INP là gì, và tại sao 2026 phải quan tâm mạnh?
INP đo độ phản hồi khi người dùng tương tác (click/tap/keyboard) trong suốt phiên truy cập, không chỉ “cú bấm đầu tiên”. INP đã thay FID và trở thành Core Web Vital từ 12/03/2024. (web.dev)
INP tệ gây hại gì cho doanh thu?
- Khách bấm “Đặt lịch / Mua ngay” mà không phản hồi ngay → họ bấm lại, lỗi form, bực
- Trang cuộn giật, gõ form chậm → đặc biệt với mobile đời thấp
- INP tệ rất hay xảy ra trên trang có nhiều script quảng cáo/remarketing
Vì sao INP thường tệ?
- JavaScript quá nhiều (theme/app nặng)
- Main-thread bị “chiếm” bởi tracking/ads/chat widget
- Form/validation xử lý nặng, hoặc gắn quá nhiều sự kiện (event listeners)
Quick wins INP (thường tiết kiệm nhất)
- Rà lại Tag Manager / Pixel: có đang bắn 2–3 pixel trùng không?
- Tắt/bớt các script “nice-to-have” (livechat, heatmap) trên các trang không cần thiết
- Hoãn tải script bên thứ ba (defer/async) theo hành vi (chỉ tải khi người dùng có dấu hiệu tương tác)
Checklist “giao việc” để cải thiện INP
- Giảm JS bundle, tách phần chỉ dùng ở trang cụ thể
- Tối ưu long tasks (các tác vụ > 50ms lặp lại)
- Nếu web app nặng: cân nhắc Web Workers cho tác vụ nặng (dev xử lý)
CLS (Cumulative Layout Shift): Trang có “nhảy khung” làm khách bấm nhầm không?
CLS tệ nhìn như thế nào?
- Bạn đang đọc thì banner/cookie bar hiện lên làm chữ nhảy xuống
- Ảnh chưa tải xong làm layout đổi liên tục
- Nút “Đặt lịch” bị đẩy đi, khách bấm nhầm chỗ khác
Nguyên nhân phổ biến (90% website gặp)
- Ảnh/video/iframe không set kích thước (width/height)
- Ads/banner/popup chèn từ trên xuống sau khi trang đã render
- Font đổi (FOIT/FOUT) làm chữ đổi size → layout dịch chuyển
Quick wins CLS
- Với ảnh/video/iframe: set kích thước cố định hoặc dùng placeholder đúng tỉ lệ
- Dành sẵn “chỗ đậu” cho banner/cookie (reserve space)
- Hạn chế chèn nội dung mới phía trên nội dung đang đọc
Checklist giao việc
- Chuẩn hóa component banner/cookie: không được “đẩy layout”
- Fix template trang dịch vụ/blog (đây là nơi CLS hay xảy ra hàng loạt)
Xem thêm 5 “Lỗ Hổng” Marketing Phổ Biến Khiến Doanh Nghiệp Nhỏ Tại TP.HCM “Đốt Tiền” Vô Ích”
Đo lường đúng (nếu đo sai, bạn sẽ tối ưu sai)
Google Search Console: dữ liệu người dùng thật (quan trọng nhất)
GSC Core Web Vitals:
- Dựa trên field data
- Gom theo URL group
- Chỉ hiển thị khi đủ dữ liệu; nếu ít traffic có thể “No data” (Google Help)
Cách chủ doanh nghiệp nên đọc GSC (không bị ngợp):
- Chọn Mobile trước
- Vào nhóm Poor → xem nhóm URL nào nhiều nhất
- Lấy 3–5 URL “đại diện” (Examples) → gửi dev/đơn vị kỹ thuật xử lý theo template
- Sau khi fix, dùng “Start tracking / Validate fix” trong GSC
GSC còn hiển thị ngưỡng Good/NI/Poor ngay trong tài liệu của họ (rất tiện để bạn yêu cầu đúng mục tiêu). (Google Help)
PageSpeed Insights & Lighthouse: dữ liệu giả lập để tìm “thủ phạm”
PSI/Lighthouse giúp bạn debug “vì sao”:
- ảnh nặng?
- render-blocking?
- JS long tasks?
PSI cũng giải thích cách đánh giá “pass CWV”: thường dựa vào 75th percentile của LCP/INP/CLS ở mức Good (khi đủ dữ liệu). (Google for Developers)
Nguyên tắc cho chủ doanh nghiệp:
- Đừng chạy theo 100/100. Google cũng nói “điểm cao không đảm bảo top” và tối ưu điểm số chỉ để SEO có thể không phải dùng thời gian tốt nhất. (Google for Developers)
- Dùng PSI để “bắt bệnh”, còn KPI chính vẫn là GSC Mobile.
Lộ trình tối ưu cho SME (30 ngày – không cần làm quá phức tạp)
Tuần 1: Chọn đúng trang để tối ưu (đừng tối ưu cả website một lúc)
- Chọn 5 trang tạo doanh thu/lead nhiều nhất: trang dịch vụ, landing, trang sản phẩm
- Trong GSC CWV (Mobile), xem nhóm nào đang Poor
- Chốt 1 bảng theo dõi đơn giản: Trang/Template – LCP – INP – CLS – Người phụ trách – Deadline
Tuần 2: Sprint LCP (tốc độ tải)
- Tối ưu ảnh hero (định dạng, kích thước, nén)
- Bật cache/CDN (nếu có)
- Gỡ bớt plugin/đoạn script làm nặng render
Tuần 3: Sprint INP (mượt tương tác)
- Audit tag/trackers: bỏ trùng, hoãn tải thứ không cần
- Tối ưu JS main-thread, giảm long tasks (dev làm)
- Với form đặt lịch: đơn giản hóa validation, giảm plugin form nặng
Tuần 4: Sprint CLS + Validate
- Set width/height cho ảnh/iframe/ads
- Chuẩn hóa banner/cookie để không làm layout nhảy
- Validate fix trong GSC và theo dõi 2–4 tuần dữ liệu
Những sai lầm “chí mạng” cần tránh
- Chạy theo điểm Lighthouse 100/100 nhưng GSC Mobile vẫn đỏ
- Chỉ tối ưu Desktop, bỏ Mobile (trong khi khách thật thường ở mobile)
- Càng tối ưu càng cài thêm plugin → xung đột + nặng JS
- “Fix tốc độ” bằng cách tắt tính năng quan trọng (form, tracking chuẩn) → đo lường sai, tối ưu sai
Google nhấn mạnh: hãy tập trung vào trải nghiệm tổng thể, không chỉ một khía cạnh. (Google for Developers)
Checklist Audit Core Web Vitals (dành cho chủ doanh nghiệp)
GSC (Field data) – làm mỗi tuần 15 phút
- Mobile → Poor: nhóm URL nào nhiều nhất?
- Nhóm đó đỏ vì LCP/INP/CLS?
- Lấy 3 URL đại diện → gửi dev xử lý theo template
- Sau khi fix: Validate/Start tracking trong GSC (Google Help)
B) PSI/Lighthouse (Lab data) – dùng để tìm nguyên nhân
- Trang dịch vụ chính: ảnh hero có nặng không?
- Có render-blocking CSS/JS không?
- Script bên thứ 3 có quá nhiều không? (Google for Developers)
C) Mục tiêu theo ngưỡng Google
- LCP ≤ 2.5s
- INP ≤ 200ms
- CLS ≤ 0.1 (Google Help)
Kết luận: CWV không phải “mẹo SEO”, mà là “mẹo giữ khách”
Core Web Vitals là cách Google (và người dùng) đánh giá website của bạn có đáng để ở lại không. CWV tốt không tự động giúp bạn đứng #1, nhưng trong môi trường cạnh tranh, nó giúp bạn giữ người dùng, tăng tỷ lệ chuyển đổi, và giảm lãng phí ngân sách ads. (Google for Developers)
Nếu bạn muốn, mình có thể chuyển checklist trên thành mẫu bảng audit 30 ngày (dạng Google Sheet) để bạn giao việc cho dev/agency theo tuần: đo → fix → validate → đo lại.