Deploy nhanh hơn, cache chết sớm hơn

Agent crawl liên tục, team deploy liên tục — băng thông đang chảy máu mà ít ai để ý. Shared dictionary có thể là lớp nén còn thiếu.

Tháng 3 năm 2026, gần 10% tổng request trên mạng lưới Cloudflare đến từ agent — tăng khoảng 60% so với cùng kỳ năm ngoái. Cùng lúc đó, web page trung bình nặng hơn 6–9% mỗi năm suốt thập kỷ qua. Hai con số này riêng lẻ thì chẳng ai giật mình. Ghép lại, bạn có một đường đứt gãy đang mở rộng ngay dưới chân hạ tầng web.

Mình không nói về GPU hay model serving — cuộc đua đó ai cũng thấy. Chuyện ít người để ý hơn: mỗi lần team bạn deploy, bundler tạo filename mới, browser và agent không nhận ra file cũ, rồi cả thế giới download lại từ đầu. Compression truyền thống nén từng file riêng lẻ rất tốt, nhưng không biết client đã có gì. Kết quả: bandwidth bị đốt cho những byte gần như giống hệt lần trước.

Cloudflare vừa hé lộ bản beta shared compression dictionary — cơ chế nén dựa trên delta. Không phải công nghệ mới hoàn toàn, nhưng thời điểm nó xuất hiện thì rất đáng bóc.

Gzip nén file, nhưng không nén sự trùng lặp

Hầu hết team đang dùng Brotli hoặc gzip — hai cơ chế nén đã chứng minh giá trị suốt nhiều năm. Vấn đề là chúng chỉ nhìn từng file một. Mỗi response được nén độc lập, không biết response trước đó client đã nhận chứa gì.

Hiểu nôm na: bạn gửi cho đồng nghiệp một tài liệu 50 trang. Hôm sau sửa 2 dòng, rồi gửi lại… cả 50 trang. Gzip giúp nén cái file 50 trang đó nhỏ hơn, nhưng không giúp bạn chỉ gửi 2 dòng thay đổi.

Với tần suất deploy ngày càng dày — nhờ AI-assisted coding, CI/CD tự động — cái vòng "sửa một dòng → bundler re-chunk → filename mới → client download lại toàn bộ" lặp lại nhiều lần mỗi ngày. Nhân thêm lượng agent crawl không ngừng, lưu lượng thừa tích tụ như trầm tích: mỗi lớp mỏng, nhưng chồng lên nhau thì nặng.

Shared dictionary — gửi diff thay vì gửi nguyên bản

Shared compression dictionary (từ điển nén dùng chung) hoạt động theo logic khác hẳn. Thay vì nén file từ con số không, nó cho phép browser nói với server: "Tôi đang giữ bản X, cho tôi phần khác biệt thôi."

Server so sánh bản mới với bản cũ (dictionary), rồi chỉ gửi delta — phần thực sự thay đổi. Với những bản deploy chỉ sửa vài dòng code, lượng data truyền tải giảm rõ rệt so với tải lại toàn bộ bundle.

Kỹ thuật này dựa trên hai cơ chế:

Cả hai đều không mới — delta compression đã tồn tại từ thời rsync. Điều khác là nó đang được tích hợp vào tầng CDN và trình duyệt theo chuẩn web mở (Compression Dictionary Transport), nghĩa là bạn không cần tự build pipeline riêng.

Điều đáng giữ lại: tư duy "diff-first" cho hạ tầng

Đối với team Việt Nam đang vận hành sản phẩm có frontend nặng — SPA, dashboard, admin panel — đây là lúc đặt câu hỏi đúng.

Kịch bản 1: Giả sử team bạn 4 người, deploy frontend 3–5 lần/ngày qua CI/CD. Mỗi lần deploy, JS bundle đổi filename. Sản phẩm có vài nghìn user active, mỗi lần deploy trigger vài nghìn lượt re-download toàn bộ bundle. Với shared dictionary, phần lớn những lượt đó chỉ cần tải delta — tiết kiệm bandwidth, cải thiện load time cho user quay lại.

Kịch bản 2: Bạn đang expose API hoặc trang web mà agent truy cập thường xuyên — crawler AI, chatbot, tool automation. Agent thường không cache thông minh như browser: chúng fetch full page mỗi lần. Shared dictionary ở tầng CDN giảm tải cho origin server mà không cần bạn viết thêm dòng code nào.

Dịch sang tiếng builder: nếu bạn đang trả tiền bandwidth theo GB và deploy thường xuyên, đây là một lớp tối ưu nằm giữa "không làm gì" và "tự build CDN riêng". Muốn kiểm chứng nhanh — bật beta trên Cloudflare, đo bandwidth trước/sau qua dashboard, so sánh với tuần trước cùng lượng deploy. Một buổi chiều là đủ để có con số thật.

Điều nên bỏ qua — chưa phải lúc đại tu

Trước khi lao vào rewrite caching strategy, vài điều cần tỉnh táo:

Một, shared dictionary đang ở giai đoạn beta trên Cloudflare và chỉ được hỗ trợ trên một số trình duyệt (Chrome đi trước, còn lại đang theo). Nếu user của bạn chủ yếu dùng browser cũ hoặc webview trong app, lợi ích thực tế sẽ thấp hơn kỳ vọng.

Hai, nếu team bạn deploy frontend mỗi tuần một lần và traffic chủ yếu từ người dùng thật (không phải agent), cache-busting truyền thống vẫn ổn. Đừng tối ưu cho vấn đề bạn chưa có.

Ba, đừng nhầm shared dictionary với service worker caching hay HTTP/2 server push — chúng giải quyết bài toán khác. Shared dictionary tập trung vào cross-version compression (nén xuyên phiên bản), không phải offline caching hay prefetch.

Mình thấy nhiều team có phản xạ "công nghệ mới, phải adopt ngay". Nhưng lớp nén này chỉ thực sự tạo khác biệt khi bạn có cả hai điều kiện: deploy thường xuyên VÀ lượng returning visitors hoặc agent traffic đáng kể. Thiếu một trong hai, ROI sẽ mỏng.

Một lớp nén, nhưng đúng chỗ đang kéo giãn

Shared dictionary không phải cuộc cách mạng — nó là một lớp vá đúng vị trí đang chịu lực nhiều nhất của web hiện tại: khoảng cách giữa tốc độ deploy và khả năng cache. Trong thế giới mà agent crawl không ngừng và team ship code mỗi ngày, việc browser phải tải lại toàn bộ bundle chỉ vì filename đổi là một sự lãng phí có hệ thống.

Đôi khi điều đáng tối ưu nhất không phải model mới hay framework mới — mà là những byte thừa đang lặng lẽ đốt tiền mỗi lần bạn bấm "merge".

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo