Tối ưu TTFB chuyên sâu (mổ xẻ từng lớp làm chậm phản hồi)

Trước khi trình duyệt kịp đọc một dòng HTML, nó phải nhận được byte đầu tiên từ máy chủ. Vì vậy mọi chỉ số tốc độ phía sau — từ LCP (Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra) cho tới lúc trang tương tác được — đều thừa hưởng (hoặc gánh chịu) con số TTFB. Nếu bạn cần phần định nghĩa căn bản, hãy đọc bài TTFB là gì và vì sao quan trọng trước; bài này đi thẳng vào việc đào từng lớp gây chậm và cách xử lý.

TTFB nằm ở đâu trong bức tranh Core Web Vitals 2026

TTFB không phải là một Core Web Vital chính thức. Ba chỉ số xếp hạng vẫn là LCP ≤ 2.5s, INP (Interaction to Next Paint — độ trễ tới lần vẽ kế tiếp sau tương tác) ≤ 200ms và CLS (Cumulative Layout Shift — tổng dịch chuyển bố cục) ≤ 0.1, đều đo ở phân vị 75 (p75 — 75% lượt truy cập phải “tốt”). Nhưng TTFB là phần nền của LCP: theo web.dev, ngưỡng “Good” cho TTFB là 0.8 giây trở xuống, từ 0.8 đến 1.8 giây là cần cải thiện, trên 1.8 giây là kém.

Nói cách khác, một trang có TTFB 1.5 giây gần như không còn cửa đạt LCP 2.5 giây, vì đã đốt hơn nửa ngân sách thời gian chỉ để chờ máy chủ mở miệng. Tối ưu TTFB vì thế là đòn bẩy gốc, làm trước khi tối ưu ảnh hay JavaScript.

Mổ xẻ TTFB thành các lớp

TTFB không phải một con số khối đặc. Nó là tổng của nhiều lớp nối tiếp nhau, và bạn chỉ tối ưu được khi tách ra để biết lớp nào đang ăn thời gian:

Phần “Chờ máy chủ xử lý” và “Truy vấn cơ sở dữ liệu” thường là thủ phạm lớn nhất với WordPress: mỗi lần tải trang, PHP phải khởi động, gọi hàng chục query vào MySQL, lắp ráp HTML rồi mới trả về. Đây chính là nơi cache phát huy hiệu quả nhất.

Page cache — đòn bẩy đáng làm trước nhất

Page cache (cache trang) biến trang động thành tệp HTML tĩnh đã dựng sẵn. Khi khách vào, máy chủ trả thẳng tệp HTML đó — bỏ qua toàn bộ khâu chạy PHP và hỏi cơ sở dữ liệu. Đây là cách kéo TTFB từ vài trăm mili-giây xuống vài chục mili-giây hiệu quả nhất, vì nó xoá hẳn hai lớp tốn kém nhất.

Nếu bạn muốn hiểu cơ chế cache phía máy chủ ở mức tổng quát, bài cache phía máy chủ là gì giải thích kỹ. Ở đây điểm cần nhớ: page cache chỉ giúp với trang có thể phục vụ cùng một HTML cho nhiều người (bài viết, trang dịch vụ). Trang cá nhân hoá (giỏ hàng, tài khoản) phải loại trừ khỏi cache, nếu không khách này thấy dữ liệu của khách kia.

Object cache — cứu phần động không cache trang được

Không phải trang nào cũng cache HTML toàn phần được. Với trang động, object cache (cache đối tượng) lưu lại kết quả các truy vấn cơ sở dữ liệu nặng vào bộ nhớ RAM, để lần sau không phải hỏi MySQL lại. Trong WordPress, Redis là lựa chọn phổ biến cho việc này. Bài Redis object cache cho WordPress đi sâu vào cách cài và đo.

Cách phân vai dễ nhớ: page cache cho phần tĩnh chung, object cache cho phần động còn lại. Hai lớp này bù trừ nhau, không thay thế nhau.

CDN edge — rút ngắn quãng đường vật lý

Dù máy chủ xử lý nhanh tới đâu, byte vẫn phải đi qua dây cáp tới trình duyệt. Khách ở xa máy chủ thì độ trễ đường truyền tự nhiên cao. CDN (Content Delivery Network — mạng phân phối nội dung) đặt bản sao nội dung ở các điểm edge gần người dùng, đồng thời mở sẵn kết nối HTTP/2, HTTP/3 và TLS 1.3 nhanh hơn. Khi cấu hình tốt, CDN có thể phục vụ cả HTML đã cache ngay tại edge, không cần chạm về máy chủ gốc.

Điều kiện để CDN cache được HTML là header Cache-Control phải khai báo đúng. Một mẹo nâng cao là dùng pattern stale-while-revalidate: trả ngay bản cache cũ cho khách (TTFB thấp) trong khi âm thầm làm mới ở nền.

Chọn hosting và phiên bản PHP

Phần cứng và phần mềm nền quyết định trần TTFB mà cache không cứu được. Vài điểm thực chiến:

• Hosting dùng chung quá tải khiến CPU phải xếp hàng — TTFB phình lên giờ cao điểm. Site lưu lượng cao nên cân nhắc gói riêng hoặc VPS.
• Phiên bản PHP: nâng lên PHP 8.2 trở lên cho tốc độ thực thi nhanh hơn đáng kể so với các bản 7.x cũ. Đây là việc gần như miễn phí, chỉ cần đổi trong bảng điều khiển host.
• Web server: LiteSpeed và Nginx xử lý nội dung tĩnh và cache hiệu quả hơn Apache mặc định trong nhiều kịch bản WordPress.
• HSTS để bỏ chuyển hướng HTTP sang HTTPS — mỗi redirect là một vòng khứ hồi cộng thẳng vào TTFB.

Ví dụ thực chiến trên web22.dev

Web22 vận hành chính web22.dev trên LiteSpeed (web server) kèm LiteSpeed Cache và Cloudflare làm CDN. Cấu hình page cache của LiteSpeed Cache (LSCWP) dựng HTML tĩnh ngay ở tầng web server — nhanh hơn cache bằng PHP thuần vì không phải tải khung WordPress lên rồi mới trả. Một đoạn cấu hình tối thiểu để ép cache header đúng và loại trang cá nhân hoá:

# Loại các trang động khỏi page cache (LiteSpeed Cache)
# Settings > Cache > Excludes
/cart
/checkout
/my-account
/wp-admin

# Bật cache trình duyệt cho tài nguyên tĩnh
Header set Cache-Control "public, max-age=31536000, immutable"

Để biết chính xác lớp nào đang ăn thời gian thay vì đoán, bạn có thể bật header Server-Timing đo riêng thời gian dựng HTML, thời gian query và tỉ lệ cache trúng/trượt — rồi đọc thẳng trong tab Network của DevTools. Cách đo minh bạch này quan trọng vì công cụ lab (Lighthouse) đôi khi thổi phồng con số do mô phỏng mạng chậm, khác với dữ liệu field thật.

Thứ tự việc nên làm

1. Đo TTFB hiện tại ở field (CrUX/PageSpeed) lẫn lab, tách theo lớp bằng Server-Timing.
2. Bật page cache cho mọi trang phục vụ HTML chung được.
3. Loại đúng trang cá nhân hoá khỏi cache.
4. Thêm object cache (Redis) cho phần động còn lại.
5. Đặt CDN trước máy chủ, cấu hình Cache-Control để cache HTML ở edge.
6. Nâng PHP, dọn redirect, bật HSTS — phần nền không cache cứu được.

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

TTFB bao nhiêu là tốt?

Theo web.dev, dưới 0.8 giây là tốt, từ 0.8 đến 1.8 giây cần cải thiện, trên 1.8 giây là kém. Đo ở p75 dữ liệu người dùng thật.

Page cache và object cache khác nhau thế nào?

Page cache lưu cả tệp HTML đã dựng, bỏ qua PHP và cơ sở dữ liệu. Object cache chỉ lưu kết quả truy vấn vào RAM, dùng cho trang động không cache HTML toàn phần được.

Có CDN rồi thì còn cần page cache không?

Có. CDN cache ở edge chỉ hiệu quả khi máy chủ gốc khai báo cache header đúng, và nhiều lượt vẫn phải chạm gốc. Page cache giảm tải ngay tại nguồn nên hai lớp bổ trợ nhau.

Nếu bạn muốn có người soi từng lớp TTFB và dựng cấu hình cache phù hợp cho site của mình, tham khảo dịch vụ tối ưu tốc độ website của Web22.