TTFB là gì? Cách đo và cải thiện Time to First Byte

TTFB (Time to First Byte) là khoảng thời gian tính từ khi browser gửi request tới khi nhận được byte đầu tiên của response từ server. Đây là metric đo phản hồi của server, không phải thời gian render trang. TTFB tốt < 200ms, chấp nhận được < 600ms, cần xử lý gấp khi > 1000ms. Bài này phân tích 5 thành phần cấu thành TTFB và 7 cách giảm cụ thể.

Định nghĩa và mối liên hệ với Core Web Vitals

TTFB không phải là 1 trong 3 Core Web Vitals chính (LCP, INP, CLS) nhưng có ảnh hưởng trực tiếp lên LCP. Theo web.dev/articles/vitals, TTFB cao chiếm phần lớn trong “preload phase” của LCP — nếu TTFB đã 1500ms thì LCP gần như chắc chắn vượt threshold 2.5s, dù asset CSS/JS/image tối ưu đến đâu.

Phân biệt TTFB với các metric khác:

• TTFB: request gửi → byte đầu về (đo ở browser hoặc curl).
• FCP (First Contentful Paint): byte đầu về → paint pixel đầu tiên.
• LCP (Largest Contentful Paint): byte đầu về → element lớn nhất paint xong.

5 thành phần cấu thành TTFB

1. DNS lookup (10-50ms)

Browser cần resolve domain (vd example.com) thành IP address. Lần đầu request domain mới → DNS server query lookup chain (root → TLD → authoritative). DNS có cache TTL 300-86400s ở browser/OS/ISP, lần sau lấy từ cache.

Tối ưu: dùng DNS provider tốc độ cao (Cloudflare DNS 1.1.1.1, Google 8.8.8.8 — trên server). Trên frontend, dùng <link rel="dns-prefetch"> cho domain phụ.

2. TCP handshake (20-80ms)

3-way handshake: SYN → SYN-ACK → ACK. Latency phụ thuộc khoảng cách vật lý browser ↔ server. User Hà Nội → server Singapore: ~30ms; server US East: ~180ms.

Tối ưu: dùng CDN có edge node tại VN region. Cloudflare có PoP tại HCMC + HN.

3. SSL/TLS handshake (50-150ms)

Sau TCP, client + server thương lượng cipher suite, verify cert, exchange key. TLS 1.2 cần 2-RTT (round trip time), TLS 1.3 chỉ cần 1-RTT — tiết kiệm 50-100ms.

Tối ưu: bật TLS 1.3 (Cloudflare/LiteSpeed/Nginx mặc định bật 2024+), bật HTTP/2 hoặc HTTP/3 (multiplex nhiều request trên 1 connection), dùng Let’s Encrypt auto-renew để cert luôn valid.

4. Server processing (50-1500ms)

Phần biến động nhất. Bao gồm:

• Web server (Nginx/Apache/LiteSpeed) nhận request, parse header.
• PHP-FPM compile (hoặc OPcache hit lookup), execute WordPress core.
• WP_Query, get_options, render template, plugin hook.
• Database query (MySQL/MariaDB) — nhiều join, JOIN với meta_query.
• Sinh HTML cuối cùng, ghi log, response header.

TTFB cao thường xuất phát từ đây. Cache hit (page cache HIT) → bỏ qua PHP+DB → server processing chỉ ~30-80ms. Cache miss → đầy đủ chuỗi → 800-1500ms trên hosting shared.

Liên quan: server cache là gì, page cache warm-up.

5. Network latency (10-100ms)

Sau khi server gửi byte đầu, byte đó vẫn cần travel qua mạng vật lý về browser. Latency tối thiểu = (khoảng cách) / (tốc độ ánh sáng trong fiber) — không thể giảm dưới ngưỡng vật lý này.

Cách đo TTFB

Tool đo

• Chrome DevTools → Network → Timing tab: request bất kỳ → xem “Waiting for server response” = TTFB.
• PageSpeed Insights: “Server response time” trong section Diagnostics + RUM data CrUX nếu site đủ traffic.
• Lighthouse: chạy local hoặc qua DevTools, audit “Reduce initial server response time”.
• WebPageTest.org: waterfall chi tiết, phân tách rõ DNS/TCP/SSL/TTFB.
• curl: curl -w "DNS:%{time_namelookup}s TCP:%{time_connect}s SSL:%{time_appconnect}s TTFB:%{time_starttransfer}sn" -o /dev/null -s https://example.com/

So sánh synthetic vs RUM

• Synthetic test (PageSpeed lab data, Lighthouse local) — đo từ 1 location, network controlled, lặp lại nhất quán. Tốt cho debug.
• RUM (Real User Monitoring) — đo từ user thật, đa device đa geo, bao gồm cả 3G mạng yếu. Tốt cho production monitor.

GA4 Web Vitals event hoặc Cloudflare Web Analytics cung cấp RUM data miễn phí.

7 cách giảm TTFB

Theo thứ tự ROI

1. Page cache: impact lớn nhất (-800-1400ms). Dùng LiteSpeed Cache (free), WP Rocket, hoặc Nginx FastCGI cache.
2. CDN gần user: -100-300ms từ network/SSL. Cloudflare free tier đủ cho phần lớn site VN.
3. Object cache Redis: -100-400ms khi cache miss. Cần persistent cache backend.
4. Nâng hosting từ shared lên VPS/cloud nếu site có DB heavy hoặc traffic spike: -200-600ms.
5. OPcache PHP: -50-150ms. Mặc định bật ở PHP 5.5+.
6. HTTP/2 + TLS 1.3: -50-100ms từ handshake. Hosting tử tế đã có sẵn.
7. DNS provider chất lượng: -20-40ms. Tác động nhỏ nhưng free.

Sai lầm thường gặp khi xử lý TTFB

1. Tối ưu frontend khi TTFB chưa fix. Minify CSS/JS, lazy load image, defer JS — đều giảm LCP nhưng không giảm TTFB. Nếu TTFB 1800ms thì LCP không thể < 2.5s. Fix TTFB trước.
2. Đo TTFB trên cache hit rồi tự tin sai. Sau khi user đã visit, lần test thứ 2 cache HIT TTFB 80ms — không phải số thật cho user mới. Test với cache cleared hoặc URL có query random.
3. Dùng plugin tracking quá nặng. Mỗi request phải gọi external API (Hotjar, Mixpanel, Facebook Pixel server-side) → block PHP wait response → TTFB tăng. Audit qua Query Monitor plugin.
4. Hosting shared khi traffic vượt 100 user concurrent. CPU bị throttle bởi neighbor, IO contention, MySQL bị queue — không cache nào fix được. Lúc này phải nâng VPS.
5. Plugin “thần thánh tăng tốc” hứa giảm 80% TTFB nhưng thực ra chỉ là minify HTML. Đo TTFB qua curl/WebPageTest trước và sau khi cài plugin để verify số thật.
6. Quên monitor sau khi fix. TTFB tốt hôm nay không đảm bảo tháng sau — DB lớn lên, traffic tăng, plugin update làm regression. Set RUM alert khi TTFB p75 > 600ms.

Khi nào nên audit TTFB

• LCP của site > 2.5s trên PageSpeed Insights và “Server response time” báo cao.
• Google Search Console → Page Experience report cảnh báo “Slow URL”.
• RUM data ghi nhận TTFB p75 > 800ms.
• Sau campaign marketing tăng traffic, site chậm hẳn — dấu hiệu hosting/DB không scale.

Liên quan: cách tối ưu PageSpeed, Technical SEO, SSL là gì, redirect 301 (chain redirect cộng dồn TTFB).

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

Khi cần audit TTFB chi tiết hoặc setup stack tối ưu (page cache + Redis + CDN), tham khảo dịch vụ tối ưu hiệu năng hoặc bảng giá dịch vụ Web22.