Bạn đã nén ảnh, bật lazy load, gộp CSS và xóa bớt plugin, nhưng điểm tốc độ vẫn không nhúc nhích. Mở PageSpeed Insights lên thì thấy một dòng cảnh báo quen thuộc: “Giảm thời gian phản hồi của máy chủ (TTFB)”. Đây là tình huống cực kỳ phổ biến, và nó cho thấy vấn đề nằm ở chỗ khác hẳn nơi bạn đang tối ưu: trang web chậm không phải vì nội dung nặng, mà vì máy chủ mất quá lâu mới chịu trả về byte dữ liệu đầu tiên.
Mọi kỹ thuật tối ưu phía trình duyệt đều chỉ bắt đầu có tác dụng sau khi byte đầu tiên về tới nơi. Nếu TTFB đã là 1,5 giây, thì dù bạn có tối ưu hoàn hảo đến đâu, người dùng vẫn phải nhìn màn hình trắng suốt 1,5 giây đó. Bài viết này sẽ giải thích TTFB là gì, cách đo chính xác, các nguyên nhân gốc khiến chỉ số này cao, và một lộ trình 5 bước cụ thể để kéo TTFB về dưới ngưỡng tốt.
TTFB là gì?
TTFB (Time To First Byte) là khoảng thời gian tính từ lúc trình duyệt gửi yêu cầu tới máy chủ cho đến khi nó nhận được byte dữ liệu đầu tiên của phản hồi. Nói ngắn gọn, đây là chỉ số đo “độ trễ phản hồi” của máy chủ — khoảng thời gian người dùng ngồi chờ trong khi màn hình vẫn hoàn toàn trắng.
Điểm quan trọng nhiều người hiểu sai: TTFB không đo tốc độ tải toàn bộ trang. Nó chỉ đo tới byte đầu tiên. Một trang có TTFB 0,2 giây vẫn có thể tải xong sau 8 giây nếu ảnh quá nặng. Ngược lại, một trang rất nhẹ vẫn có thể chậm thảm hại nếu TTFB là 2 giây. Đây là hai vấn đề riêng biệt, cần hai nhóm giải pháp khác nhau.
TTFB bao gồm những giai đoạn nào?
TTFB không phải một con số đơn lẻ mà là tổng của nhiều pha nối tiếp nhau. Hiểu rõ từng pha giúp bạn biết chính xác cần sửa ở đâu thay vì tối ưu mò:
- Redirect time — thời gian xử lý chuyển hướng, nếu URL bị redirect trước khi tới đích. Mỗi lần chuyển hướng là một vòng yêu cầu mới, cộng thêm toàn bộ các pha bên dưới một lần nữa.
- DNS lookup — thời gian phân giải tên miền thành địa chỉ IP. Thường 20–120ms, phụ thuộc nhà cung cấp DNS.
- TCP connection — thời gian bắt tay ba bước để thiết lập kết nối với máy chủ. Phụ thuộc mạnh vào khoảng cách địa lý.
- TLS handshake — thời gian thương lượng mã hóa HTTPS. Với TLS 1.3 pha này nhanh hơn đáng kể so với TLS 1.2.
- Server processing — thời gian máy chủ thực sự xử lý yêu cầu: chạy mã PHP, truy vấn cơ sở dữ liệu, dựng HTML. Đây thường là pha chiếm tỷ trọng lớn nhất và cũng là nơi bạn can thiệp được nhiều nhất.
Khi nhìn vào cơ cấu này, bạn sẽ thấy ngay vì sao các mẹo tối ưu ảnh hay gộp file JavaScript không giúp gì cho TTFB: không pha nào trong số trên liên quan tới tài nguyên tĩnh của trang cả.
TTFB bao nhiêu là tốt?
Google đưa ra mốc đánh giá khá rõ ràng cho chỉ số này. Ngưỡng được dùng phổ biến trong tài liệu chính thức trên web.dev như sau:
| Mức TTFB | Đánh giá | Ý nghĩa thực tế | Mức độ ưu tiên xử lý |
|---|---|---|---|
| Dưới 0,8 giây | Tốt | Máy chủ phản hồi nhanh, còn dư ngân sách thời gian cho việc render | Không cần can thiệp |
| 0,8 – 1,8 giây | Cần cải thiện | Đã ăn mất phần lớn ngân sách thời gian dành cho LCP | Nên xử lý trong tháng |
| Trên 1,8 giây | Kém | Gần như không thể đạt Core Web Vitals dù tối ưu phần còn lại | Bắt buộc, ưu tiên cao nhất |
Một cách hiểu thực dụng hơn: hãy coi TTFB là khoản chi phí cố định bạn phải trả trước khi trang bắt đầu hiển thị. Nếu mục tiêu Largest Contentful Paint là 2,5 giây mà riêng TTFB đã ngốn 1,8 giây, bạn chỉ còn vỏn vẹn 0,7 giây để tải font, CSS và ảnh banner. Điều đó gần như bất khả thi với một trang thông thường. Đây chính là lý do TTFB là chỉ số phải xử lý đầu tiên, trước mọi tối ưu front-end khác.
TTFB có phải yếu tố xếp hạng trực tiếp không?
Câu trả lời trung thực là không. TTFB không nằm trong bộ Core Web Vitals chính thức — bộ này gồm LCP, INP và CLS. Google xếp TTFB vào nhóm chỉ số chẩn đoán (diagnostic metric), tức công cụ giúp bạn tìm nguyên nhân chứ không phải thước đo được chấm điểm trực tiếp.
Nhưng đừng vì thế mà xem nhẹ. TTFB ảnh hưởng gián tiếp nhưng rất mạnh tới những chỉ số thực sự được tính điểm. Cụ thể, TTFB là thành phần cấu thành đầu tiên của LCP; TTFB cao thì LCP gần như chắc chắn cao theo. Tương tự, thời gian chờ ban đầu kéo dài cũng làm trải nghiệm tương tác xấu đi, gián tiếp ảnh hưởng tới chỉ số INP. Nói cách khác, TTFB không bị chấm điểm, nhưng nó quyết định phần lớn điểm số của những chỉ số bị chấm.
TTFB ảnh hưởng tới SEO và traffic như thế nào?
1. Kéo tụt toàn bộ Core Web Vitals
Như đã phân tích, LCP luôn lớn hơn hoặc bằng TTFB. Đây là quan hệ toán học, không phải phỏng đoán. Nếu TTFB của bạn là 2 giây, LCP không bao giờ có thể tốt hơn 2 giây. Mọi nỗ lực preload font, tối ưu ảnh hero hay inline CSS đều vô nghĩa khi trần đã bị chặn từ đầu. Đây là lý do rất nhiều website tối ưu mãi mà điểm Page Experience vẫn giậm chân tại chỗ.
2. Lãng phí ngân sách thu thập dữ liệu
Googlebot có giới hạn thời gian và tài nguyên dành cho mỗi website. Khi máy chủ phản hồi chậm, bot thu thập được ít URL hơn trong cùng một khoảng thời gian, và Google còn chủ động giảm tốc độ crawl để tránh gây quá tải cho máy chủ của bạn. Hệ quả là bài mới lâu được index hơn, bài cập nhật lâu được ghi nhận hơn.
Với website đăng bài thường xuyên hoặc có hàng nghìn URL, đây là thiệt hại rất cụ thể. Bạn có thể tìm hiểu sâu hơn về cơ chế này trong bài crawl budget và bài phân tích cách Googlebot crawl, render và index website.
3. Đẩy người dùng rời trang trước khi thấy nội dung
Trong giai đoạn TTFB, người dùng nhìn thấy đúng một thứ: màn hình trắng. Không có spinner, không có nội dung, không có tín hiệu nào cho thấy trang đang hoạt động. Đây là giai đoạn dễ mất khách nhất, đặc biệt với người vào từ kết quả tìm kiếm — họ chưa có cam kết gì với trang web của bạn và hoàn toàn sẵn sàng bấm nút quay lại để chọn kết quả khác.
Hành vi quay lại SERP ngay sau khi click là tín hiệu tiêu cực rõ ràng. Nó làm tăng tỷ lệ thoát và giảm thời gian ở lại trang — những chỉ số phản ánh trực tiếp mức độ hài lòng của người dùng với kết quả tìm kiếm.
4. Ảnh hưởng nặng hơn trên thiết bị di động
Người dùng di động thường ở trên mạng có độ trễ cao hơn, nên mọi pha trong TTFB đều bị kéo dài. Một TTFB đo được 0,6 giây trên máy tính bàn nối cáp quang có thể trở thành 1,5 giây trên 4G ở vùng sóng yếu. Vì Google đánh giá theo dữ liệu di động là chính, đây là con số bạn cần quan tâm. Bài tối ưu tốc độ tải trang trên mobile phân tích kỹ hơn nhóm vấn đề này.
Cách kiểm tra TTFB chính xác
Trước khi sửa bất cứ thứ gì, bạn cần một con số đáng tin. Sai lầm phổ biến nhất là đo một lần rồi kết luận — trong khi TTFB dao động rất mạnh theo thời điểm, vị trí địa lý và trạng thái cache.
Chrome DevTools — nhanh và chi tiết nhất
Mở DevTools, vào tab Network, tải lại trang, click vào request đầu tiên (chính là file HTML), rồi xem mục Timing. Dòng Waiting for server response chính là TTFB. Ưu điểm lớn của cách này là bạn thấy được từng pha riêng biệt — DNS, kết nối, TLS, chờ phản hồi — nên biết ngay pha nào đang ngốn thời gian.
Lưu ý bắt buộc: hãy tick Disable cache và thử ở chế độ ẩn danh, nếu không bạn sẽ đo nhầm trên bản đã được cache sẵn và nhận con số đẹp một cách giả tạo.
PageSpeed Insights — có cả dữ liệu người dùng thật
Công cụ này cho bạn hai loại dữ liệu rất khác nhau. Phần lab data là kết quả mô phỏng trong môi trường chuẩn. Phần field data lấy từ báo cáo trải nghiệm người dùng thật trong 28 ngày gần nhất — đây mới là con số Google thực sự dùng để đánh giá. Nếu hai con số chênh nhau nhiều, hãy luôn tin vào field data. Hướng dẫn đọc chi tiết có trong bài Google PageSpeed Insights.
Kiểm tra bằng dòng lệnh curl
Đây là cách chính xác nhất để tách bạch từng pha mà không bị nhiễu bởi trình duyệt hay tiện ích mở rộng. Bạn tạo một file format.txt chứa các biến thời gian của curl, sau đó gọi lệnh với tùy chọn ghi ra thông tin thời gian. Kết quả trả về sẽ hiển thị riêng thời gian phân giải DNS, thời gian kết nối, thời gian bắt tay TLS và thời gian bắt đầu truyền dữ liệu. Hiệu thời gian giữa pha bắt tay TLS và pha bắt đầu truyền chính là phần máy chủ xử lý.
Mẹo quan trọng: chạy lệnh ít nhất 5–10 lần liên tiếp và lấy giá trị trung vị. Lần chạy đầu tiên thường chậm hơn hẳn vì cache chưa được làm nóng, nếu chỉ đo một lần bạn sẽ có kết luận sai lệch.
WebPageTest — đo từ nhiều vị trí địa lý
Điểm mạnh riêng của công cụ này là cho phép chọn vị trí máy đo. Nếu website phục vụ khách Việt Nam nhưng máy chủ đặt ở Mỹ, hãy đo từ Singapore hoặc Hà Nội để thấy con số thực tế mà khách của bạn đang chịu. Đây cũng là cách nhanh nhất để chứng minh bạn có cần CDN hay không: nếu TTFB đo từ nơi đặt máy chủ rất tốt nhưng đo từ Việt Nam lại tệ, vấn đề là khoảng cách địa lý chứ không phải máy chủ yếu.
Nguyên nhân khiến TTFB cao
Gần như mọi trường hợp TTFB cao đều quy về một trong bảy nguyên nhân dưới đây. Hãy kiểm tra theo đúng thứ tự này, vì chúng được sắp xếp theo tần suất gặp phải trong thực tế.
Hosting quá yếu hoặc bị chia sẻ tài nguyên
Đây là nguyên nhân số một, đặc biệt với gói shared hosting giá rẻ. Trên shared hosting, hàng trăm website dùng chung một máy chủ vật lý. Khi một website khác trên cùng máy chủ bị tăng đột biến lượt truy cập, tài nguyên CPU bị chia sẻ và TTFB của bạn tăng vọt dù bạn không làm gì sai cả.
Dấu hiệu nhận biết rõ nhất: TTFB dao động thất thường theo giờ trong ngày, lúc 0,4 giây lúc 2 giây, mà lưu lượng truy cập của chính bạn thì không đổi. Nếu thấy mẫu hình này, vấn đề gần như chắc chắn nằm ở hàng xóm trên cùng máy chủ.
Không có cache trang hoàn chỉnh
Với một hệ quản trị nội dung động như WordPress, mỗi lượt truy cập không có cache đều kéo theo toàn bộ quy trình: khởi động PHP, nạp toàn bộ plugin, thực hiện hàng chục truy vấn cơ sở dữ liệu, rồi mới dựng xong HTML. Quy trình này dễ dàng mất 800ms đến 2 giây.
Khi có full page cache, máy chủ chỉ việc trả về một file HTML đã dựng sẵn. Thời gian xử lý rơi xuống còn vài chục mili giây. Đây là thay đổi đơn lẻ có tác động lớn nhất tới TTFB, và cũng là việc dễ làm nhất.
Cơ sở dữ liệu chậm
Database phình to theo thời gian là chuyện tất yếu. Bảng lưu bài viết tích tụ hàng nghìn bản nháp tự động, bảng tùy chọn tích tụ dữ liệu rác từ các plugin đã gỡ nhưng không dọn sạch. Nguy hiểm nhất là các tùy chọn được đánh dấu tự động nạp — chúng được đọc lên trong mọi lượt truy cập, kể cả khi trang đó không cần đến.
Một website có vài megabyte dữ liệu tự động nạp sẽ chậm ở mọi trang, mọi lượt truy cập, và không công cụ đo tốc độ nào chỉ thẳng ra nguyên nhân này.
Plugin và theme viết kém
Một plugin duy nhất gọi API bên ngoài ngay trong quá trình dựng trang có thể cộng thêm cả giây vào TTFB — và nếu dịch vụ bên ngoài đó sập, trang của bạn treo theo. Tương tự, theme thực hiện truy vấn nặng để đếm lượt xem hoặc lấy bài liên quan trên mọi trang cũng là thủ phạm quen mặt.
Khoảng cách địa lý
Dữ liệu không thể đi nhanh hơn tốc độ ánh sáng. Một vòng yêu cầu từ Việt Nam tới máy chủ đặt tại Mỹ mất khoảng 200–250ms chỉ riêng cho đường truyền, và TTFB cần vài vòng như vậy để hoàn tất bắt tay TCP và TLS. Đây là giới hạn vật lý, không phần mềm nào khắc phục được ngoài cách đưa nội dung tới gần người dùng hơn.
Chuỗi chuyển hướng
Mỗi lần chuyển hướng là một vòng yêu cầu hoàn chỉnh mới. Một chuỗi phổ biến nhưng tai hại: từ địa chỉ không bảo mật chuyển sang bảo mật, rồi từ tên miền không có tiền tố chuyển sang có tiền tố, rồi thêm dấu gạch chéo cuối. Ba lần chuyển hướng liên tiếp có thể cộng thêm 400–600ms trước khi máy chủ bắt đầu làm việc thật. Hãy cấu hình để mọi biến thể URL chuyển thẳng tới đích cuối cùng chỉ trong một bước.
Cấu hình TLS chưa tối ưu
Dùng TLS 1.3 thay vì 1.2 giúp giảm một vòng bắt tay. Bật cơ chế ghim phản hồi trạng thái chứng chỉ giúp trình duyệt không phải hỏi riêng bên cấp chứng chỉ. Những tinh chỉnh này thường tiết kiệm 50–150ms — không nhiều bằng cache, nhưng là phần thưởng gần như miễn phí khi bạn đã xử lý xong các nguyên nhân lớn.
Lộ trình 5 bước giảm TTFB
Thứ tự dưới đây được sắp xếp theo nguyên tắc: xử lý nguyên nhân gốc trước, tinh chỉnh sau. Làm ngược thứ tự là lý do phổ biến khiến nhiều người tối ưu rất nhiều mà con số không nhúc nhích.
Bước 1 — Đo chuẩn và ghi lại mốc xuất phát
Đo TTFB ở ít nhất ba loại trang khác nhau: trang chủ, một bài viết, và một trang động không thể cache như trang giỏ hàng hoặc kết quả tìm kiếm nội bộ. Đo mỗi loại 5 lần, ghi lại giá trị trung vị. Đồng thời ghi lại field data từ PageSpeed Insights.
Nếu bỏ qua bước này, bạn sẽ không bao giờ chứng minh được tối ưu có hiệu quả hay không, và cũng không biết nên dừng ở đâu.
Bước 2 — Xử lý nền tảng máy chủ
Nâng phiên bản PHP lên bản mới nhất mà mã nguồn của bạn hỗ trợ — chênh lệch hiệu năng giữa các phiên bản cách nhau vài đời là rất đáng kể, thường 30–50%. Bật bộ nhớ đệm mã máy để PHP không phải biên dịch lại mã nguồn ở mọi lượt truy cập.
Nếu đang dùng shared hosting mà TTFB vẫn cao sau khi đã bật cache, hãy cân nhắc nâng lên máy chủ riêng ảo. Đây là khoản đầu tư có tác động rõ rệt nhất khi tất cả các cách phần mềm đã cạn.
Bước 3 — Bật cache trang hoàn chỉnh
Chọn một giải pháp cache ở mức máy chủ nếu có thể, vì nó phục vụ HTML tĩnh mà không cần khởi động PHP. Ba điều cần kiểm tra ngay sau khi bật:
- Xác nhận cache thực sự hoạt động — kiểm tra header phản hồi xem có báo trúng cache hay không, đừng tin vào giao diện plugin.
- Rà soát danh sách loại trừ. Rất nhiều người vô tình loại trừ quá nhiều trang, khiến những trang quan trọng nhất vẫn chạy không cache.
- Thiết lập cơ chế làm nóng cache sau mỗi lần xóa, để người dùng đầu tiên không phải gánh lượt truy cập chậm.
Với website WordPress, phần cấu hình chi tiết được trình bày trong bài SEO WordPress từ A-Z.
Bước 4 — Đưa nội dung tới gần người dùng bằng CDN
Điểm mấu chốt mà rất nhiều người bỏ lỡ: CDN mặc định chỉ tăng tốc tài nguyên tĩnh như ảnh, CSS, JavaScript. Những thứ này không ảnh hưởng tới TTFB, vì TTFB đo ở tài liệu HTML.
Muốn CDN thực sự giảm TTFB, bạn phải bật cache HTML tại biên. Khi đó, máy chủ biên gần người dùng nhất sẽ trả thẳng HTML đã cache mà không cần hỏi máy chủ gốc. TTFB cho khách ở xa có thể giảm từ 1,2 giây xuống còn 0,2–0,3 giây. Đây là khác biệt giữa “đã mua CDN” và “đã dùng CDN đúng cách”.
Bước 5 — Tối ưu cơ sở dữ liệu và các trang không thể cache
Sau bốn bước trên, phần lớn lưu lượng đã được phục vụ từ cache. Việc còn lại là xử lý những trang bắt buộc phải động. Hãy dọn dẹp dữ liệu tự động nạp, xóa bản nháp tự động cũ, bổ sung chỉ mục cho các truy vấn chậm, và cân nhắc bộ nhớ đệm đối tượng để giảm số lần hỏi cơ sở dữ liệu.
Năm sai lầm thường gặp khi tối ưu TTFB
Sai lầm 1 — Chỉ tin vào lab data. Con số mô phỏng đo từ một máy chủ ở nước ngoài, trong điều kiện lý tưởng, không phản ánh trải nghiệm của khách hàng thật. Luôn đối chiếu với field data trước khi kết luận.
Sai lầm 2 — Bật cache nhưng loại trừ quá nhiều. Thêm một quy tắc loại trừ để khắc phục lỗi hiển thị nhỏ, rồi quên mất, là chuyện rất thường gặp. Hãy rà lại danh sách này định kỳ và kiểm tra trực tiếp bằng header phản hồi.
Sai lầm 3 — Mua CDN rồi để mặc định. Như đã phân tích ở bước 4, không bật cache HTML tại biên thì CDN gần như không tác động gì tới TTFB.
Sai lầm 4 — Đổ lỗi cho hosting quá sớm. Trước khi nâng cấp gói, hãy thử tắt toàn bộ plugin trên môi trường thử nghiệm rồi bật lại từng cái và đo lại. Rất nhiều trường hợp thủ phạm là một plugin duy nhất, và đổi hosting chỉ che giấu vấn đề chứ không giải quyết.
Sai lầm 5 — Nén ảnh để giảm TTFB. Tối ưu ảnh là việc tốt và cần làm, nhưng nó cải thiện LCP và tổng thời gian tải, không cải thiện TTFB. Byte đầu tiên đã được gửi đi từ trước khi trình duyệt biết trang có ảnh nào.
Checklist triển khai
Dùng danh sách này như một quy trình tuần tự, đánh dấu từng mục sau khi đã xác minh bằng số đo thật:
- Đã đo TTFB trung vị trên 3 loại trang, ghi lại mốc xuất phát
- Đã đối chiếu field data từ PageSpeed Insights, không chỉ dựa vào lab data
- Đã nâng PHP lên phiên bản mới và bật bộ nhớ đệm mã máy
- Đã bật full page cache và xác minh bằng header phản hồi
- Đã rà soát danh sách loại trừ cache, chỉ giữ lại trang thật sự cần động
- Đã bật cache HTML tại biên trên CDN, không chỉ cache tài nguyên tĩnh
- Đã rút mọi chuỗi chuyển hướng về tối đa một bước
- Đã bật TLS 1.3 và cơ chế ghim phản hồi trạng thái chứng chỉ
- Đã dọn dữ liệu tự động nạp và bản nháp tự động cũ
- Đã đo lại sau 7 ngày và so sánh với mốc xuất phát
- Đã đặt lịch kiểm tra định kỳ hàng tháng để phát hiện suy giảm sớm
Câu hỏi thường gặp về TTFB
TTFB bao nhiêu là đủ tốt cho website tại Việt Nam?
Hãy đặt mục tiêu dưới 0,8 giây đo từ vị trí Việt Nam trên kết nối di động. Nếu máy chủ đặt trong nước và có cache tốt, mức 0,2–0,4 giây là hoàn toàn khả thi. Điều quan trọng là đo từ nơi khách hàng thật của bạn đang ở, không phải từ máy chủ đo đặt ở nước ngoài.
Giảm TTFB có giúp tăng thứ hạng ngay không?
Không ngay lập tức. Tốc độ là một trong rất nhiều yếu tố, và nội dung vẫn quan trọng hơn. Tuy nhiên giảm TTFB mang lại ba lợi ích tích lũy: cải thiện Core Web Vitals, tăng tốc độ thu thập dữ liệu, và giảm tỷ lệ người dùng rời trang sớm. Ba yếu tố này cùng tác động sẽ tạo ra khác biệt rõ rệt sau vài tuần đến vài tháng.
Vì sao TTFB trong Chrome DevTools khác với PageSpeed Insights?
Vì hai công cụ đo ở hai điều kiện khác nhau. DevTools đo từ chính máy bạn, với kết nối mạng và vị trí địa lý của bạn. PageSpeed Insights ở phần field data tổng hợp từ hàng nghìn người dùng thật với đủ loại thiết bị và đường truyền. Khi cần ra quyết định, hãy ưu tiên field data.
Website dùng shared hosting có thể đạt TTFB tốt không?
Có, nếu bật full page cache đúng cách và dùng CDN có cache HTML tại biên. Khi đó phần lớn lượt truy cập không hề chạm tới PHP, nên điểm yếu của shared hosting ít bộc lộ. Hạn chế thật sự chỉ xuất hiện ở những trang bắt buộc phải động như giỏ hàng hay tài khoản người dùng.
TTFB cao có ảnh hưởng tới tốc độ index bài mới không?
Có. Máy chủ phản hồi chậm khiến Googlebot thu thập được ít URL hơn trong mỗi phiên và chủ động giảm tần suất ghé thăm. Với website đăng bài đều đặn, đây là lý do thường bị bỏ sót khi bài mới lâu được lập chỉ mục.
Có nên dùng plugin để giảm TTFB không?
Plugin cache là cần thiết và hiệu quả. Nhưng hãy cảnh giác với các plugin quảng cáo “tăng tốc toàn diện” bằng cách cộng dồn hàng chục tính năng — bản thân chúng cũng tiêu tốn tài nguyên trong mỗi lượt truy cập. Nguyên tắc an toàn: một plugin cache tốt, cấu hình đúng, vẫn hơn ba plugin tối ưu chồng chéo nhau.
Kết luận
TTFB không phải chỉ số được Google chấm điểm trực tiếp, nhưng nó là trần giới hạn cho mọi nỗ lực tối ưu tốc độ khác. Không thể đạt LCP tốt khi TTFB đã tệ, cũng không thể mong Googlebot thu thập dữ liệu nhanh khi máy chủ phản hồi chậm.
Việc cần làm ngay hôm nay rất cụ thể: mở Chrome DevTools, đo TTFB trang chủ và một bài viết bất kỳ, ghi lại con số. Nếu kết quả trên 0,8 giây, hãy bắt đầu từ bước 3 trong lộ trình — bật full page cache và xác minh bằng header phản hồi. Chỉ riêng bước này thường đã đưa TTFB về ngưỡng tốt với đa số website. Sau đó đo lại sau 7 ngày và so sánh với mốc xuất phát để biết chính xác mình đã đi được bao xa.
Zalo