Tốc độ website ảnh hưởng thế nào đến doanh thu: cách đo và cải thiện Core Web Vitals

Website chậm làm mất khách là điều nhiều người tin, nhưng ít người biết nó mất bao nhiêu, đo thế nào, và sửa gì trước. Phần lớn con số "chậm 1 giây mất 7% doanh thu" lưu hành trên mạng không có nguồn rõ, hoặc đến từ các nghiên cứu cũ của nhà cung cấp.

Bài này trình bày bằng chứng đã công bố về tốc độ và doanh thu cùng giới hạn của từng nghiên cứu, 3 chỉ số Core Web Vitals và ngưỡng của chúng, cách đo đúng bằng dữ liệu thực địa, và danh sách sửa theo từng chỉ số.

Nguồn chính là web.dev, tài liệu Google Search Central, HTTP Archive Web Almanac 2025, tài liệu Next.js và các nghiên cứu điển hình của Google, đọc ngày 21/10/2026.

Click Star đã có bài về website chuyển đổi trông như thế nào và về tư duy SEO. Bài này đi vào tốc độ và Core Web Vitals. Cần nói thẳng: mọi nghiên cứu điển hình dưới đây đều do Google đăng, viết cùng nhà quảng cáo, chọn lọc từ thành công và chủ yếu là thương hiệu lớn.

Điểm chính

• Core Web Vitals có 3 chỉ số. LCP (tốc độ hiển thị nội dung chính) tốt khi không quá 2,5 giây, INP (độ phản hồi khi bấm) tốt khi không quá 200 mili giây, CLS (độ ổn định bố cục) tốt khi không quá 0,1. Một trang đạt khi phân vị 75 của lượt truy cập đạt cả 3.
• INP thay FID thành chỉ số chính thức ngày 12/3/2024, và 3 chỉ số cùng ngưỡng không đổi từ đó. Click Star không tìm thấy nguồn của Google cho các "thay đổi năm 2026" mà một số blog nêu.
• Bằng chứng về doanh thu: nghiên cứu của Deloitte cho Google (2020) ghi nhận cải thiện 0,1 giây gắn với tỷ lệ chuyển đổi bán lẻ cao hơn 8,4%, nhưng là quan sát, không phải thử nghiệm. Chỉ Vodafone và Rakuten 24 là thử nghiệm đối chứng.
• Google nói trải nghiệm trang không phải một tín hiệu đơn lẻ, và CWV không bảo đảm thứ hạng. Lập luận kinh doanh nên dựa vào hành vi khách, không dựa vào xếp hạng.
• Theo Web Almanac 2025, chỉ 48% website trên di động đạt cả 3 chỉ số (56% trên máy tính), và LCP trên di động yếu nhất (62%).
• Hãy đo bằng dữ liệu thực địa (CrUX 28 ngày, phân vị 75), dùng dữ liệu phòng thí nghiệm để gỡ lỗi, và sửa LCP trước.

Core Web Vitals là gì

Theo web.dev (cập nhật 31/10/2024), Core Web Vitals gồm 3 chỉ số. LCP (Largest Contentful Paint) đo thời gian hiển thị phần nội dung lớn nhất, tốt khi không quá 2,5 giây. INP (Interaction to Next Paint) đo độ trễ khi người dùng bấm hoặc gõ, tốt khi không quá 200 mili giây.

CLS (Cumulative Layout Shift) đo độ xê dịch bố cục bất ngờ, tốt khi không quá 0,1.

Ngưỡng kém là LCP trên 4 giây, INP trên 500 mili giây và CLS trên 0,25; khoảng giữa là cần cải thiện (web.dev, 7/5/2025). Cùng một ngưỡng cho di động và máy tính, nhưng được đặt chủ yếu theo khả năng của di động. Một trang đạt khi phân vị 75 của các lượt tải đạt cả 3 chỉ số, tách riêng di động và máy tính.

Phân vị 75 nghĩa là 3 trong 4 lượt truy cập đạt ngưỡng. web.dev nói đây là cách cân bằng giữa việc đa số lượt đạt mục tiêu và việc các ngoại lệ không làm lệch kết quả.

INP thay FID thành chỉ số chính thức ngày 12/3/2024. Ghi chú phát hành của CrUX mới nhất (13/10/2026) chỉ thêm các biến thể thử nghiệm cho LCP, INP và CLS có tính các lần chuyển trang trong ứng dụng một trang (SPA). Click Star không tìm thấy nguồn của Google cho các bài blog nói rằng năm 2026 có thay đổi cách tính hay tăng trọng số xếp hạng.

Tốc độ ảnh hưởng thế nào đến doanh thu

Deloitte cho Google, "Milliseconds Make Millions" (web.dev, 24/6/2020). Nghiên cứu theo dõi 37 thương hiệu ở châu Âu và Mỹ với hơn 30 triệu phiên trên di động trong 30 ngày cuối năm 2019, không có thiết kế lại giao diện.

Cải thiện 0,1 giây trên 4 chỉ số gắn với: bán lẻ có tỷ lệ chuyển đổi cao hơn 8,4% và chi tiêu cao hơn 9,2%; du lịch có số đặt chỗ cao hơn 10%; tạo khách tiềm năng có tỷ lệ sang bước gửi biểu mẫu cao hơn 21,6%.

Giới hạn: đây là quan sát (tương quan), không phải thử nghiệm A/B, do Google đặt hàng. Hiệu ứng chỉ xuất hiện khi mọi trang trong hành trình cải thiện, và các chỉ số tốc độ được dùng nay một phần đã lỗi thời.

Vodafone (web.dev, 17/3/2021). Thử nghiệm A/B 50/50 trên một trang đích quảng cáo, khoảng 100.000 lượt nhấp. LCP thực tế cải thiện 31% (5,7 giây so với 8,3 giây), doanh số tăng 8%, tỷ lệ khách tiềm năng trên lượt truy cập tăng 15% và tỷ lệ giỏ trên lượt truy cập tăng 11%.

Thay đổi gồm hiển thị phía máy chủ, giảm mã JavaScript chặn hiển thị và tối ưu ảnh.

Giới hạn: không nêu thời gian chạy, ý nghĩa thống kê hay số tuyệt đối, và một chỉ số khác (DCL) xấu đi. Đây là nghiên cứu điển hình do chính Vodafone viết.

Rakuten 24 (web.dev, 24/8/2022). Thử nghiệm A/B 50/50 một tháng, khác biệt duy nhất là tối ưu CWV. Doanh thu trên mỗi khách tăng 53,37%, tỷ lệ chuyển đổi tăng 33,13%, giá trị đơn trung bình tăng 15,20% và tỷ lệ thoát giảm 35,12%, với trang tối ưu tải sớm hơn 0,4 giây (1,6 giây so với 2 giây).

Giới hạn: trang không nêu đã tối ưu cụ thể gì, không có cỡ mẫu hay ý nghĩa thống kê.

Renault (web.dev, 8/10/2021). Trên hơn 10 triệu lượt truy cập ở 33 nước, mỗi 1 giây LCP cải thiện đi cùng tỷ lệ thoát thấp hơn 14 điểm và chuyển đổi cao hơn 13%; tỷ lệ khách có LCP dưới 2,5 giây tăng từ 51% lên 73% ở 5 thị trường lớn nhất. Đây không phải thử nghiệm A/B mà là hồi quy trên dữ liệu quan sát, nên chỉ cho thấy tương quan.

Economic Times (web.dev, 21/12/2021). LCP thực tế từ 4,5 giây xuống 2,5 giây và CLS từ 0,25 xuống 0,09; trang nêu "tỷ lệ thoát tốt hơn 43%" nhưng không nêu cách đo và tự mâu thuẫn ở vài nhãn phần trăm. Click Star chỉ dùng các giá trị trước và sau.

Đánh giá của Click Star. Cả 5 là nghiên cứu điển hình do Google đăng cùng nhà quảng cáo, chọn lọc thành công và chủ yếu là thương hiệu lớn. Chỉ 2 trong số đó là thử nghiệm đối chứng. Kết quả không chuyển nguyên sang doanh nghiệp nhỏ, nhưng hướng chung nhất quán: trang nhanh hơn thường đi cùng chuyển đổi cao hơn.

Click Star không dùng con số "53% khách bỏ trang nếu tải quá 3 giây" vì nguồn gốc năm 2016 không đọc được ở trang Google còn sống.

Tốc độ có giúp xếp hạng tìm kiếm không

Theo trang của Google Search Central (10/12/2025), Core Web Vitals phù hợp với điều mà các hệ thống xếp hạng cốt lõi muốn thưởng, và Google khuyến nghị mạnh việc đạt CWV tốt. Trang không nêu trọng số.

Trang về trải nghiệm trang (22/9/2026) nói không có một tín hiệu đơn lẻ nào cho trải nghiệm trang, và Google luôn ưu tiên nội dung liên quan dù trải nghiệm trang kém. Trải nghiệm tốt có thể giúp khi nhiều trang hữu ích cạnh tranh nhau, và điểm CWV từ các công cụ không bảo đảm thứ hạng cao.

Click Star đọc các trang này qua công cụ tóm tắt, nên câu chữ cần được đối chiếu trên trang gốc.

Cách đọc an toàn của Click Star: coi CWV là yếu tố phụ khi xếp hạng, giống tiêu chí phân định khi 2 trang tương đương. Lý do để đầu tư vào tốc độ nên dựa trên hành vi khách, như các nghiên cứu ở trên, không dựa trên xếp hạng.

Cách đo đúng

Dữ liệu thực địa và dữ liệu phòng thí nghiệm. Theo web.dev, hãy ưu tiên dữ liệu thực địa (từ người dùng thật) để quyết định sửa gì, và dùng dữ liệu phòng thí nghiệm để gỡ lỗi. 2 loại khác nhau vì phần tử LCP, bộ nhớ đệm, tương tác của người dùng (với INP) và các xê dịch do cuộn trang.

PageSpeed Insights. Phần thực địa lấy từ CrUX (dữ liệu người dùng Chrome thật) của 28 ngày gần nhất, ở phân vị 75, cập nhật hằng ngày. Nếu một URL thiếu dữ liệu, công cụ dùng dữ liệu của cả tên miền. Trang đạt khi cả LCP, INP và CLS đều tốt.

Phần phòng thí nghiệm do Lighthouse chạy (giả lập điện thoại Moto G4 trên mạng di động): 90 trở lên là tốt, 50 đến 89 là cần cải thiện, dưới 50 là kém. Điểm này dao động giữa các lần chạy và có thể không phản ánh điểm nghẽn thực tế.

Search Console. Báo cáo Core Web Vitals dùng CrUX 28 ngày, tách di động và máy tính, gom các URL thành nhóm và lấy trạng thái chỉ số tệ nhất của nhóm. Báo cáo chỉ gồm một mẫu URL đã lập chỉ mục, phù hợp để thấy xu hướng toàn site. Chức năng "Start Tracking" chạy kiểm chứng 28 ngày sau khi sửa, nên kết quả đầy đủ có thể mất tới khoảng 4 tuần.

Site nhỏ có thể không có dữ liệu CrUX. Khi đó dùng thư viện web-vitals của Google (khoảng 3 KB) để đo trên người dùng thật, với onLCP, onINP và onCLS; bản có phần ghi nguồn cho biết phần tử LCP và mục tiêu của CLS.

Cải thiện từng chỉ số

LCP. Theo web.dev (31/3/2025), thời gian LCP chia thành 4 phần với mục tiêu thô: độ trễ máy chủ (TTFB) khoảng 40%, thời gian tải tài nguyên khoảng 40%, độ trễ bắt đầu tải dưới 10% và độ trễ hiển thị dưới 10%.

Ảnh LCP phải có trong HTML ban đầu; đặt fetchpriority="high" cho 1 đến 2 ảnh có khả năng là LCP, dùng preload nếu ảnh chỉ được gọi từ CSS hoặc JavaScript, và không bao giờ tải lười (lazy-load) ảnh LCP. Dùng ảnh AVIF hoặc WebP đúng kích thước, CDN, bộ nhớ đệm, và giảm chuyển hướng.

CLS. Theo web.dev (7/2/2025): đặt width và height hoặc aspect-ratio cho ảnh và video; chừa chỗ cho quảng cáo, nhúng và iframe bằng min-height; đặt banner hay biểu mẫu chèn thêm ở vị trí thấp hơn hoặc chừa chỗ; với phông chữ dùng font-display và size-adjust; dùng transform cho hoạt ảnh; giữ trang đủ điều kiện cho bộ nhớ đệm lùi tiến (bfcache).

INP. Theo web.dev (2/9/2025), độ trễ bằng tổng độ trễ đầu vào, thời gian xử lý và độ trễ trình bày. Hãy chia nhỏ các tác vụ dài (trên 50 mili giây) bằng scheduler.yield() hoặc setTimeout, giữ hàm xử lý nhẹ và giảm kích thước DOM.

Mã bên thứ ba và phông chữ. Dùng async hoặc defer, kết nối trước chỉ cho nguồn quan trọng, tải lười các nhúng ở dưới màn hình đầu và cân nhắc tự lưu. Tài liệu này khá cũ (2019). Trường hợp Renault nêu việc thu nhỏ container GTM và giảm số phông là một phần thay đổi.

Với phông, web.dev khuyên dùng WOFF2, cắt tập con, tự lưu, giảm số phông và chọn font-display có chủ đích.

Next.js. Website của Click Star dùng Next.js. Tài liệu Next.js nói next/image trả ảnh đúng kích thước ở định dạng hiện đại, tải lười mặc định và tránh CLS nhờ width và height.

Từ Next.js 16, prop priority được coi là lỗi thời để thay bằng preload, và tài liệu nói đa số trường hợp nên dùng loading="eager" hoặc fetchPriority="high". next/font tự lưu phông và không yêu cầu ngoài. next/script có các chiến lược nạp, và nên nạp script bên thứ ba chỉ ở trang cần. Hãy kiểm tra phiên bản Next.js đang dùng trước khi áp dụng.

Bối cảnh Việt Nam

Click Star không tìm thấy tỷ lệ đạt Core Web Vitals riêng cho Việt Nam; việc đó cần truy vấn CrUX theo quốc gia.

Về mạng, theo các báo Việt Nam dẫn chỉ số Ookla Speedtest, tháng 8/2026 tốc độ tải xuống trung vị của di động ở Việt Nam là 219,93 Mbps (thứ 9 thế giới, trung vị toàn cầu 109,05) và băng thông cố định là 301,48 Mbps (thứ 8, trung vị toàn cầu 129,68). Đây là nguồn thứ cấp, dữ liệu do người dùng ứng dụng tự đo, và chỉ là tốc độ tải xuống.

Suy luận của Click Star, không phải số đo: khi mạng nhanh, website chậm thường do trang nặng, quá nhiều JavaScript và thiết bị yếu hơn là do băng thông. Vì vậy hãy kiểm tra bằng dữ liệu thực địa trên di động thật, không chỉ trên máy của đội làm web.

Lộ trình 30 ngày

• Tuần 1: đo hiện trạng bằng PageSpeed Insights (dữ liệu thực địa) và Search Console; ghi LCP, INP, CLS của 5 trang quan trọng nhất trên di động.
• Tuần 2: sửa LCP trước (ảnh chính, phông, bộ nhớ đệm, mã chặn hiển thị) và CLS (kích thước ảnh, chỗ chừa cho nhúng).
• Tuần 3: rà mã bên thứ ba và INP; bỏ script không còn dùng, hoãn nạp phần còn lại.
• Tuần 4: bật theo dõi xác nhận trong Search Console, chờ 28 ngày dữ liệu, so chuyển đổi trước và sau theo từng trang.

Ghi chú: để so chuyển đổi trước và sau, hãy so cùng khoảng thời gian trong tuần và loại bỏ chiến dịch quảng cáo lớn, vì thay đổi tốc độ không phải nguyên nhân duy nhất làm chuyển đổi đổi.

Điều chưa biết

Click Star không có số đo độc lập về mức tăng doanh thu khi cải thiện tốc độ ở doanh nghiệp nhỏ Việt Nam, và các nghiên cứu điển hình đều do Google đăng. Chưa có tỷ lệ đạt CWV theo quốc gia cho Việt Nam. Dữ liệu Ookla lấy qua báo, chưa đọc trên trang gốc.

Câu chữ về xếp hạng của Google được đọc qua công cụ tóm tắt, cần đối chiếu trang gốc. Click Star chưa kiểm hướng dẫn về GTM trong @next/third-parties.

Những sai lầm thường gặp

1. Dùng điểm Lighthouse làm mục tiêu thay vì dữ liệu thực địa ở phân vị 75.
2. Chỉ đo trên máy tính và mạng nhanh của đội làm web, bỏ qua di động thật.
3. Tải lười ảnh LCP, làm chính ảnh quan trọng nhất hiển thị chậm.
4. Không đặt kích thước ảnh và chỗ chừa cho nhúng, gây xê dịch bố cục.
5. Thêm thẻ và script bên thứ ba liên tục mà không rà soát lại.
6. Kỳ vọng một con số tăng doanh thu cố định từ các nghiên cứu điển hình của thương hiệu lớn.
7. Sửa xong rồi kết luận ngay, trong khi dữ liệu thực địa cần tới khoảng 4 tuần mới phản ánh đủ.