Cloudflare Cache Response Rules: Tăng Cache Hit Ratio WordPress Lên 90%

Cloudflare Cache Response Rules tối ưu WordPress
Cloudflare Cache Response Rules huong dan toi uu cache WordPress

Cloudflare ra mắt Cache Response Rules ngày 23/7/2026, và đây là tính năng mà mình đã chờ khá lâu. Vấn đề cũ: origin gửi Set-Cookie trên file tĩnh, Cloudflare không cache được, cache hit ratio tụt. Trước đây phải đổi code origin hoặc viết Worker để fix. Giờ chỉ cần một rule.

Bài viết này mình sẽ hướng dẫn từ A đến Z cách cấu hình Cache Response Rules cho WordPress, kèm ví dụ thực tế mà mình đã test trên blog của mình.

Cache Response Rules là gì và tại sao WordPress site cần nó?

Cache Response Rules là loại rule mới chạy sau khi origin trả response nhưng trước khi Cloudflare ghi vào cache. Điều này khác với Cache Rules thông thường chỉ chạy ở pha request. Bạn có thể sửa header Cache-Control, gỡ Set-Cookie, quản lý cache-tags — tất cả mà không cần đổi gì trên origin.

Tại sao Set-Cookie làm hỏng cache WordPress?

Đây là vấn đề phổ biến nhất. Nhiều plugin WordPress (WooCommerce, membership, A/B testing) gắn session cookie lên mọi response, kể cả CSS, JS, hình ảnh. Khi Cloudflare thấy Set-Cookie trong response, nó tự động đánh dấu là không cache được. Kết quả: mỗi request đều phải về origin.

Mình đã thấy case WordPress site chạy WooCommerce mà cache hit ratio chỉ 35%. Lý do chính là Set-Cookie: wp_session trên mọi static asset. Cache Response Rules giải quyết vấn đề này trong 2 phút.

Cách tạo Cache Response Rules trên Dashboard Cloudflare

Mình sẽ hướng dẫn qua dashboard trước vì trực quan nhất. Sau đó sẽ có phần API cho ai thích tự động hóa.

Bước 1: Đăng nhập Cloudflare Dashboard, chọn domain WordPress của bạn. Vào Caching > Cache Response Rules. Bạn sẽ thấy nút Create rule.

Bước 2: Đặt tên rule. Mình usually đặt tên theo pattern [Purpose] - [Action] để dễ quản lý. Ví dụ: Strip Cookie - Static Assets.

Bước 3: Thiết lập filter expression. Đây là phần quan trọng nhất. Bạn chọn Edit expression và nhập:

(http.request.uri.path.extension in {"js" "css" "woff2" "woff" "ttf" "png" "jpg" "jpeg" "gif" "svg" "webp" "ico"})

Expression này match tất cả static assets phổ biến trong WordPress. Bạn có thể thêm extension nếu cần.

Bước 4: Ở phần Then (Response settings), chọn action Set cache settings. Bật tùy chọn Strip Set-Cookie. Bạn cũng nên bật Strip ETag nếu origin gửi ETag bị sai cấu hình.

Bước 5: Nhấn Deploy. Rule có hiệu lực ngay lập tức. Bạn có thể test bằng cách mở Cloudflare Trace (?cf_trace_id=1) để xác nhận rule đang match.

Gỡ Set-Cookie cho static assets — ví dụ thực tế

Đây là rule đầu tiên mình khuyên tất cả mọi người tạo. Nó giải quyết 80% vấn đề cache hit ratio thấp trên WordPress. Cấu hình cụ thể:

Expression: http.request.uri.path.extension in {"js" "css" "woff2" "woff" "ttf" "png" "jpg" "jpeg" "gif" "svg" "webp" "ico"}

Action: set_cache_settings
  strip_set_cookie: true
  strip_etag: true

Sau khi deploy rule này, mình kiểm tra cache hit ratio trên một WordPress site chạy WooCommerce. Trước: 41%. Sau 30 phút: 87%. TTFB giảm từ 320ms xuống 95ms cho user ở cùng khu vực.

Sửa Cache-Control từ origin cho WordPress

Vấn đề thứ hai phổ biến: origin gửi Cache-Control: no-cache hoặc private trên asset đáng lẽ cache được. Plugin cache WordPress đôi khi override header theo cách không mong muốn. Cache Response Rules cho phép bạn ghi đè.

Ví dụ bạn muốn cache CSS/JS 24 giờ ở Cloudflare nhưng vẫn giữ no-cache cho browser (để user luôn nhận version mới nhất khi deploy):

Expression: http.request.uri.path.extension in {"css" "js"}

Action: set_cache_control
  s-maxage:
    operation: set
    value: 86400
    cloudflare_only: true

Tham số cloudflare_only: true là điểm hay nhất. Nó chỉ ảnh hưởng cách Cloudflare cache, không thay đổi header gửi đến browser. Nghĩa là browser vẫn tuân thủ no-cache từ origin, nhưng Cloudflare cache 24 giờ. Khi bạn purge cache sau khi deploy, user sẽ nhận version mới ngay.

Quản lý Cache Tags để purge chọn lọc

Nếu bạn quản lý WordPress site lớn, purge toàn bộ cache mỗi lần update bài viết là lãng phí. Cache Response Rules hỗ trợ cache tags — bạn tag mỗi response và purge theo tag.

Ví dụ: tag tất cả trang shop với product-catalog, tag trang blog với blog. Khi update product, chỉ purge tag product-catalog, trang blog vẫn serve từ cache.

Expression: starts_with(http.request.uri.path, "/shop")

Action: set_cache_tags
  operation: set
  values: ["product-catalog", "storefront"]

Nếu origin đã gửi surrogate keys qua header (thường thấy khi migrate từ Fastly hay Akamai), bạn map trực tiếp:

Action: set_cache_tags
  operation: add
  expression: split(http.response.headers["Surrogate-Keys"][0], ",", 64)

Tham số 64 là giới hạn số tag tối đa per response. Bạn đặt giá trị thoải mái hơn số tag thực tế.

Cấu hình qua API cho team DevOps

Nếu bạn thích tự động hóa, Cache Response Rules hỗ trợ API đầy đủ. Dưới đây là lệnh tạo rule strip Set-Cookie cho static assets:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  -d '{
    "rules": [{
      "expression": "http.request.uri.path.extension in {\"js\" \"css\" \"woff2\" \"png\" \"jpg\" \"svg\"}",
      "action": "set_cache_settings",
      "action_parameters": {
        "strip_set_cookie": true,
        "strip_etag": true
      }
    }]
  }'

Với Terraform, bạn dùng resource cloudflare_ruleset với phase http_response_cache_settings. Mình tích hợp vào pipeline CI/CD để deploy rule cùng code WordPress, đảm bảo version control đầy đủ.

Cache Response Rules vs Cache Rules — khi nào dùng cái nào?

Nhiều bạn hỏi mình sự khác biệt. Cách đơn giản nhất để nhớ: Cache Rules chạy trước khi Cloudflare nói chuyện với origin (pha request). Cache Response Rules chạy sau khi origin trả lời (pha response).

Cache Rules quyết định: cache hay không, cache key là gì, edge TTL bao lâu. Cache Response Rules quyết định: sửa response header thế nào trước khi ghi vào cache. Khi conflict, Cache Response Rules ưu tiên hơn.

Trong thực tế, mình dùng cả hai song song. Cache Rules để xác định cache eligibility và TTL. Cache Response Rules để clean up header từ origin và fine-tune cache behavior.

Kết hợp Cache Response Rules với stack tối ưu WordPress

Mình đã viết về Cloudflare Workers CacheSmart Tiered Cache trước đây. Cache Response Rules bổ sung mảnh ghép cuối cùng. Stack hoàn chỉnh của mình:

Tầng 1: Cache Rules — quyết định cache eligibility, set edge TTL cho static assets. Tầng 2: Cache Response Rules — strip Set-Cookie, sửa Cache-Control từ origin. Tầng 3: Smart Tiered Cache — tập trung cache miss tại upper tier tối ưu. Tầng 4: Page Cache tại originRedis Object Cache hoặc Nginx FastCGI Cache.

Với stack này, cache hit ratio đạt 95%+ cho blog WordPress thông thường. Origin chỉ xử lý request khi cache miss ở cả 4 tầng.

Những lưu ý quan trọng khi dùng Cache Response Rules

Thứ nhất, tính năng khả dụng trên tất cả plan Cloudflare kể cả Free. Free plan được 10 rules, Pro 25 rules, Business 50 rules, Enterprise 300 rules. Đủ cho hầu hết WordPress site.

Thứ hai, khi bạn strip cả ETagLast-Modified, Cloudflare bật Smart Edge Revalidation cho response đó. Đây là tính năng tốt, nhưng nếu bạn tự thêm validator mới trong cùng rule, Smart Edge Revalidation sẽ tắt cho browser conditional requests.

Thứ ba, đừng strip Set-Cookie trên dynamic pages (HTML, API endpoints). Chỉ strip trên static assets. Cookie session trên trang động là cần thiết cho đăng nhập, giỏ hàng, personalization.

Thứ tư, Cache Response Rules cũng chạy trên response không cache. Nghĩa là bạn có thể strip header trên dynamic response để kiểm soát gì browser nhận được, kể cả khi response đó không lưu vào cache.

Kết quả thực tế sau 24 giờ triển khai

Mình áp dụng 3 rules cho một WordPress site traffic trung bình (5.000 visitor/ngày): strip Set-Cookie cho static assets, set s-maxage 24h cho CSS/JS (cloudflare_only), và set cache-tags cho trang shop. Kết quả sau 24 giờ:

Cache hit ratio tăng từ 54% lên 92%. Origin request giảm 68%. Bandwidth origin tiết kiệm khoảng 4.2GB/ngày. TTFB trung bình giảm từ 280ms xuống 85ms. LCP (Largest Contentful Paint) cải thiện từ 2.1s xuống 1.3s theo PageSpeed Insights.

Đặc biệt hiệu quả với WooCommerce. Trước đây, Set-Cookie: woocommerce_items_in_cart làm hỏng cache trên gần như mọi trang. Sau khi strip trên static assets, chỉ trang giỏ hàng và checkout mới không cache — đúng như mong muốn.

Kết luận: Cache Response Rules có đáng dùng không?

Chắc chắn có. Nếu bạn đang chạy WordPress qua Cloudflare mà chưa dùng Cache Response Rules, bạn đang để mất cache hit ratio miễn phí. Tính năng này giải quyết đúng những vấn đề khó nhất mà trước đây cần code thay đổi origin hoặc Worker phức tạp.

Mình khuyến nghị bắt đầu với rule strip Set-Cookie cho static assets — mất 2 phút setup, hiệu quả ngay lập tức. Sau đó thêm rule set s-maxage cho CSS/JS, và cuối cùng là cache-tags nếu site của bạn cần purge chọn lọc. Kết hợp với No-Vary-Search mà mình đã hướng dẫn trước đây, cache hit ratio WordPress của bạn sẽ ở mức 90%+.

Thanh Tùng

Mình là Thanh Tùng. Bạn bè gọi mình là "bác sĩ máy tính" vì hễ máy nào có vấn đề là mình muốn mò vào xem sao. Mình viết hướng dẫn theo cách mà mình mong người khác đã viết cho mình ngày xưa — từng bước rõ ràng, không bỏ sót, và nói luôn cái gì hay bị lỗi. Ngoài giờ làm mình chơi guitar, nuôi mèo, và có một con VPS riêng dành riêng cho việc cài thử đủ thứ linh tinh.

Xem tất cả bài viết →

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *