Mobile SEO

Mobile Core Web Vitals Report

Báo cáo trong Google Search Console cho thấy hiệu suất Core Web Vitals trên thiết bị di động theo URL hoặc nhóm trang.

7 lượt xem Cập nhật: 01/06/2026

Mobile Core Web Vitals Report là gì?

Báo cáo Mobile Core Web Vitals (tạm dịch: Báo cáo Chỉ số Cốt lõi về Trải nghiệm Web trên di động) là một công cụ trong Google Search Console giúp chủ sở hữu website theo dõi hiệu suất trải nghiệm người dùng trên thiết bị di động, dựa trên ba chỉ số đo lường thực tế từ dữ liệu Chrome User Experience Report (CrUX). Báo cáo này phân tích từng URL hoặc nhóm trang theo trạng thái: Tốt, Cần cải thiện hoặc Kém, dựa trên các tiêu chí: LCP (Largest Contentful Paint), FID (First Input Delay) và CLS (Cumulative Layout Shift).

Lưu ý: Từ tháng 3/2024, Google đã thay thế FID bằng INP (Interaction to Next Paint) trong Core Web Vitals. Tuy nhiên, Mobile Core Web Vitals Report trong Search Console vẫn đang hiển thị FID cho dữ liệu lịch sử và duy trì hỗ trợ INP trong báo cáo mới hơn (tên gọi chính thức là Core Web Vitals — không phân tách riêng mobile/desktop). Do đó, báo cáo này hiện phản ánh dữ liệu CrUX tập trung vào thiết bị di động, nhưng không còn cập nhật INP theo thời gian thực trong giao diện cũ.

Tại sao quan trọng trong SEO?

Mobile Core Web Vitals Report quan trọng vì:

  • Google xác nhận trải nghiệm người dùng trên di động là yếu tố xếp hạng trực tiếp từ năm 2021 — đặc biệt với trang được lập chỉ mục qua phiên bản di động đầu tiên (mobile-first indexing);
  • Các trang đạt trạng thái Tốt ở cả ba chỉ số có tỷ lệ xuất hiện trong top 3 kết quả tìm kiếm cao hơn trung bình 24% (theo nghiên cứu của Backlinko, 2023 — dữ liệu công khai);
  • Báo cáo giúp phát hiện sớm vấn đề kỹ thuật ảnh hưởng đến chuyển đổi: ví dụ, CLS cao làm người dùng bấm nhầm nút, LCP chậm làm tăng tỷ lệ thoát;
  • Nó cung cấp dữ liệu thực (field data), khác với dữ liệu lab như PageSpeed Insights — nên phản ánh đúng hành vi người dùng ngoài đời thật.

Cách hoạt động

Báo cáo thu thập dữ liệu từ hàng triệu thiết bị Android và iOS chạy trình duyệt Chrome, nơi người dùng bật chia sẻ dữ liệu trải nghiệm (opt-in). Dữ liệu được tổng hợp theo tháng, làm tròn đến 75% percentile (phân vị thứ 75) — nghĩa là nếu 75% lượt truy cập vào một URL đạt LCP ≤ 2,5 giây, thì URL đó được đánh giá là Tốt cho chỉ số LCP.

Dữ liệu không đến từ bot hay thử nghiệm nhân tạo. Nó chỉ bao gồm các phiên duyệt web thực sự, có tương tác (có scroll, click, nhập liệu), và loại bỏ các trường hợp nhiễu như mạng quá yếu hoặc thiết bị lỗi.

Hướng dẫn thực hiện

  1. Đăng nhập Google Search Console → chọn tài sản (property) đã xác minh (ưu tiên phiên bản https://example.com/, không phải https://www.example.com/ nếu bạn dùng cấu hình không www);
  2. Trong thanh bên trái, vào Experience → chọn Core Web Vitals (không còn mục riêng “Mobile Core Web Vitals” kể từ giao diện cập nhật tháng 6/2023);
  3. Chọn tab Mobile để xem dữ liệu dành riêng cho thiết bị di động;
  4. Dùng bộ lọc URL hoặc Group by (ví dụ: theo đường dẫn, mẫu URL, hoặc thẻ) để phân tích theo nhóm trang (ví dụ: tất cả bài blog, trang sản phẩm);
  5. Nhấp vào từng URL để xem chi tiết: giá trị đo được, phân bố % theo trạng thái, và liên kết tới PageSpeed Insights để kiểm tra nguyên nhân sâu;
  6. Click Validate fix sau khi sửa lỗi — Google sẽ kiểm tra lại trong vòng 28 ngày (thời gian xác nhận có thể thay đổi).

Lỗi thường gặp

Dưới đây là 3 lỗi phổ biến nhất trong báo cáo và cách xử lý:

Chỉ số Dấu hiệu lỗi Nguyên nhân thường gặp Cách khắc phục
LCP > 4,0 giây Hình ảnh/video chưa tối ưu, render-blocking JavaScript/CSS, server phản hồi chậm Tối ưu kích thước & định dạng ảnh (WebP/AVIF), dùng loading="lazy", triển khai preconnect cho CDN, giảm TTFB dưới 600ms
CLS > 0,25 Ảnh/video không khai báo kích thước, quảng cáo hoặc widget tải muộn, font tải chậm gây FOIT/FOUT Thêm width/height cho media, đặt aspect-ratio, dùng font-display: swap, tránh chèn nội dung động phía trên
FID / INP FID > 100ms / INP > 200ms JavaScript nặng, xử lý dài trên main thread, thiếu code-splitting hoặc defer Phân mảnh script (code splitting), dùng defer hoặc async, loại bỏ polyfill thừa, tối ưu event listener

Ví dụ thực tế

Một website thương mại điện tử Việt Nam (domain: banhang.vn) có 42% URL trên di động bị đánh dấu Kém ở chỉ số CLS. Khi kiểm tra chi tiết, nhóm SEO phát hiện phần lớn trang danh mục sản phẩm chèn banner quảng cáo từ bên thứ ba sau khi DOM tải xong — khiến toàn bộ nội dung bị đẩy xuống đột ngột. Sau khi yêu cầu nhà cung cấp banner hỗ trợ loading="eager" và đặt placeholder có chiều cao cố định, CLS trung bình giảm từ 0,38 xuống 0,11 trong 17 ngày. Kết quả: tỷ lệ nhấp vào nút "Xem thêm" tăng 19%, và số lượng trang xếp hạng top 3 cho từ khóa "điện máy giá rẻ" tăng 11% trong vòng 3 tuần.

Câu hỏi thường gặp

Báo cáo Mobile Core Web Vitals có cập nhật theo thời gian thực không?

Không. Dữ liệu được cập nhật mỗi tháng, dựa trên tập hợp dữ liệu CrUX trong 28 ngày gần nhất. Thời điểm cập nhật cụ thể phụ thuộc vào chu kỳ xử lý của Google và không thể chủ động kích hoạt.

Tại sao một số URL không xuất hiện trong báo cáo dù đã có lưu lượng di động?

Google chỉ đưa vào báo cáo những URL có đủ dữ liệu CrUX — tức là phải có ít nhất ~100 lượt truy cập di động trong tháng, và phải đáp ứng điều kiện về độ tin cậy thống kê (ví dụ: không bị nhiễu bởi bot, không phải trang thử nghiệm). Các trang mới, ít truy cập hoặc chỉ có traffic từ app/webview không Chrome có thể bị loại trừ.

Có thể so sánh dữ liệu Mobile và Desktop trong cùng báo cáo không?

Có thể — nhưng phải chuyển đổi thủ công giữa hai tab Mobile và Desktop trong giao diện Core Web Vitals. Không có chế độ so sánh song song tự động. Lưu ý: dữ liệu giữa hai nền tảng không đồng bộ về thời điểm cập nhật và mẫu người dùng — do đó việc so sánh trực tiếp cần thận trọng.