Tối Ưu Chiến Lược Caching Cloudflare CDN Để Tăng Tốc Độ

Cấu hình một chính sách caching Cloudflare CDN vững chắc là một trong những nhiệm vụ kỹ thuật có tác động lớn nhất để tối ưu tốc độ cho một website doanh nghiệp vào năm 2026. Nhiều nền tảng web gặp phải độ trễ cao vì mọi yêu cầu của người dùng đều phải đi đến máy chủ cơ sở dữ liệu gốc để render trang. Sự phụ thuộc vào origin đó làm chậm các chỉ số tốc độ First Contentful Paint (FCP) và Largest Contentful Paint (LCP), trong khi việc lưu trữ các bố cục trang tĩnh và thành phần asset tại các vị trí edge trên toàn thế giới mang lại các phản hồi nhanh, độ trễ thấp từ vị trí edge gần nhất. Hướng dẫn này phân tích cơ chế caching, các quy tắc Edge Cache TTL và cấu hình bypass cookie động.

[!TIP] Mẹo tối ưu caching: Tránh cache các trang HTML chứa thông tin của người dùng đã đăng nhập. Luôn cấu hình Cache Rules để bỏ qua caching edge khi phát hiện các cookie phiên cụ thể (như cookie WordPress hoặc token xác thực tùy chỉnh) trong header của yêu cầu.

Những điểm chính:

• Caching Cloudflare CDN giảm số lượng truy vấn cơ sở dữ liệu tới máy chủ backend, cắt giảm chi phí hosting.
• Cache Rules cho phép nhà phát triển đặt các giá trị TTL tùy chỉnh dựa trên loại nội dung và thư mục.
• Triển khai các quy tắc Cache Everything đòi hỏi cấu hình bypass cookie phiên để ngăn rò rỉ dữ liệu người dùng.
• Phục vụ các trang tĩnh trực tiếp từ các vị trí edge giúp website vượt qua Core Web Vitals trên thiết bị di động.

Cấu hình caching: Page Rules vs. Cache Rules

Để tận dụng tối đa các pipeline phân phối, bạn phải chọn mô hình điều khiển dashboard phù hợp. Theo các hướng dẫn caching từ Cloudflare Developer Docs , các Page Rules cũ đang được thay thế bằng Cache Rules dạng mô-đun. Do đó, các nhà phát triển nên triển khai các cấu hình sau:

Theo mặc định, các mạng CDN chỉ cache các định dạng media, stylesheet và script. Do đó, bạn phải cấu hình ba tùy chọn asset cốt lõi:

• Caching HTML: Để đạt được tải trang tức thì, bạn phải hướng dẫn CDN cache cấu trúc tài liệu HTML. Do đó, điều này ngăn các truy vấn cơ sở dữ liệu.
• Header Cache-Control: Cấu hình máy chủ backend Symfony hoặc PHP của bạn để gửi các chỉ thị s-maxage tùy chỉnh nhằm hướng dẫn các máy chủ edge lưu trữ các trang trong bao lâu. Ngoài ra, điều này cho phép các quy tắc TTL tùy chỉnh.
• Browser Cache TTL: Đặt thời gian tồn tại cache trình duyệt ngắn hơn (ví dụ 4 giờ) để đảm bảo người dùng nhận được bản cập nhật khi bạn sửa đổi bố cục trang. Do đó, điều này ngăn các vấn đề không khớp bố cục.

Đối với các cổng thông tin web tương tác, bạn không thể cache toàn bộ trang một cách phổ quát. Do đó, bạn phải thiết lập hai quy tắc bypass động:

• Bypass phiên: Xây dựng các quy tắc hướng dẫn CDN bỏ qua caching khi một yêu cầu mang theo cookie xác thực hoặc cookie phiên, để người dùng đã đăng nhập luôn nhận được các phản hồi được cá nhân hóa trong khi khách truy cập ẩn danh vẫn được phục vụ từ edge cache.
• Sắp xếp query string: Cấu hình cache cơ sở dữ liệu edge bỏ qua các biến analytics nhỏ (như thẻ UTM) khi đánh giá các khóa cache. Do đó, điều này ngăn phân mảnh cache.

Để triển khai một chiến lược caching edge cấp doanh nghiệp một cách an toàn, hãy thực hiện chuỗi xác thực kỹ thuật này. Áp dụng bốn bước tối ưu này:

1. Kiểm tra header HTTP: Xác minh rằng máy chủ origin của bạn gửi các header Cache-Control và Vary sạch mà không có khối xác thực.
2. Soạn thảo Cache Rules dạng mô-đun: Cấu hình các Cache Rules mục tiêu để lưu trữ các thư mục danh mục tĩnh trong tối đa 30 ngày.
3. Xây dựng ngoại lệ xác thực: Tạo các quy tắc bỏ qua cache edge khi phát hiện cookie đăng nhập.
4. Triển khai webhook Purge API: Cấu hình các hành động lưu cơ sở dữ liệu để kích hoạt các yêu cầu Purge API tự động khi bạn cập nhật trang.

So sánh hiệu suất: caching edge vs. fetch từ origin

Để minh họa các lợi ích về tốc độ, bảng sau đây trình bày chi tiết các chỉ số tải thực tế:

Điều kiện tiên quyết

Trước khi bạn chạm vào dashboard, hãy đảm bảo bạn đã có sẵn những điều sau:

• Một tên miền đã được proxy qua Cloudflare (thiết lập DNS đám mây cam, không phải xám/chỉ DNS).
• Quyền truy cập vào cấu hình origin của bạn — Nginx, Apache, hoặc lớp ứng dụng — để bạn có thể đặt các header phản hồi.
• Một API token với phạm vi Zone → Cache Purge nếu bạn dự định tự động hóa việc purge. Tạo nó trong My Profile → API Tokens.
• Một cách để kiểm tra header HTTP thô: curl trên dòng lệnh, hoặc tab Network trong Chrome DevTools.
• Một URL staging hoặc một đường dẫn ít lưu lượng mà bạn có thể thử nghiệm trước khi triển khai bất cứ điều gì trên toàn bộ site.

Một gói Free hoặc Pro là đủ để làm theo mọi bước bên dưới. Cache Rules có sẵn trên tất cả các gói, mặc dù một vài tùy chọn cache-key và Tiered Cache thuộc về các cấp cao hơn.

Bước 1: Gửi header Cache-Control chính xác từ origin

Cloudflare chỉ coi một phản hồi là có thể cache được nếu origin của bạn không chủ động cấm điều đó. Lý do phổ biến nhất khiến HTML không bao giờ được cache là một origin trả về header Set-Cookie hoặc một Cache-Control hạn chế trên mỗi yêu cầu.

Đặt các chỉ thị rõ ràng tại origin. Trong Nginx:

1location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
2    add_header Cache-Control "public, max-age=31536000, immutable";
3}
4
5location / {
6    # HTML: short browser life, long shared (edge) life
7    add_header Cache-Control "public, max-age=0, s-maxage=86400";
8}

Chỉ thị s-maxage nhắm vào các cache dùng chung như edge Cloudflare, trong khi max-age=0 giữ cho trình duyệt của khách truy cập luôn revalidate để họ không bao giờ thấy HTML cũ sau một lần deploy. Token immutable trên các asset có fingerprint bảo trình duyệt không bao giờ revalidate chúng.

Đối với một phản hồi do ứng dụng điều khiển (PHP hoặc Symfony), hãy thể hiện cùng một ý định trong code:

1$response->setPublic();
2$response->setMaxAge(0);            // browser
3$response->setSharedMaxAge(86400);  // edge / s-maxage

Các phản hồi được xác thực hoặc cá nhân hóa phải tự loại trừ một cách rõ ràng, nếu không một quy tắc quá rộng có thể phục vụ trang của một người dùng cho người khác:

1Cache-Control: private, no-store

Bước 2: Làm cho HTML đủ điều kiện để cache bằng một Cache Rule

Theo mặc định Cloudflare đánh dấu HTML là DYNAMIC và không bao giờ lưu trữ nó. Để thay đổi điều đó, hãy tạo một quy tắc trong Caching → Cache Rules → Create rule.

Viết một biểu thức khớp với các trang bạn muốn cache trong khi loại trừ mọi thứ động:

1(http.host eq "example.com"
2  and not starts_with(http.request.uri.path, "/wp-admin")
3  and not starts_with(http.request.uri.path, "/cart")
4  and not starts_with(http.request.uri.path, "/checkout")
5  and not starts_with(http.request.uri.path, "/my-account"))

Sau đó đặt các hành động của quy tắc:

• Cache eligibility: Eligible for cache — phiên bản hiện đại tương đương với hành vi “Cache Everything” cũ.
• Edge TTL: Use cache-control header if present, để s-maxage bạn đặt ở Bước 1 thắng; quay lại một giá trị cố định như 1 ngày nếu header vắng mặt.
• Browser TTL: Respect origin.

Bước 3: Thêm một Cookie Bypass để người dùng đã đăng nhập không bao giờ bị cache

Đây là bước mà hầu hết các hướng dẫn bỏ qua, và là bước làm rò rỉ dữ liệu khi họ bỏ qua. Thêm một quy tắc thứ hai, đặt phía trên quy tắc eligibility, buộc một bypass bất cứ khi nào có một cookie phiên thực sự. Cloudflare đánh giá Cache Rules từ trên xuống dưới, vì vậy một quy tắc bypass sớm hơn luôn thắng đối với khách truy cập đã xác thực.

1http.cookie contains "wordpress_logged_in_"
2or http.cookie contains "wp-postpass_"
3or http.cookie contains "woocommerce_items_in_cart"
4or http.cookie contains "comment_author_"

Đặt hành động thành Bypass cache. Đối với các stack không phải WordPress, hãy thay tên cookie bằng định danh phiên của framework của bạn — PHPSESSID, laravel_session, connect.sid, v.v. Giới hạn phạm vi này chặt chẽ: việc khớp một cookie analytics rộng như _ga ở đây sẽ vô tình bypass cache cho cả mọi khách truy cập ẩn danh.

Bước 4: Chuẩn hóa khóa cache

Hai URL chỉ khác nhau bởi một tham số tracking nên chia sẻ một đối tượng cache duy nhất. Bên trong quy tắc eligibility, mở Cache Key → Query String, chọn Ignore specific query string parameters, và liệt kê các khóa analytics:

1utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid

Điều này gộp /pricing?utm_source=newsletter và /pricing?gclid=123 vào một mục cache duy nhất, nâng tỷ lệ hit của bạn thay vì phân mảnh nó qua hàng nghìn khóa gần trùng lặp.

Cách xác minh một Cache HIT hoặc MISS

Đừng bao giờ giả định một quy tắc hoạt động — hãy đo lường nó. Mỗi phản hồi mà Cloudflare phục vụ mang một header cf-cache-status. Yêu cầu cùng một URL hai lần và theo dõi nó thay đổi:

1curl -sI https://example.com/ | grep -i cf-cache-status
2# First request:  cf-cache-status: MISS
3# Second request: cf-cache-status: HIT

Các giá trị bạn sẽ gặp và ý nghĩa của từng giá trị:

Nếu bạn chỉ luôn thấy DYNAMIC, quy tắc eligibility không kích hoạt. Xác nhận tên host trong biểu thức, sau đó kiểm tra rằng origin không gửi Cache-Control: private hoặc một Set-Cookie trên tài liệu HTML.

Các cạm bẫy phổ biến và khắc phục sự cố

• Một Set-Cookie trên mỗi phản hồi. Cloudflare sẽ không cache một phản hồi đặt cookie. Các plugin analytics, token CSRF và công cụ kiểm thử A/B thường gắn một cái vào tài liệu HTML. Chuyển logic đó sang một yêu cầu bất đồng bộ, hoặc loại bỏ header trên các đường dẫn có thể cache.
• BYPASS trên khách truy cập ẩn danh. Hầu như luôn là một quy tắc cookie bypass quá rộng — một cookie chung như _ga khớp với biểu thức của bạn. Hạn chế bypass chỉ với các cookie phiên thực sự.
• Trang cũ sau một lần deploy. Edge TTL đang làm đúng nhiệm vụ của nó; bạn chỉ đơn giản là quên purge. Kích hoạt một purge có mục tiêu khi publish thay vì rút ngắn TTL xuống vài giây.
• Header Vary bị bỏ qua. Cloudflare chỉ vary cache của nó trên Accept-Encoding; nó sẽ không giữ các bản sao riêng cho một Vary: User-Agent hoặc Vary: Cookie tùy ý. Hãy phục vụ markup theo thiết bị thông qua CSS responsive hoặc một Worker thay vì dựa vào Vary.
• Development Mode bị bật. Nó bypass cache trong ba giờ và âm thầm làm cho mọi phản hồi trông không thể cache được. Xác nhận nó đã tắt trước khi bạn kiểm thử.

Cân nhắc cho production và purge tự động

Khi một đường dẫn duy nhất hoạt động chính xác, hãy mở rộng quy tắc ra toàn bộ site trong một khoảng thời gian lưu lượng thấp và theo dõi Caching → Overview để xem tỷ lệ hit của bạn — một site tĩnh lành mạnh nằm thoải mái trên 90%.

Kết nối CMS của bạn để chỉ purge những gì đã thay đổi thay vì toàn bộ zone. Một purge có mục tiêu theo URL giữ cho các trang lân cận vẫn ấm trong cache:

1curl -X POST \
2  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
3  -H "Authorization: Bearer ${CF_API_TOKEN}" \
4  -H "Content-Type: application/json" \
5  --data '{"files":["https://example.com/pricing"]}'

Gọi điều này từ publish hook của bạn để bản cập nhật của một biên tập viên hoạt động trực tuyến trong vài giây trong khi mọi thứ khác vẫn được cache. Đối với các danh mục lớn, hãy nhóm các URL liên quan sau một Cache Tag (Enterprise) hoặc purge theo tiền tố, và bật Tiered Cache để nâng tỷ lệ hit toàn cầu bằng cách định tuyến các miss qua một parent khu vực trước khi chúng từng chạm tới origin của bạn.

Hợp tác với một đơn vị tư vấn Cloudflare tại UK đã được thẩm định

Đưa ra đúng các quyết định caching này bảo vệ các máy chủ origin của bạn và tăng tốc phân phối trang cho mọi khách truy cập. Mecanik cung cấp các dịch vụ kiểm toán SEO kỹ thuật chuyên nghiệp và mở rộng hạ tầng thông qua trang phát triển website của chúng tôi. Chúng tôi chuyên về tích hợp edge Symfony, Cache Rules Cloudflare tùy chỉnh và các triển khai edge-native. Hãy liên hệ với chúng tôi hôm nay để lên lịch cho workshop scoping kỹ thuật của bạn.

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

Cloudflare cdn caching là gì? Cloudflare cdn caching là quá trình lưu trữ các bản sao tĩnh của các trang, hình ảnh và tệp script của website của bạn trên các máy chủ edge nằm khắp thế giới. Cấu hình này cho phép các yêu cầu của người dùng được phục vụ từ máy chủ vật lý gần nhất, giảm thời gian tải của website.

Làm thế nào để cache các trang HTML mà không làm rò rỉ dữ liệu người dùng? Để cache HTML một cách an toàn, hãy cấu hình một Cache Rule với hành động “Bypass Cache” kích hoạt khi các cookie phiên hoặc admin có mặt trong header của yêu cầu. Thiết lập này đảm bảo người dùng cổng thông tin đã đăng nhập luôn fetch nội dung động từ cơ sở dữ liệu origin.

Sự khác biệt giữa Edge TTL và Browser TTL là gì? Edge TTL (Time-To-Live) quy định các máy chủ CDN Cloudflare lưu trữ nội dung của bạn trong bao lâu trước khi yêu cầu một bản sao mới từ máy chủ origin của bạn. Ngược lại, Browser TTL xác định cache trình duyệt cục bộ của khách truy cập giữ các tệp trong bao lâu.

Tại sao caching query string ảnh hưởng đến hiệu suất website? Nếu các query string (như thẻ tracking UTM) không được chuẩn hóa, CDN coi mỗi biến thể là một URL duy nhất, tạo ra các yêu cầu trùng lặp tới máy chủ origin của bạn. Cấu hình chuẩn hóa khóa cache ngăn sự trùng lặp crawl này.

Caching edge có thể cải thiện điểm Core Web Vitals của tôi không? Có, phục vụ các asset HTML và media trực tiếp từ các máy chủ edge giảm thiểu thời gian Time-to-First-Byte (TTFB) và Largest Contentful Paint (LCP). Do đó, chiến lược caching này trực tiếp cải thiện thứ hạng tốc độ trang di động của bạn.