Core Web Vitals tháng 3/2026: ngưỡng LCP 2 giây, INP 200ms — website Việt ưu tiên điện thoại di động

Cập nhật: 11/06/2026 — phản ánh bản cập nhật lõi Google tháng 3/2026 và thực tế 70% lưu lượng Việt đến từ di động

Core Web Vitals 2026 là bộ 3 chỉ số Google dùng để đo trải nghiệm thật của người dùng, không phải số đo trong phòng thí nghiệm. Tháng 3/2026, Google siết ngưỡng: LCP từ 2,5 giây xuống 2,0 giây, nâng INP (Interaction to Next Paint) lên ngang LCP, và CLS trở thành tín hiệu xếp hạng chính. Với 70% lượng truy cập Việt đến từ di động, website nào chưa đạt ngưỡng tốt sẽ chịu thiệt hại xếp hạng rõ rệt, bất kể nội dung hay đến đâu.

Core Web Vitals tháng 3/2026 là gì? Ngưỡng mới so với 2024 đến 2025

Trả lời ngắn: Core Web Vitals gồm 3 chỉ số (LCP, INP, CLS) mà Google dùng để đo trải nghiệm thật trên thiết bị người dùng. Tháng 3/2026, Google siết LCP xuống 2,0 giây và nâng INP thành tín hiệu xếp hạng chính thức ngang LCP và CLS. Dữ liệu lấy từ Chrome UX Report (CrUX), đo người dùng thật trong 28 ngày, không phải số đo phòng thí nghiệm (truy cập 2026-06-07).

Trước tháng 3/2026, LCP 2,5 giây vẫn tính là đạt chuẩn. Từ tháng 3/2026, ngưỡng tụt xuống 2,0 giây. Nghĩa là mọi website có LCP từ 2,0 đến 2,5 giây bị xếp xuống nhóm "cần cải thiện" mà không cần thay đổi gì từ phía mình, chỉ vì Google dời cột mốc.

INP (Interaction to Next Paint) không phải là cách đo mới của FID. INP đo toàn bộ vòng đời tương tác: từ lúc người dùng chạm hoặc nhấp, qua quãng xử lý, đến lúc trình duyệt hiển thị phản hồi. FID chỉ đo độ trễ ở lần tương tác đầu tiên, bỏ qua toàn bộ phần xử lý và vẽ giao diện. Hai chỉ số này không thể so sánh ngang nhau, vì INP khắt khe hơn nhiều với website có nhiều JavaScript.

LCP 2,0 giây nghĩa là gì? Khác gì so với ngưỡng 2,5 giây cũ

Phần tử lớn nhất trên trang, thường là ảnh đầu trang, tiêu đề H1, hoặc ảnh đại diện video, phải hiển thị xong trong vòng 2,0 giây kể từ khi bắt đầu điều hướng. Dải phân loại mới:

• Đạt chuẩn: tối đa 2,0 giây
• Cần cải thiện: 2,0 đến 4,0 giây
• Kém: trên 4,0 giây

Ảnh hưởng thực tế: website nhiều ảnh đầu trang không tối ưu, phông chữ hiển thị muộn (FOIT/FOUT), hoặc máy chủ phản hồi chậm sẽ không đạt ngưỡng mới dù trước đây vẫn qua. Cách đo nhanh là dùng PageSpeed Insights với phần dữ liệu thực tế (lấy từ CrUX). Đây là số Google thực sự dùng để xếp hạng, không phải số đo phòng thí nghiệm (truy cập 2026-06-07).

INP là gì? Tại sao thay FID và được nâng lên tín hiệu xếp hạng chính 2026

INP (Interaction to Next Paint) đo độ trễ phản hồi của toàn bộ tương tác: cuộn trang, chạm menu, gõ vào biểu mẫu, nhấp nút. Khác FID cũ vốn chỉ đo lần chạm đầu tiên, INP ghi nhận tương tác tệ nhất trong cả phiên làm việc. Ngưỡng:

• Đạt chuẩn: tối đa 200 mili-giây
• Cần cải thiện: 200 đến 500 mili-giây
• Kém: trên 500 mili-giây

Với website nặng JavaScript (băng chuyền ảnh, biểu mẫu phức tạp, hiệu ứng động chạy theo cuộn), INP là chỉ số dễ không đạt nhất. Mỗi tác vụ dài chặn luồng chính quá 50 mili-giây đều đẩy INP lên. Từ tháng 3/2026, INP được nâng ngang LCP và CLS trong nhóm tín hiệu xếp hạng, không còn là chỉ số phụ nữa.

Tại sao website Việt bị ảnh hưởng nhiều hơn mức bình quân toàn cầu?

70% lượng truy cập Việt Nam đến từ di động (theo We Are Social Digital 2026 Vietnam Report, truy cập 2026-06-07), cao hơn mức bình quân toàn cầu khoảng 60%. Ngưỡng Core Web Vitals trên di động khắt khe hơn vì vi xử lý điện thoại yếu hơn và độ trễ mạng 4G/3G cao hơn. Dữ liệu CrUX Việt Nam: trung vị LCP di động khoảng 3,2 giây, INP khoảng 280 mili-giây. Phần lớn website Việt chưa đạt ngưỡng tốt trên di động ngay cả trước tháng 3/2026.

Cảnh báo quan trọng từ tài liệu chính sách Google: Core Web Vitals trên máy tính bàn đạt không bù được di động không đạt. Google đánh giá theo từng nhóm thiết bị riêng biệt. Máy bàn đạt nhưng di động kém vẫn bị xếp vào nhóm kém ở phía di động, vốn chiếm đa số lượng truy cập.

Core Web Vitals so với E-E-A-T và liên kết trỏ về: thứ tự ưu tiên xếp hạng 2026

Theo tài liệu Google Search Central (truy cập 2026-06-07): Core Web Vitals là yếu tố quyết định khi hai trang đồng điểm, không phải tín hiệu xếp hạng chính. Thứ tự ưu tiên thực tế: mức độ liên quan của nội dung, rồi E-E-A-T, rồi liên kết trỏ về, rồi Core Web Vitals (quyết định khi hai trang gần bằng nhau). Trên AI Overviews và Google AI Mode, Core Web Vitals đóng vai trò ngưỡng lọc. Không đạt ngưỡng tốt sẽ bị loại khỏi nhóm được trích dẫn, dù nội dung tốt.

Lập luận "LCP dưới 2,0 giây tăng xếp hạng X phần trăm" phổ biến trên các trang SEO Việt là diễn giải sai. Core Web Vitals không có hệ số xếp hạng cố định, và không có con số phần trăm nào được Google công bố chính thức.

Bao lâu thì thấy thay đổi xếp hạng sau khi sửa Core Web Vitals?

CrUX cập nhật dữ liệu theo cửa sổ 28 ngày gần nhất. Sửa hôm nay thì cần ít nhất 28 ngày để thấy ngưỡng thay đổi trong CrUX. Báo cáo "Core Web Vitals" trong Google Search Console còn chậm hơn CrUX thêm 3 đến 7 ngày nữa. Hành động đúng: sửa, đo ngay bằng dữ liệu phòng thí nghiệm của PageSpeed Insights (phản hồi tức thì), chờ 28 ngày để dữ liệu thực tế cập nhật, rồi kiểm báo cáo Search Console sau 35 ngày. Cùng quy trình này áp dụng cho bảng kiểm SEO kỹ thuật 30 điểm 2026 — đo mốc nền, sửa, đợi dữ liệu thực tế, rồi xác minh.

Ba chỉ số LCP, INP, CLS: nguyên nhân không đạt phổ biến và cách sửa theo thứ tự ưu tiên

Trả lời ngắn: Ba chỉ số đo ba khía cạnh khác nhau là tốc độ tải, độ phản hồi, và độ ổn định bố cục. Một website có thể không đạt một trong ba mà hai cái kia vẫn đạt. Không có cách sửa chung cho cả ba. Cần rà soát từng chỉ số riêng và sửa theo nguyên nhân gốc, không theo triệu chứng.

LCP không đạt: 4 nguyên nhân phổ biến và thứ tự sửa

Ảnh đầu trang quá nặng là nguyên nhân số một khiến LCP trên 3,0 giây ở website Việt. Ảnh đầu trang 2MB tương đương LCP 4 đến 6 giây trên mạng 4G. Không có lý do kỹ thuật nào để giữ ảnh chưa nén trên bản chạy thật.

Sửa theo thứ tự:

1. Chuyển ảnh đầu trang sang định dạng WebP bằng sharp (sharp input.jpg -o output.webp -q 85). Cách này giảm kích thước tệp đáng kể so với JPEG cùng chất lượng theo phép đo của web.dev về WebP (truy cập 2026-06-07). Đặt loading="eager" fetchpriority="high" cho ảnh đầu trang.
2. Phông chữ hiển thị muộn (FOIT/FOUT). Áp font-display: swap, tải trước phông chữ quan trọng, và tự lưu trữ phông chữ thay vì gọi qua Google Fonts ở tên miền khác. Cách này sửa được cả CLS lẫn LCP.
3. TTFB (thời gian phản hồi đầu tiên của máy chủ) trên 1,0 giây. Bật bộ đệm CDN ở biên (đặt máy chủ tại Singapore hoặc TP.HCM cho lưu lượng Việt), và tối ưu khởi động nguội cho hàm chạy không máy chủ riêng.
4. CSS/JS chặn hiển thị. Đưa phần CSS quan trọng vào nội tuyến, hoãn phần JS không cấp thiết, bỏ JS đồng bộ trong <head> không có defer hoặc async.

Kiểm tra nhanh: mục "Opportunities" của Lighthouse sẽ liệt kê và ước tính thời gian tiết kiệm cho từng việc cần sửa.

INP không đạt: nguồn JavaScript nặng và cách giảm độ trễ tương tác

INP kém thường đến từ tác vụ dài của JavaScript chặn luồng chính. Một tác vụ dài 300 mili-giây tương đương INP tệ ngay cả khi độ trễ đầu vào chỉ 10 mili-giây. Nguyên nhân phổ biến nhất với website Việt:

• Script bên thứ ba (khung chat, công cụ phân tích, công cụ bản đồ nhiệt) thường chiếm phần lớn tác vụ dài. Đây là nguồn ẩn bị bỏ qua nhiều nhất. Tải trễ bằng defer, và cân nhắc Partytown để đẩy sang luồng nền (Web Worker).
• Băng chuyền ảnh hoặc trình chiếu ở đầu trang là lối làm sai kép: vừa hại LCP (nhiều ảnh) vừa hại INP (hiệu ứng lặp vô tận). Bỏ đi, thay bằng một ảnh đầu trang tĩnh.
• Biểu mẫu kiểm tra dữ liệu đồng bộ trên luồng chính. Chuyển phần kiểm tra sang luồng nền (Web Worker), và làm trễ sự kiện gõ phím.
• Hiệu ứng động chạy theo cuộn thiếu tiết chế. Tiết chế requestAnimationFrame ở 16 mili-giây (60 khung hình/giây), hoặc dùng IntersectionObserver thay vì gắn sự kiện cuộn.

Dùng thẻ Performance trong Chrome DevTools để xác định cụ thể các tác vụ dài. Bất kỳ tác vụ nào trên 50 mili-giây đều là ứng viên cần viết lại.

CLS không đạt: bố cục nhảy bất ngờ và cách chừa chỗ trước

CLS trên 0,1 làm trải nghiệm người dùng tệ rõ rệt: phần tử trang nhảy trong khi người dùng đang đọc hoặc nhấp. Nguyên nhân:

• Ảnh không khai báo thuộc tính width hoặc height, nên trình duyệt không chừa chỗ, dẫn đến vẽ lại bố cục khi ảnh tải xong.
• Phông chữ web hoán đổi làm chữ vẽ lại. Tải trước phông chữ, và dùng bộ mô tả size-adjust.
• Quảng cáo hoặc biểu ngữ chèn vào DOM sau lần hiển thị đầu. Chừa sẵn khung chứa với min-height cố định.
• Băng chuyền tự xoay gây đột biến CLS mỗi vài giây.

Di động so với máy tính bàn: lý do chênh lệch và chiến lược đo đúng

Tỷ lệ di động đạt tốt là 64,9% so với máy tính bàn 96,8% (theo HTTP Archive Web Almanac 2025, truy cập 2026-06-07). Lý do: vi xử lý điện thoại tầm trung chậm hơn máy bàn 4 đến 6 lần, nên INP trên di động cao hơn 2 đến 3 lần. Trên mạng 4G/3G ở Việt Nam, trung vị LCP di động cao hơn máy bàn 35 đến 40%. Đây cũng là lý do bảng kiểm thiết kế ưu tiên di động cho 70% lưu lượng Việt là điều kiện tiên quyết trước khi sửa Core Web Vitals.

Chiến lược đo bắt buộc: PageSpeed Insights ở chế độ di động, Lighthouse đặt chế độ di động, và thử trên máy thật. Đừng chỉ dùng nút giả lập trong Chrome DevTools, vì nó không mô phỏng chính xác vi xử lý thật của điện thoại Android tầm trung.

Dữ liệu thực tế (CrUX) so với dữ liệu phòng thí nghiệm: dùng cái nào để quyết định?

• Dữ liệu thực tế (lấy từ CrUX) là dữ liệu người dùng thật, quyết định xếp hạng. Cập nhật theo cửa sổ 28 ngày.
• Dữ liệu phòng thí nghiệm (từ Lighthouse) là môi trường giả lập, dùng để dò lỗi nhanh. Không quyết định xếp hạng.

Quy trình đúng: dùng dữ liệu thực tế để biết hiện trạng (đã đạt chuẩn chưa), rồi dùng dữ liệu phòng thí nghiệm để dò lỗi (tại sao không đạt, cần sửa cái gì).

Lộ trình tối ưu Core Web Vitals 5 bước cho website Việt 2026

Trả lời ngắn: Không tối ưu cả 3 chỉ số cùng lúc. Ưu tiên sửa nhóm kém trước, đích đến là nhóm đạt chuẩn. Đừng đuổi theo nhóm "xuất sắc" vì lợi ích giảm dần rất nhanh (theo phân tích 107.000 trang của Mean.ceo). Mỗi bước có một mốc đo lại để biết nên đi tiếp hay sửa thêm.

Bước 1 (Tuần 1): Đo mốc nền 3 chỉ số trên di động và máy tính bàn

Chạy PageSpeed Insights cho 5 đến 10 trang quan trọng nhất: trang chủ, các trang đích chính, và bài viết nhiều truy cập nhất. Ghi lại dữ liệu phòng thí nghiệm và dữ liệu thực tế CrUX riêng biệt. Phân loại: kém (đỏ) xử lý trước, cần cải thiện (vàng) xử lý sau, đạt chuẩn (xanh) bỏ qua lúc này.

Lưu ý: website mới hoặc ít lưu lượng thường không có dữ liệu thực tế INP trong CrUX. Trường hợp này dùng số giả lập từ Lighthouse.

Bước 2 (Tuần 2 đến 3): Sửa LCP kém, lấy những cải thiện nhanh

Chuyển ảnh đầu trang sang WebP bằng sharp, khai báo rõ width và height, thêm fetchpriority="high" cho ảnh đầu trang. Tải trước phông chữ quan trọng, áp font-display: swap. Đưa phần JS chặn hiển thị xuống cuối <body> và hoãn lại. Đo lại PageSpeed Insights sau mỗi nhóm 5 lần sửa để bảo đảm không vô tình làm tụt số chỗ khác.

Bước 3 (Tuần 3 đến 4): Sửa INP, rà soát và bỏ JavaScript nặng

Rà soát mã lệnh bên thứ ba: bỏ khung chat không dùng, tải trễ công cụ phân tích, tách phần phân tích cấp thiết ra nội tuyến. Bỏ băng chuyền ở đầu trang nếu còn. Làm trễ sự kiện gõ phím, tiết chế bộ xử lý cuộn. Đưa tính toán nặng (sắp xếp hoặc lọc danh sách dài) sang luồng nền (Web Worker).

Bước 4 (Tuần 4 đến 5): Sửa CLS, chừa chỗ cho mọi phần tử động

Khai báo thuộc tính width và height cho mọi <img> và ảnh đại diện <video>. Khung chứa quảng cáo hoặc nội dung nhúng đặt min-height cố định khớp nội dung. Tải trước phông chữ web, dùng bộ mô tả size-adjust. Kiểm tra xáo trộn bố cục bằng thẻ Performance của Chrome DevTools, mục Xáo trộn bố cục.

Bước 5 (Tuần 5 trở đi): Đo lại dữ liệu thực tế sau 28 ngày và giám sát liên tục

Chờ 28 ngày để CrUX cập nhật. Kiểm báo cáo Core Web Vitals trong Google Search Console, xác nhận nhóm URL đã chuyển sang đạt chuẩn. Cài giám sát liên tục bằng thư viện Web Vitals (truy cập 2026-06-07), thu thập INP, LCP, CLS từ người dùng thật mỗi lượt tải trang. Đặt cảnh báo khi chỉ số tụt quá 10% so với mốc nền.

5 sai lầm phổ biến khi tối ưu Core Web Vitals

Trả lời ngắn: Phần lớn sai lầm đến từ đo sai (chỉ đo máy tính bàn, bỏ qua di động) và hiểu sai chỉ số (nhầm FID với INP, tải trễ cả ảnh đầu trang). Sửa đúng thứ tự, đo đúng thiết bị, giám sát liên tục.

1. Tải trễ ảnh đầu trang. Ảnh đầu trang bị đặt tải trễ làm LCP tăng thêm 1 đến 2 giây vì trình duyệt trì hoãn việc tải tài nguyên quan trọng nhất. Ảnh đầu trang phải dùng loading="eager" và fetchpriority="high", ngược với ảnh nằm dưới màn hình đầu vốn nên tải trễ.

2. Chỉ đo máy tính bàn, bỏ qua di động. Google lập chỉ mục ưu tiên di động. Website đạt 95/100 trên máy bàn nhưng 60/100 trên di động thì đang bị đánh giá theo điểm 60. Với lưu lượng Việt đa số là di động, sai lầm này đặc biệt tốn kém.

3. Nhầm INP với FID. FID (First Input Delay) đã bị gỡ khỏi Core Web Vitals từ tháng 3/2024, thay bằng INP. INP đo toàn bộ vòng đời tương tác, khắt khe hơn FID nhiều. Tối ưu FID không bảo đảm INP tốt.

4. Bỏ qua mã lệnh bên thứ ba. Khung chat, công cụ phân tích, công cụ bản đồ nhiệt, và mã quảng cáo thường là nguồn tác vụ dài lớn nhất trên website dùng nhiều công cụ. Không rà soát mã lệnh bên thứ ba thì không bao giờ đạt INP tốt, dù mã tự viết đã tối ưu hoàn toàn.

5. Tối ưu một lần rồi thôi. Core Web Vitals thay đổi theo dữ liệu thực tế của người dùng. Triển khai tính năng mới, thêm mã lệnh mới là LCP hoặc INP có thể tụt ngay. Cần giám sát liên tục qua báo cáo Core Web Vitals trong Google Search Console, thay vì rà soát một lần rồi quên.

HAYWEB tự đo: 3 dữ liệu thật từ hayweb.vn và mục Kiến thức

Trả lời ngắn: HAYWEB áp cùng lộ trình tối ưu cho trang chính hayweb.vn và mục Kiến thức. Dữ liệu PageSpeed Insights và Mozilla Observatory được lưu ảnh chụp từ tháng 5/2026.

• hayweb.vn (trang gốc): Lighthouse di động 99/100, LCP 1,8 giây (đạt ngưỡng tối đa 2,0 giây tháng 3/2026), Mozilla Observatory hạng A+. Đây là minh chứng cho việc hiệu năng và bảo mật có thể song song, không phải đánh đổi. Xem thêm bài hướng dẫn bảo mật website và Mozilla Observatory để hiểu cách triển khai cả hai cùng lúc.
• hayweb.vn/kienthuc (mục Kiến thức): ban đầu LCP 3,0 giây. Sau khi tối ưu lại (chuyển ảnh sang WebP bằng sharp, tải trước phông chữ, bỏ JS chặn hiển thị) thì LCP về 2,0 giây, đúng ngưỡng đạt chuẩn tháng 3/2026.
• Cắt ngang 9 bài viết SEO trên hayweb.vn/kienthuc: trung vị INP khoảng 145 mili-giây trên máy bàn và 210 mili-giây trên di động (dữ liệu thực tế CrUX). Sửa sai vị trí tải trễ và chuyển ảnh sang WebP đem lại cải thiện INP đáng kể so với mốc nền trước khi tối ưu.
• Điểm Mozilla Observatory hạng A+ giữ nguyên qua mọi lần tối ưu, kiểm tra qua điểm cuối observatory-api.mdn.mozilla.net/api/v2/scan. Điểm trên 100 là 100 điểm nền cộng 10 đến 20 điểm thưởng từ tiêu đề bảo mật nâng cao (HSTS preload, CSP strict-dynamic, COOP/COEP).
• Tự lưu trữ phông chữ thay vì gọi Google Fonts ở tên miền khác, sửa CLS đồng thời tránh yêu cầu CSP khác nguồn gốc.
• Độ trễ hàm biên (Edge Function) ở mức phân vị 95 từ 27 giây ban đầu kéo xuống 2,8 giây sau khi tối ưu đường khởi động nguội. Cải thiện ở phía máy chủ không cần nâng phần cứng. Nguyễn Thế Quyền, người sáng lập HAYWEB, đã trực tiếp viết đoạn mã đo khởi động nguội theo từng khu vực để xác định điểm nghẽn thật sự nằm ở khâu nào.

Bảng kiểm nhanh Core Web Vitals

Dùng PageSpeed Insights (dữ liệu thực tế từ CrUX) kết hợp với dữ liệu phòng thí nghiệm của Lighthouse. Dữ liệu thực tế quan trọng hơn vì đó là số Google thực sự dùng để xếp hạng.

1. Chạy PageSpeed Insights trên di động (không phải máy tính bàn), vì Google lập chỉ mục ưu tiên di động và điểm di động mới là số quan trọng.
2. Kiểm tra phần tử LCP được đánh dấu. Nếu là ảnh, xác minh ảnh đã có gợi ý preload trong <head> chưa và đã chuyển WebP chưa.
3. Kiểm tra INP (nếu có dữ liệu thực tế). Website mới hoặc ít lưu lượng thường chưa có dữ liệu thực tế INP, trường hợp này dùng số giả lập.
4. Kiểm tra CLS. Chỉ số này thường bị bỏ qua nhưng CLS trên 0,1 làm trải nghiệm tệ rõ rệt.
5. Xác minh thêm ở chế độ giả lập mạng 3G chậm trong DevTools, gần với điều kiện người dùng di động Việt thực tế nhất.

Về Mozilla Observatory: hayweb.vn đạt A+ 100/100 điểm nền. Các tên miền con kiemtra và kienthuc đạt A+ 110 đến 120 (100 điểm nền cộng 10 đến 20 điểm thưởng từ HSTS preload, CSP strict-dynamic, COOP/COEP). Điểm trên 100 không phải lỗi hiển thị, đó là cơ chế tính điểm thưởng của Observatory phiên bản 2 (điểm cuối: observatory-api.mdn.mozilla.net/api/v2/scan).

Tiêu đề bảo mật và hiệu năng không đánh đổi nhau: bật CSP chặt và HSTS không làm tăng LCP. Đọc thêm bài hướng dẫn bảo mật website và Mozilla Observatory để hiểu cách triển khai cả hai cùng lúc.

Bắt đầu tối ưu Core Web Vitals thế nào sau khi đọc xong bài này?

Core Web Vitals 2026 không phải bảng kiểm làm một lần. Đây là vòng lặp: đo, xác định điểm nghẽn, sửa, xác minh dữ liệu thực tế, rồi lặp lại. Ngưỡng LCP tối đa 2,0 giây và INP tối đa 200 mili-giây không xa vời. HAYWEB đã đạt LCP 1,8 giây trên hayweb.vn với Lighthouse di động 99/100. Lộ trình 5 bước ở trên áp dụng cho mọi nền tảng công nghệ, không kén một khung lập trình nào.

Bước 1: Chạy rà soát miễn phí tại kiem-tra.hayweb.vn. Nhập địa chỉ trang chủ và 1 trang đích chính, xem báo cáo 3 chỉ số LCP, INP, CLS trên di động và máy tính bàn trong 30 giây, không cần đăng ký tài khoản.

Bước 2: Đọc thêm các bài trong cùng cụm SEO kỹ thuật: Tổng quan SEO là gì và tại sao quan trọng · Bảng kiểm SEO kỹ thuật 30 điểm 2026 · Thiết kế ưu tiên di động cho 70% lưu lượng Việt · Bảo mật website và Mozilla Observatory A+.

Bước 3: Đặt lịch tư vấn 30 phút với HAYWEB qua hayweb.vn/contact. Người sáng lập Nguyễn Thế Quyền trả lời trực tiếp, không qua trung gian bán hàng, bàn cụ thể lộ trình tối ưu Core Web Vitals 2026 cho website của bạn, dựa trên dữ liệu PageSpeed Insights thật chứ không phải ước lượng chung.