Tại sao caching sai cách còn hại performance hơn không cache

1. Double-caching và vòng lặp revalidate

Khi vừa bật page cache ở plugin (ví dụ full-page HTML) vừa ép cache ở CDN, bạn có thể tạo hai lớp revalidate khác biệt. Mỗi lần purge ở lớp A khiến lớp B coi là miss và truy vấn origin, dẫn tới “bão miss” sau mỗi lần purge. Triệu chứng: spike CPU/PHP-FPM, origin queue tăng, TTFB thất thường.

2. TTL quá ngắn gây cache thrashing

TTL 30–60 giây nghe có vẻ “tươi”, nhưng trên site traffic vừa–cao, điều này tạo vòng lặp fetch liên tục. Thay vì giảm tải, bạn đang biến CDN thành cỗ máy miss. Dấu hiệu: cache hit ratio thấp, request đến origin đều đặn theo nhịp TTL, chi phí tăng.

3. Vary header, cookie và cache-key nổ phân mảnh

Thêm Vary: Cookie, User-Agent bừa bãi khiến cùng một URL sinh ra vô số biến thể cache. Kết quả là tỷ lệ hit giảm mạnh. Trên WordPress, cookie đăng nhập, A/B testing, geolocation rất dễ “đầu độc” cache-key. Cần whitelist cookie thực sự cần thiết và cứng hoá cache-key.

4. Cache nội dung riêng tư hoặc bán riêng tư

Cache page chứa dữ liệu cá nhân (giỏ hàng, hồ sơ, trang quản trị) dễ gây lộ thông tin và hiển thị sai nội dung giữa người dùng. Chuẩn là phải bypass hoặc dùng Cache-Control: private, no-store cho các đường dẫn nhạy cảm và tách rõ route public vs private.

5. Stale-while-revalidate dùng sai

stale-while-revalidate giúp phục vụ bản cũ trong lúc nền đang làm mới. Tuy nhiên nếu thời gian stale quá dài hoặc số worker revalidate không giới hạn, bạn gặp “revalidate stampede” sau khi object hết hạn. Kết quả là nhiều luồng cùng đập vào origin.

6. Microcaching trên trang động

Microcache 1–5 giây hiệu quả cho API idempotent hoặc trang news tĩnh. Áp dụng cho trang có query phụ thuộc user/cookie sẽ tạo độ trễ không ổn định và hiển thị sai trạng thái. Hãy chỉ microcache khi chắc chắn response thật sự có thể chia sẻ.

7. Purge theo cảm tính

Purge toàn bộ CDN mỗi lần cập nhật một bài viết làm “đông cứng” site vài phút vì mọi thứ thành miss. Cần chuyển sang purge có chọn lọc dựa trên URL pattern, tag hoặc surrogate key; kết hợp pre-warm các trang chủ lực sau purge.

8. Nén, minify, WebP “chồng chéo”

CDN nén, plugin cũng nén; CDN convert WebP, server convert nữa. Kết quả là chuỗi xử lý dài hơn, đôi khi tạo lỗi content-type và cache miss do ETag khác nhau. Chọn một tầng chịu trách nhiệm tối ưu tài nguyên tĩnh, ưu tiên CDN hình ảnh để giảm tải origin.

9. ETag/Last-Modified và If-None-Match sai

ETag không ổn định theo deploy (bao gồm timestamp, build-id) khiến mọi lần triển khai đều coi như khác file, bỏ qua 304 và buộc tải mới. Chuẩn là tạo ETag dựa trên nội dung hoặc dùng versioning qua filename để CDN cache bền vững.

10. Object cache ≠ page cache

Nhiều site bật Redis/Memcached rồi tưởng như xong. Object cache chỉ giảm truy vấn DB ở tầng PHP, không thay thế page cache/CDN. Thiếu page cache, mỗi request vẫn phải boot WordPress, tốn CPU và TTFB cao dưới tải.

11. Cache API sai phương thức hoặc sai idempotency

Caching GET là bình thường; caching POST/PUT/PATCH là rủi ro trừ khi thiết kế cẩn thận. Với API đọc dữ liệu, cache key cần bao gồm tham số truy vấn theo chuẩn. Với API ghi, tuyệt đối không cache, và thêm Cache-Control: no-store.

12. Sai khác giữa s-maxage và max-age

s-maxage dành cho shared cache (CDN), max-age cho browser. Đặt max-age dài nhưng s-maxage ngắn sẽ khiến CDN liên tục gọi origin trong khi trình duyệt vẫn giữ bản cũ, gây trải nghiệm không đồng nhất và tải origin vô ích.

13. Bỏ quên critical path và edge logic

Nhiều site cache trang list nhưng lại bỏ qua API chậm trong trang đó, biến API thành nút cổ chai. Cần move một phần logic ra edge (ví dụ conditional routing, early hints, KV/DB edge) hoặc tách API ra domain được tối ưu cache riêng.

14. CDN và server cache không thống nhất

Server set no-cache nhưng CDN rule vẫn “Force cache everything” làm lệch sematics. Hoặc CDN tôn trọng Vary còn server thì strip header. Không đồng nhất dẫn đến hành vi khó đoán, khó debug, dễ sinh lỗi “lúc nhanh lúc chậm”.

Các dấu hiệu bạn đang “cache sai”

• Hit ratio dưới 60% cho nội dung đáng lẽ tĩnh.
• TTFB cao ngay cả với user gần PoP.
• CPU/PHP-FPM spike sau mỗi lần purge hoặc deploy.
• Chênh lệch lớn giữa TTFB CDN và Origin.
• Log cho thấy nhiều biến thể cache theo cookie/User-Agent.

Checklist cấu hình cache an toàn

• Xác định rõ route public vs private. Bypass cache cho /wp-admin, giỏ hàng, tài khoản, API ghi.
• Chuẩn hoá cache-key: strip query thừa, whitelist cookie cần thiết, tránh Vary theo User-Agent nếu không bắt buộc.
• Chọn một nơi duy nhất để nén/minify/chuyển định dạng ảnh.
• Dùng TTL hợp lý: trang tĩnh 10–60 phút, asset có version 1 năm, kết hợp immutable.
• Dùng stale-while-revalidate có giới hạn, thêm cơ chế chống stampede.
• Purge theo URL/tag/surrogate key, kèm pre-warm cho trang chủ lực.
• Phân tách domain cho asset tĩnh để tối ưu cache và policy.
• Giám sát hit ratio, origin traffic, TTFB và error rate theo release.

Thiết lập gợi ý cho WordPress + CDN

• Page cache ở CDN cho khách ẩn danh; object cache (Redis/Memcached) cho tầng PHP.
• Asset tĩnh dùng versioning qua filename, đặt Cache-Control: public, max-age=31536000, immutable.
• HTML public: Cache-Control: public, s-maxage=1800, max-age=60, stale-while-revalidate=120 tùy traffic.
• Private routes: Cache-Control: private, no-store hoặc bypass hoàn toàn.
• Chuẩn hoá cookie: chỉ giữ cookie cần cho chức năng, loại cookie không ảnh hưởng rendering khỏi cache-key.

Quy trình triển khai tránh “bão miss”

1. Deploy → purge có chọn lọc theo tag/surrogate key.
2. Pre-warm: crawl sitemap/top URLs bằng tốc độ giới hạn.
3. Quan sát hit ratio và origin RPS 15–30 phút đầu; chỉ roll back nếu hit không phục hồi.
4. Log cache-key và Vary để kiểm tra phân mảnh.

Kết luận

Cache chỉ nhanh khi đúng thiết kế. Sai TTL, sai cache-key, sai route policy có thể khiến hệ thống chậm và tốn tài nguyên hơn cả không cache. Hãy ưu tiên phân loại route, thống nhất nơi tối ưu tài nguyên, kiểm soát purge và theo dõi hit ratio. Làm đúng, bạn sẽ có TTFB ổn định, tải origin giảm mạnh và UX mượt mà ngay cả khi traffic tăng đột biến.