TTFB và Core Web Vitals: con số nào ảnh hưởng thứ hạng, con số nào chỉ để báo cáo

Google dùng ba chỉ số Core Web Vitals đo trên người dùng thật (LCP ≤2,5s, INP ≤200ms, CLS ≤0,1 ở phân vị 75), không dùng điểm Lighthouse. TTFB không thuộc bộ ba nhưng là phần đầu của LCP và ảnh hưởng tốc độ Google thu thập site.

Ban biên tập SEO Gốc · 09/11/2026 · 6 phút đọc

Con số tốc độ mà Google dùng trong hệ thống xếp hạng là ba chỉ số Core Web Vitals (bộ chỉ số trải nghiệm trang cốt lõi) đo trên người dùng thật: LCP, INP và CLS. Điểm Lighthouse hay PageSpeed Insights 95 hay 60 không phải yếu tố xếp hạng; đó là phép đo trong phòng thí nghiệm để bạn tìm nguyên nhân. TTFB (thời gian tới byte đầu tiên) cũng không nằm trong bộ ba, nhưng nó là phần đầu của LCP và ảnh hưởng thẳng tới việc Google thu thập site nhanh hay chậm. Ngay cả khi đạt cả ba chỉ số, đừng chờ thứ hạng nhảy vọt: Google nói rõ nội dung phù hợp vẫn thắng, tốc độ tốt giúp ở những trang ngang ngửa nhau và giúp người dùng không bỏ đi.

Ba chỉ số cốt lõi và ngưỡng "tốt"

Chỉ số	Đo cái gì	Tốt	Kém
LCP — hiển thị phần tử lớn nhất	Bao lâu thì khối nội dung lớn nhất trong khung nhìn (thường là ảnh đầu bài hoặc đoạn chữ lớn) hiện ra	≤ 2,5 giây	> 4 giây
INP — phản hồi tương tác	Từ lúc bấm, chạm, gõ phím tới lúc trang vẽ phản hồi, lấy gần mức chậm nhất trong cả lượt xem	≤ 200 ms	> 500 ms
CLS — độ xô lệch bố cục	Nội dung nhảy chỗ bất ngờ khi trang đang tải	≤ 0,1	> 0,25

INP thay FID từ tháng 3/2024. FID chỉ đo độ trễ của lần tương tác đầu tiên nên hầu như site nào cũng đạt; INP xét cả lượt xem, nên nhiều site từng "xanh" chuyển sang "cần cải thiện" chỉ sau một đêm mà không đổi gì.

Ngưỡng được tính ở phân vị thứ 75 của các lượt xem thật, tách riêng di động và máy tính. Nghĩa là 3/4 lượt xem phải đạt ngưỡng; một nửa người dùng có mạng tốt không cứu được phần còn lại dùng điện thoại tầm trung trên 4G yếu.

Dữ liệu thật và dữ liệu phòng thí nghiệm

Google lấy dữ liệu thật từ Chrome của người dùng đồng ý chia sẻ (bộ dữ liệu CrUX). Báo cáo Core Web Vitals trong Search Console và phần "Khám phá trải nghiệm của người dùng thực" ở đầu PageSpeed Insights là dữ liệu này. Phần điểm số tròn bên dưới là Lighthouse chạy giả lập một máy và một đường mạng cố định.

Site ít truy cập thường không có dữ liệu thật: báo cáo Search Console trống. Không có dữ liệu không phải là bị đánh giá kém; nó chỉ có nghĩa chưa đủ mẫu.
Sửa xong hôm nay, dữ liệu thật phản ánh dần trong khoảng 28 ngày vì CrUX tính trên cửa sổ trượt bốn tuần. Đừng kết luận "sửa không có tác dụng" sau ba ngày.
Lighthouse thấp mà dữ liệu thật tốt thì người dùng của bạn vẫn đang ổn; ưu tiên việc khác.

TTFB: con số nằm dưới mọi con số khác

TTFB gồm thời gian phân giải tên miền, bắt tay kết nối, bắt tay TLS và thời gian máy chủ dựng xong trang để gửi byte đầu tiên. Trang mất 1,8 giây chỉ để có byte đầu tiên thì gần như không thể đạt LCP 2,5 giây trên di động. Tài liệu web.dev coi TTFB khoảng 0,8 giây trở xuống là tốt. Công cụ SEO Gốc dùng ngưỡng cảnh báo riêng chặt hơn: dưới 0,6 giây đủ điểm, tới 1,5 giây nửa điểm, trên 1,5 giây không điểm. Đây là ngưỡng của SEO Gốc chứ không phải luật Google, và là một lần đo từ máy đo của SEO Gốc, nên dùng để phát hiện máy chủ chậm rõ rệt, không phải để so lẻ từng trăm mili giây.

TTFB cao còn có hệ quả ngoài người dùng: Google tự điều chỉnh tốc độ thu thập theo sức khỏe máy chủ. Máy chủ trả chậm hoặc trả lỗi 5xx thì Googlebot giảm số lượt tải, bài mới được phát hiện chậm hơn. Với site lớn, đây là chỗ tốc độ ảnh hưởng tới SEO rõ nhất, xem bài ngân sách thu thập.

Nguyên nhân TTFB cao thường gặp ở site Việt

Không có đệm trang. Mỗi lượt xem chạy lại toàn bộ PHP và hàng chục câu truy vấn. Bài viết không đổi theo người xem thì nên được đệm sẵn thành HTML.
Đặt Cloudflare nhưng HTML không được đệm. Mặc định Cloudflare chỉ đệm tệp tĩnh; tiêu đề cf-cache-status: DYNAMIC nghĩa là mọi lượt vẫn chạy về máy chủ gốc. Đi qua thêm một trạm còn có thể chậm hơn đi thẳng, nhất là khi máy gốc ở xa điểm trung chuyển.
Máy chủ dùng chung quá tải. Hàng xóm cùng máy ăn hết CPU, site của bạn chậm theo giờ cao điểm. Đo vài lần ở các giờ khác nhau trước khi đổ lỗi cho mã.
Bot dò mật khẩu. Với WordPress, xmlrpc.php và wp-login.php bị gọi hàng nghìn lần mỗi ngày, mỗi lần dựng cả WordPress. Đọc nhật ký truy cập trước khi nâng cấp máy chủ.
Truy vấn chậm ở trang danh mục, trang chủ "bài nổi bật", widget "xem nhiều".

Sửa từng chỉ số: việc cụ thể

LCP

Ảnh đầu trang không được gắn loading="lazy". Lỗi này gặp rất nhiều sau khi cài plugin "lazy load mọi ảnh": ảnh quan trọng nhất bị trì hoãn tới cuối.
Gắn fetchpriority="high" cho ảnh LCP, phục vụ đúng kích thước theo màn hình bằng srcset, định dạng WebP hoặc AVIF.
Bớt CSS và phông chữ chặn hiển thị: phông chữ tải từ dịch vụ ngoài thêm một tên miền phải kết nối.

CLS

Mọi ảnh, khung video, khung nhúng có width và height (hoặc aspect-ratio trong CSS) để trình duyệt chừa chỗ trước.
Khối quảng cáo, thanh thông báo cookie, dải "tải ứng dụng" chèn ở đầu trang sau khi tải là thủ phạm hàng đầu. Chừa sẵn khung có chiều cao cố định, hoặc cho nó nổi đè thay vì đẩy nội dung.

INP

Tìm tác vụ JavaScript dài trong tab Performance của Chrome. Thủ phạm phổ biến là mã bên thứ ba: hộp chat, mã theo dõi, bộ quản lý thẻ tải chục mã khác.
Nút bấm phải vẽ phản hồi ngay (đổi trạng thái, hiện vòng xoay) rồi mới làm việc nặng.

Cân nặng HTML và nén

Máy chủ phải nén HTML bằng gzip hoặc brotli; trang 300 KB chưa nén thường chỉ còn 50–70 KB khi nén. Googlebot đọc tối đa 15 MB đầu của tệp HTML nên cân nặng hiếm khi gây mất nội dung, nhưng HTML phình to (thường do nhúng sẵn dữ liệu JSON khổng lồ hoặc SVG lặp lại) làm chậm cả tải lẫn dựng trang. SEO Gốc cảnh báo khi HTML nén vượt 100 KB, ngưỡng do SEO Gốc đặt.

Lỗi hay gặp

Đuổi theo điểm Lighthouse 100. Tốn công tối ưu những thứ không ảnh hưởng người dùng thật, trong khi INP thật đang kém vì một hộp chat.
Đo từ văn phòng cáp quang. Người đo thấy nhanh, khách trên 4G thấy chậm. Luôn xem dữ liệu thật và giả lập di động.
Chỉ đo trang chủ. Trang chủ thường được chăm nhất; trang bài và trang danh mục mới là trang nhận lượt tìm kiếm. Báo cáo Search Console gom theo nhóm URL, xem nhóm nào kém.
Chồng plugin tối ưu. Hai plugin cùng gộp và trì hoãn JavaScript có thể làm hỏng chức năng hoặc chậm hơn. Mỗi lớp đệm chỉ nên có một chủ.
Chuyển hướng ở trang đầu. Mỗi bước chuyển hướng thêm một lượt mạng trước cả TTFB của trang thật; gom về một bước như bài chuyển hướng 301 và gom www.

Thứ tự làm cho site nhỏ

Đo TTFB vài lần ở giờ khác nhau. Trên 1,5 giây thì sửa máy chủ hoặc bật đệm trang trước mọi việc khác.
Bật nén, bật đệm trình duyệt cho tệp tĩnh.
Sửa ảnh LCP: bỏ lazy, đúng kích thước, định dạng nhẹ.
Gắn kích thước cho ảnh và khung nhúng để hết CLS.
Rà mã bên thứ ba, bỏ thứ không ai dùng.
Sau đó mới tính tới tối ưu sâu hơn, và chỉ khi dữ liệu thật vẫn kém.

Kiểm bằng SEO Gốc

Chấm điểm site đo TTFB trang chủ (6 điểm), cân nặng HTML sau nén (3 điểm) và có nén hay không. Đây là phép đo máy chủ, không thay được Core Web Vitals; với LCP, INP, CLS hãy xem báo cáo Core Web Vitals trong Search Console và tài liệu trên web.dev. Cách SEO Gốc tính điểm từng mục ở thang chấm điểm.

Hỏi đáp

Điểm PageSpeed Insights thấp có làm tụt hạng không?

Điểm số Lighthouse không phải yếu tố xếp hạng. Google dùng dữ liệu Core Web Vitals của người dùng thật, hiện ở phần đầu PageSpeed Insights và trong Search Console. Điểm phòng thí nghiệm chỉ giúp tìm nguyên nhân.

Search Console không có dữ liệu Core Web Vitals là sao?

Site chưa đủ lượt truy cập từ Chrome để Google có mẫu thống kê. Đó không phải đánh giá xấu. Khi chưa có dữ liệu thật, dùng phép đo phòng thí nghiệm và giả lập di động để tự kiểm.

TTFB bao nhiêu là ổn?

web.dev coi khoảng 0,8 giây trở xuống là tốt. SEO Gốc cảnh báo từ 0,6 giây và chấm không điểm khi trên 1,5 giây, đó là ngưỡng riêng của công cụ. Một lần đo chỉ để phát hiện máy chủ chậm rõ rệt, nên đo lại ở nhiều giờ khác nhau.

Sửa tốc độ xong bao lâu thì báo cáo xanh?

Dữ liệu thật tính trên cửa sổ trượt 28 ngày nên báo cáo cải thiện dần trong khoảng bốn tuần. Kiểm ngay bằng phép đo phòng thí nghiệm để biết sửa đúng chỗ chưa.