Application Performance Updates & Release Notes

Your origin can serve different responses for the same URL — different languages based on Accept-Language, or different formats based on Accept — by returning a Vary response header. Cloudflare's cache now honors that header directly in Cache Rules, so the same URL can hold multiple cached versions and each request is matched to the right one. Content that previously had to bypass cache to stay correct can now be cached, following standard HTTP caching behavior.

What changed

Your origin now decides which request headers matter by listing them in its Vary response, and you control how Cloudflare treats each one. When you have enabled Vary using a cache rule and a response includes a Vary header, the request headers listed become part of the cache key.

For each header your origin varies on, choose one of three actions:

Action
Behavior
Best for

• normalize
  Converts equivalent header values to the same cache key value before matching, collapsing redundant versions.
  Most Accept, Accept-Language, and Accept-Encoding use cases.

• passthrough
  Uses the raw header value to select the cached version and forwards it to the origin unchanged.
  When byte-for-byte differences in the header value should create versions.

• bypass
  Bypasses cache whenever this header name appears in the origin's Vary response.
  Per-user values, or headers with too many possible values to cache safely.

Benefits

Higher cache hit ratios: normalize treats semantically equivalent headers as one version. For example, Accept-Language: en-US, fr;q=0.8 and Accept-Language: fr;q=0.8, en-GB both resolve to the same cache key, so you serve more requests from cache instead of the origin.

Correct content negotiation: Requests always receive the cached version that matches their headers, so language and format variants stay accurate.

No origin or Worker changes required: If your origin already sends Vary, you configure the behavior entirely in Cache Rules.

Standards-aligned: Cache key calculation follows RFC 9111, and Vary: * continues to bypass cache as required by RFC 9110.

Availability

Vary in Cache Rules is available on all plans (Free, Pro, Business, and Enterprise). For per-request control in Workers subrequests, use the cf.vary property.

Get started

Configure Vary in the Cloudflare dashboard under Caching > Cache Rules, or through the Rulesets API. To learn how Vary affects cache keys and how each action works, refer to Vary and the Cache Rules Vary setting.

Cloudflare now accepts ML-DSA (FIPS 204) post-quantum certificates on the connection between Cloudflare's edge and your origin server. Combined with our existing X25519MLKEM768 key agreement, this lets you establish end-to-end post-quantum authentication on the Cloudflare-to-origin connection.

ML-DSA is supported in two origin-facing features:

Authenticated Origin Pulls (AOP) — upload an ML-DSA client certificate that Cloudflare will present during the mTLS handshake to your origin. Available at both zone-level and per-hostname scopes.

Custom Origin Trust Store (COTS) — upload an ML-DSA certificate authority that Cloudflare will trust when validating your origin server certificate under Full (strict) encryption mode.

Refer to Post-quantum signatures for certificate generation and setup guidance, and to PQC in Cloudflare products for the current post-quantum deployment status across Cloudflare.

Cloudflare now enforces DNS records quotas at the account level for Enterprise accounts. Instead of a per-zone limit, these accounts have a quota on the total number of records across all of their zones, letting you distribute records across your zones however you like — regardless of each zone's plan. Public and internal zones are counted separately, each with a default quota of 1,000,000 records.

Accounts without an account-level quota are unaffected: existing per-zone quotas behave exactly as before.

For more details, refer to DNS records quota.

What to expect in your analytics

Cloudflare now returns a BYPASS cache status whenever a response is not cacheable, instead of the previous mix of BYPASS and MISS that depended on why Cloudflare chose not to cache the response.

There are multiple reasons Cloudflare may refuse to cache a response — for example, the response exceeds the maximum cacheable file size for your plan, the origin sends Cache-Control: no-cache, private, or max-age=0, the response includes a Set-Cookie header, or the request includes an Authorization header.

Previously, only some of these conditions returned BYPASS. Others — such as responses exceeding the maximum cacheable file size — returned MISS on every request, regardless of whether Origin Cache Control was on or off. Because the response could never be cached, every subsequent request also returned MISS, which looked indistinguishable from a broken cache and made it hard to tell whether Cloudflare was trying and failing to cache the asset or had deliberately chosen not to cache it.

BYPASS now consistently signals that Cloudflare refused to cache the response, regardless of the reason. MISS is reserved for cacheable responses that simply were not in the local cache at request time.

After this change rolls out, you should see:

• MISS rate decreases: Uncacheable responses no longer count as cache misses.
• BYPASS rate increases: These same responses are now reported as bypasses.
• Cache hit ratio increases: Hit ratio calculations no longer include uncacheable traffic that could never have been cached, giving you a more accurate view of cache effectiveness.

Your total request volume and origin traffic are unchanged — only the cache status label is different.

Browser cache TTL behavior is preserved

The cache status label is the only thing changing — browser cache TTL handling for any given response is identical to what it was before:

• Responses that historically returned MISS because Cloudflare refused to cache them (for example, responses over the maximum cacheable file size) now return BYPASS, but continue to have browser cache TTL applied — exactly as they did when they were labeled MISS.
• Responses that historically returned BYPASS and skipped browser cache TTL continue to skip browser cache TTL.

In both cases, the decision to apply browser cache TTL depends on the underlying reason Cloudflare did not cache the response, not on the new BYPASS label.

Starting today, everyone can opt in to a refreshed DNS records page in the Cloudflare dashboard. Over the coming weeks, the new experience will become the default for Free plan users first, followed by paid plans.

What is new

Better table experience: resizable and hideable columns, row pinning, advanced filters with logical operators (AND/OR), configurable pagination, and expanded input fields so long values are no longer cut off.

First-class mobile experience: responsive layout with a touch-friendly, card-based UI and compact controls for small screens.

DNS quick reference: bite-sized explainers for DNS, proxy status, and TTL, available directly in the product to help users configure records without leaving the page.

Modern frontend: a refactor onto Cloudflare's new UI framework that improves performance and lays the foundation for future improvements.

Rollout plan

Dates are subject to change based on feedback received during the rollout.

20 May - 05 June: ramped rollout to Free, then Pro and Business plans.

08 June - 03 July: ramped rollout to Enterprise plans.

Share your feedback

Once the new experience is turned on for your account, look for the feedback link at the top of the DNS records page in the Cloudflare dashboard and let us know what you think. Your input helps us prioritize the next round of improvements.

The /cdn-cgi/rum beacon endpoint now returns 405 Method Not Allowed for non-POST requests instead of 404 Not Found

The response includes an Allow: POST, OPTIONS header per RFC 9110 §15.5.6.

Previously, sending a GET or other non-POST request to this endpoint returned a 404, which was misleading because it suggested the endpoint did not exist. The new 405 response clearly indicates that the endpoint exists but only accepts POST requests.

The Web Analytics beacon (beacon.min.js) already uses POST for all metric submissions, so this change does not affect normal beacon operation. OPTIONS requests for CORS preflight continue to work as before.

For more information, refer to the Web Analytics FAQ.

What this brings

Lower latency: The new proxy reduces per-request overhead through improved connection reuse.

Reduced cache MISSes: Enhanced cache retention improves origin offload.

Better RFC compliance: Caching behavior more closely follows HTTP caching standards.

Foundation for future features: The new architecture enables upcoming improvements to cache functionality and efficiency.

New features

Asynchronous stale-while-revalidate: Every request returns stale content immediately while revalidation happens in the background, instead of the first request after expiry blocking on the origin. Refer to the asynchronous stale-while-revalidate changelog for details.

Unbuffered bypass by default: Responses that bypass cache are streamed directly to the client without buffering, reducing time-to-first-byte for uncacheable content.

Behavioral changes

The new architecture introduces the following behavioral changes to improve RFC compliance and correctness:

• Vary: * results in cache bypass: According to RFC 9110 Section 12.5.5, a Vary header value of * indicates the response varies on factors beyond request headers and must not be served from cache. Cloudflare now bypasses cache for these responses instead of storing them.

• Set-Cookie stripped on MISS and EXPIRED: For cacheable assets, Set-Cookie is now stripped on MISS and EXPIRED responses, not only on HITs.

• Floating-point TTL values: Floating-point time-to-live values (for example, max-age=1.5) are rounded down to the nearest integer instead of being rejected as invalid.

What's next

A deeper look at the new cache proxy is coming soon to the Cloudflare blog. For background on the underlying framework, read:

• Open sourcing Pingora: our Rust framework for building programmable network services
• How we built Pingora, the proxy that connects Cloudflare to the Internet

What changed

Shared dictionaries (RFC 9842) let an origin compress a response against a previous version of the same resource that the browser already has cached, so only the difference between versions travels over the wire. Shared dictionaries passthrough is now in open beta on all plans.

In passthrough mode, Cloudflare:

• Forwards the Use-As-Dictionary and Available-Dictionary headers between client and origin without modification.
• Treats dcb (Dictionary-Compressed Brotli) and dcz (Dictionary-Compressed Zstandard) as valid Content-Encoding values end to end, without recompressing them.
• Extends the cache key to vary on Available-Dictionary and Accept-Encoding so each delta-compressed variant is cached correctly.

Your origin manages the dictionary lifecycle: deciding which assets are dictionaries, attaching Use-As-Dictionary headers, and producing deltas in response to Available-Dictionary requests. Cloudflare handles the transport and the cache.

In internal testing on a 272 KB JavaScript bundle, the asset shrinks from 92.1 KB with Gzip to 2.6 KB with delta Zstandard against the previous version — a 97% reduction over standard compression — with download times improving by 81–89% versus Gzip.

Shared dictionaries work with browsers that advertise dcb or dcz in Accept-Encoding. Today, this includes Chrome 130 or later and Edge 130 or later.

Get started

Turn on passthrough for your zone with a single API call:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/shared_dictionary_mode" \
--request PATCH \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"value": "passthrough"
}'

You can also turn it on under Speed > Settings > Content Optimization in the Cloudflare dashboard. For full origin setup instructions and a working test recipe, refer to Shared dictionaries, or try the live demo at canicompress.com.

Cloudflare Web Analytics now supports Navigation Type reporting and filtering.

This update allows developers and performance analysts to see how users are navigating between pages — whether through a link click or form submission, a page reload, or using the browser's back/forward buttons — and whether a browser cache hit occurred for these behaviors.

Understanding navigation types is critical for optimizing user experience. For example, if a high volume of your traffic consists of "Back-forward" navigations versus "Back-forward Cache", those visitors are not benefiting from the Back/Forward Cache (bfcache) and therefore are experiencing higher load times due to potentially unnecessary network requests.

The same applies for regular "Navigate" entries — where "Navigate Cache", "Navigate Prefetch Cache" and "Prerender" would provide instant document retrieval — and "Reload", where "Reload cache" would be more optimal.

A high volume of "Reload" entries can also indicate a potential stability problem with your website.

By identifying these patterns, you can tune your browser caching strategies to ensure HTML documents are served instantaneously from local caches rather than requiring a roundtrip to the network.

For more information, refer to Navigation Types.

Key benefits

• Monitor Cache Effectiveness: See how often your site is served from the HTTP cache or bfcache.
• Identify Performance Bottlenecks: Filter by the different types to understand performance opportunity of improving browser cache hit ratio.

Analyze navigation types in the Cloudflare dashboard

You can now find the Navigation Type dimension in the Web Analytics dashboard. You can filter to include/exclude one or more specific types using "equals", "does not equal", "in", or "not in" matchers.

To check the list of popular navigation types, select Page views on the Web Analytics sidebar and scroll down to the bottom:

Warning

Enabling this setting exposes your origin IP addresses and removes all Cloudflare protections — including DDoS mitigation, WAF, caching, and all other proxy-based features — for every zone in your account. Use with extreme caution and only after proper preparations.

Key characteristics

• Account-level — Affects all zones in the account simultaneously with a single API call.
• Non-destructive — Does not modify your DNS records. Disabling the setting restores normal proxy behavior.
• API-only — Available through the API only, not in the Cloudflare dashboard.

What's affected

• Included: Standard proxied A, AAAA, and CNAME records, Load Balancing records, and records matching Worker routes.
• Excluded: Spectrum applications, Cloudflare Tunnel CNAMEs, R2 custom domains, Web3 gateways, and Workers custom domains continue to operate normally.

Before you enable

• Verify your origin servers can handle direct traffic without Cloudflare's caching and filtering.
• Review which origin IPs will become publicly visible through DNS queries.
• Test the API in a staging account before relying on it for incident response.

Availability

Available via API to all Cloudflare customers.

For information on how to use it, refer to Enforce DNS-only developer documentation .

What changed

Cache Response Rules now work with Version Management. You can version response-phase cache settings and promote them through environments, just like Cache Rules and other supported configurations.

Previously, Cache Response Rules were excluded from zone versioning. Any response-phase rule you created applied globally across all environments with no way to test changes in staging first. Cache Rules already supported versioning, but the response phase, where you modify Cache-Control directives, manage cache tags, and strip headers, did not.

Cache Response Rules are now fully integrated with Version Management. You can create or modify response-phase rules within a version, and those changes stay scoped to that version until promoted.

Benefits

Safe rollout of cache behavior changes: Test response-phase rules in a staging environment before promoting to production. Catch unintended caching side effects early.

Parity with Cache Rules: Cache Response Rules now follow the same versioning workflow as Cache Rules, so you can manage all cache configuration through a single promotion pipeline.

Independent environment control: Run different response-phase cache settings per environment. For example, strip Set-Cookie headers in staging to validate cacheability without affecting production traffic.

Get started

Configure Cache Response Rules in the Cloudflare dashboard under Caching > Cache Rules, or via the Rulesets API. For more details, refer to the Cache Response Rules documentation and the Version Management documentation.

You can now achieve higher cache HIT rates and reduce origin load for origins hosted on public cloud providers with Smart Tiered Cache. By setting a cloud region hint for your origin, Cloudflare selects the optimal upper-tier data center for that cloud region, funneling all cache MISSes through a single location close to your origin.

Previously, Smart Tiered Cache could not reliably select an optimal upper tier for origins behind anycast or regional unicast networks commonly used by cloud providers. Origins on AWS, GCP, Azure, and Oracle Cloud would fall back to a multi-upper-tier topology, resulting in lower cache HIT rates and more requests reaching your origin.

How it works

Set a cloud region hint (for example, aws/us-east-1 or gcp/europe-west1) for your origin IP or hostname. Smart Tiered Cache uses this hint along with real-time latency data to select a primary upper tier close to your cloud region, plus a fallback in a different location for resilience.

• Supported providers: AWS, GCP, Azure, and Oracle Cloud.
• All plans: Available on Free, Pro, Business, and Enterprise plans at no additional cost.
• Dashboard and API: Configure from Caching > Tiered Cache > Origin Configuration, or use the API and Terraform.

Get started

To get started, enable Smart Tiered Cache and set a cloud region hint for your origin in the Tiered Cache settings.

You can now manage mutual TLS (mTLS) and Bring Your Own Certificate Authority (BYO CA) configurations directly from the Cloudflare dashboard — no API required.

Previously, these advanced workflows required the Cloudflare API. The following are now available in the dashboard:

• AOP certificate management — Upload and manage your own certificate authorities for Authenticated Origin Pulls (AOP) directly from the dashboard.
• BYO Client mTLS certificate management — Upload and manage your own CA certificates for client mTLS enforcement without needing API access.
• CDN hostname to client mTLS certificate mapping — Associate client mTLS certificates with specific hostnames directly from the dashboard.