Ngày 1/9/2026, Cloudflare đăng một bài kỹ thuật rất đáng đọc: họ prototype hệ thống Cache Transcoding, nén toàn bộ asset trong cache bằng thuật toán Zstandard (zstd) ngay bên trong proxy Pingora, và kết quả là dung lượng đĩa giảm còn khoảng 1/3 so với ban đầu. Giá RAM và ổ cứng đang tăng vọt, nên mỗi byte tiết kiệm được trên cache đều có ý nghĩa lớn.
Nhưng bài viết này không chỉ dành cho dân vận hành CDN. Nếu mình đang chạy website WordPress trên VPS với Nginx hoặc OpenLiteSpeed, có cache page bằng FastCGI hoặc Redis, thì tư duy “nén ở tầng lưu trữ, giải nén khi phục vụ” áp dụng được ngay cho server của mình. Trong bài này mình sẽ tóm tắt cách Cloudflare làm, sau đó hướng dẫn từng bước bật zstd cho chính server WordPress của bạn.
Zstandard là gì và vì sao Cloudflare chọn nó thay vì gzip hay Brotli?
Zstandard (zstd) là thuật toán nén không mất dữ liệu do Yann Collet phát triển tại Facebook, open source từ năm 2016. Điểm mạnh của zstd là cân bằng rất tốt giữa tỉ lệ nén và tốc độ: theo số đo của chính Cloudflare, zstd nén nhanh hơn Brotli khoảng 42% trong khi kích thước file gần bằng nhau, và nhỏ hơn gzip khoảng 11,3% ở tốc độ tương đương. Với hệ thống cache phải xử lý hàng tỷ request, tốc độ encode và decode quan trọng ngang kích thước file.
Cloudflare dùng mức nén zstd level 3 — mức mặc định, đủ tốt về tỉ lệ nén mà không biến quá trình ghi cache thành điểm nghẽn CPU. Đây cũng là mức mình khuyên các bạn dùng trên server của mình.
Cloudflare đã làm gì với Cache Transcoding?
Cách hoạt động rất gọn. Khi một response trúng cache miss, proxy Pingora nén body bằng zstd trước khi ghi xuống đĩa, và metadata của cache ghi lại rằng object này đang được lưu dạng nén. Khi có request tới, proxy đọc object nén từ đĩa, giải nén, rồi trả về cho client dạng gốc. Với Tiered Cache, object di chuyển giữa các data center ở dạng nén, chỉ giải nén ở chặng cuối gần người dùng.
Không phải mọi thứ đều đáng nén. Cloudflare chỉ transcode các response thỏa mãn đồng thời: status 200 OK, không có header Content-Encoding, Content-Type là văn bản nén được (HTML, JSON, CSS, JS), và Content-Length tối thiểu 4 KiB. Ảnh, video, font chiếm 63,3% băng thông nhưng đã nén sẵn rồi, nén lần nữa chỉ tốn CPU vô ích. Phần văn bản chiếm 67,3% request nhưng chỉ 22,3% bytes — và trong đó khoảng 71% về origin dạng chưa nén.
Kết quả đo đạc của Cloudflare ra sao?
Trong chiến dịch test hơn 1 triệu request trên 10 cache server, các asset đủ điều kiện nén được khoảng 2,83 lần. Chi phí: encode tốn khoảng 4,31 ns mỗi byte (tương đương 232 MB/s) nhưng chỉ trả một lần duy nhất khi object vào cache. Decode tốn 1,56 ns mỗi byte (641 MB/s) nhưng phải trả mỗi lần phục vụ. Vì asset được phục vụ nhiều lần hơn nhiều so với số lần ghi cache, bài toán là lời.
Một phát hiện thú vị: Cloudflare ban đầu định chỉ nén nội dung “nóng” (được truy cập nhiều), nhưng cách này kém hiệu quả hơn nén toàn bộ văn bản đủ điều kiện từ 4 KiB trở lên. Ngưỡng 4 KiB loại bỏ hàng loạt request tí hon mà chỉ bỏ sót khoảng 1% bytes đủ điều kiện.
Bài học gì cho người chạy website WordPress?
Mình rút ra ba điều đáng giá. Thứ nhất, đừng nén thứ đã nén rồi — ảnh WebP, AVIF, video, font sẽ không nhỏ đi thêm mà còn tốn CPU. Thứ hai, ngưỡng kích thước quan trọng — nén những chunk vài trăm byte chỉ thêm overhead. Thứ ba, nén một lần ở tầng lưu trữ, hưởng lợi nhiều lần — đúng tinh thần mà page cache WordPress đang làm, chỉ thêm lớp nén nữa thôi.
Trên thực tế, một trang WordPress điển hình có HTML document 50-300 KB, JSON của REST API và file CSS/JS cũng toàn văn bản. Đây chính là nhóm asset mà Cloudflare gọi là “compressible text” — và bạn có thể tự làm điều tương tự trên server của mình.
Làm thế nào để bật zstd cho Nginx cache trên VPS WordPress?
Bước 1 — cài module nén zstd cho Nginx. Nếu bạn dùng Ubuntu/Debian, bản nginx từ repo nginx.org hoặc các bản build phổ biến thường đã kèm module. Kiểm tra nhanh:
nginx -V 2>&1 | grep -o http_zstd_moduleNếu không có, bạn cần cài bản Nginx có build module zstd, ví dụ qua gói của distribution hoặc tự build với --add-module từ zendtech/zstd-nginx.
Bước 2 — thêm cấu hình vào block server của bạn:
# nén zstd cho response trả về client
zstd on;
zstd_comp_level 3;
zstd_types text/plain text/css text/javascript application/javascript application/json text/html application/xml;
# và đừng quên gzip làm fallback cho client cũ
gzip on;
gzip_comp_level 5;
gzip_types text/css text/javascript application/javascript application/json;Bước 3 — nếu bạn đang dùng FastCGI cache như trong bài hướng dẫn cấu hình Nginx FastCGI Cache cho WordPress của mình trước đây, phần cache tự nó lưu response theo dạng gốc. Muốn tiết kiệm đĩa như Cloudflare, hướng đi đơn giản nhất là để Nginx nén ở tầng response (bước 2) kết hợp filesystem nén zstd: bật compress=zstd cho phân vùng cache qua mount option, hoặc dùng Btrfs với compress-force=zstd:3 cho thư mục cache. Cách này áp dụng nguyên tắc “nén khi lưu, giải nén khi đọc” mà không phải sửa gì trong Nginx.
OpenLiteSpeed và LiteSpeed hỗ trợ zstd ra sao?
Nếu bạn dùng OpenLiteSpeed, tin vui là máy chủ này hỗ trợ brotli tích hợp sẵn còn zstd thì tùy phiên bản. Trong Admin Console, vào Configuration > Server > Tuning, bạn chỉnh mức nén và bật compression cho các MIME type văn bản như ở trên. Nguyên tắc vẫn y hệt Cloudflare: chỉ nén text, bỏ qua ảnh và video, mức nén vừa phải để không ăn CPU.
Với tầng CDN, nếu site của bạn đã proxy qua Cloudflare, phía client sẽ tự động nhận brotli hoặc zstd tùy trình duyệt. Phần việc còn lại của bạn là đảm bảo origin trả Content-Encoding hợp lý — mình đã viết chi tiết trong bài hướng dẫn bật Brotli cho WordPress từ Nginx đến Cloudflare.
Có nên chuyển từ gzip sang zstd ngay không?
Mình nghĩ nên làm theo thứ tự ưu tiên này. Nếu chưa bật bất kỳ nén nào: bật gzip trước, đó là mức tối thiểu. Nếu đã có gzip và muốn tối ưu thêm: thêm brotli hoặc zstd cho tầng response client — cả hai đều tốt, zstd nhanh hơn khi encode. Còn nếu lo về dung lượng đĩa cache hoặc băng thông nội bộ giữa các server: đó là chỗ zstd tỏa sáng đúng như Cloudflare đã chứng minh. Đo trước, đo sau bằng curl -sI -H 'Accept-Encoding: zstd' https://domain-cua-ban | grep -i content-encoding để biết mình đang ở đâu.
Cuối cùng, đừng quên benchmark Core Web Vitals sau khi thay đổi. Nén đúng cách giúp giảm bytes nhưng chọn mức nén quá cao trên VPS yếu có thể làm TTFB tệ đi. Mức 3 của zstd là điểm khởi đầu an toàn — chính Cloudflare cũng chọn mức đó cho hàng petabyte cache của họ.
Kết luận
Công bố của Cloudflare về Cache Transcoding là minh chứng đẹp rằng một ý tưởng cũ — nén dữ liệu — vẫn còn dư địa tối ưu lớn khi áp dụng đúng chỗ: trong tầng lưu trữ cache, chỉ với văn bản đủ lớn, ở mức nén vừa phải. Người chạy WordPress hoàn toàn có thể mượn nguyên tắc này: bật zstd/brotli cho response, nén filesystem chứa cache, và bỏ qua những thứ đã nén sẵn. Chi phí CPU nhỏ, lợi ích lưu trữ và băng thông kéo dài suốt vòng đời cache. Nếu bạn làm theo hướng dẫn trên mà gặp vướng chỗ nào, cứ để lại bình luận, mình sẽ replied từng bước.
