Application Performance Updates & Release Notes

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

Original source

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.

Original source

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:

Original source

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 .

Original source

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.

Original source

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.

Original source

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.

Original source

You can now control how Cloudflare handles origin responses without changing your origin. Cache Response Rules let you modify Cache-Control directives, manage cache tags, and strip headers like Set-Cookie from origin responses before they reach Cloudflare's cache. Whether traffic is cached or passed through dynamically, these rules give you control over origin response behavior that was previously out of reach.

What changed

Cache Rules previously only operated on request attributes. Cache Response Rules introduce a new response phase that evaluates origin responses and lets you act on them before caching. You can now:

• Modify Cache-Control directives: Set or remove individual directives like no-store, no-cache, max-age, s-maxage, stale-while-revalidate, immutable, and more. For example, remove a no-cache directive your origin sends so Cloudflare can cache the asset, or set an s-maxage to control how long Cloudflare stores it.
• Set a different browser Cache-Control: Send a different Cache-Control header downstream to browsers and other clients than what Cloudflare uses internally, giving you independent control over edge and browser caching strategies.
• Manage cache tags: Add, set, or remove cache tags on responses, including converting tags from another CDN's header format into Cloudflare's Cache-Tag header. This is especially useful if you are migrating from a CDN that uses a different tag header or delimiter.
• Strip headers that block caching: Remove Set-Cookie, ETag, or Last-Modified headers from origin responses before caching, so responses that would otherwise be treated as uncacheable can be stored and served from cache.

Benefits

• No origin changes required: Fix caching behavior entirely from Cloudflare, even when your origin configuration is locked down or managed by a different team.
• Simpler CDN migration: Match caching behavior from other CDN providers without rewriting your origin. Translate cache tag formats and override directives that do not align with Cloudflare's defaults.
• Native support, fewer workarounds: Functionality that previously required workarounds is now built into Cache Rules with full Tiered Cache compatibility.
• Fine-grained control: Use expressions to match on request and response attributes, then apply precise cache settings per rule. Rules are stackable and composable with existing Cache Rules.

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 Rules documentation.

Original source

DNS Analytics is now available for customers with Customer Metadata Boundary (CMB) set to EU. Query your DNS analytics data while keeping metadata stored in the EU region.

This update includes:

• DNS Analytics — Access the same DNS analytics experience for zones in CMB=EU accounts.
• EU data residency — Analytics data is stored and queried from the EU region, meeting data localization requirements.
• DNS Firewall Analytics — DNS Firewall analytics is now supported for CMB=EU customers.

Availability

Available to customers with the Data Localization Suite who have Customer Metadata Boundary configured for the EU region.

Where to find it

Authoritative DNS: In the Cloudflare dashboard, select your zone and go to the Analytics page.

Go to Analytics

DNS Firewall: In the Cloudflare dashboard, go to the DNS Firewall Analytics page.

Go to Analytics

For more information, refer to DNS Analytics and DNS Firewall Analytics.

Original source

Overview

Cloudflare's stale-while-revalidate support is now fully asynchronous. Previously, the first request for a stale (expired) asset in cache had to wait for an origin response, after which that visitor received a REVALIDATED or EXPIRED status. Now, the first request after the asset expires triggers revalidation in the background and immediately receives stale content with an UPDATING status. All following requests also receive stale content with an UPDATING status until the origin responds, after which subsequent requests receive fresh content with a HIT status.
stale-while-revalidate is a Cache-Control directive set by your origin server that allows Cloudflare to serve an expired cached asset while a fresh copy is fetched from the origin.
Asynchronous revalidation brings:

Asynchronous revalidation brings:

• Lower latency: No visitor is waiting for the origin when the asset is already in cache. Every request is served from cache during revalidation.
• Consistent experience: All visitors receive the same cached response during revalidation.
• Reduced error exposure: The first request is no longer vulnerable to origin timeouts or errors. All visitors receive a cached response while revalidation happens in the background.

Availability

This change is live for all Free, Pro, and Business zones. Approximately 75% of Enterprise zones have been migrated, with the remaining zones rolling out throughout the quarter.

Get started

To use this feature, make sure your origin includes the stale-while-revalidate directive in the Cache-Control header. Refer to the Cache-Control documentation for details.

Original source

Request body buffering

Controls how Cloudflare buffers HTTP request bodies before forwarding them to your origin server:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the request body for enabled functionality such as WAF and Bot Management. Full Buffers the entire request body before sending to origin. None No buffering — the request body streams directly to origin without inspection.

Response body buffering

Controls how Cloudflare buffers HTTP response bodies before forwarding them to the client:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the response body for enabled functionality. None No buffering — the response body streams directly to the client without inspection.

Setting body buffering to None may break security functionality that requires body inspection, including the Web Application Firewall (WAF) and Bot Management. Ensure that any paths where you disable buffering do not require security inspection.

These settings only take effect on zones running Cloudflare's latest CDN proxy. Enterprise customers can contact their account team to enable the latest proxy on their zones.

API example

{
  "action": "set_config",
  "action_parameters": {
    "request_body_buffering": "standard",
    "response_body_buffering": "none"
  }
}

For more information, refer to Configuration Rules.

Original source

New functions

Function Description Availability encode_base64(input, flags) Encodes a string to Base64 format. Optional flags parameter: u for URL-safe encoding, p for padding (adds = characters to make the output length a multiple of 4, as required by some systems). By default, output is standard Base64 without padding. All plans (in header transform rules) sha256(input) Computes a SHA256 hash of the input string. Requires enablement

Note
The sha256() function is available as an Enterprise add-on and requires a specific entitlement. Contact your account team to enable it.

Examples

Encode a string to Base64 format:

encode_base64("hello world")

Returns: aGVsbG8gd29ybGQ

Encode a string to Base64 format with padding:

encode_base64("hello world", "p")

Returns: aGVsbG8gd29ybGQ=

Perform a URL-safe Base64 encoding of a string:

encode_base64("hello world", "u")

Returns: aGVsbG8gd29ybGQ

Compute the SHA256 hash of a secret token:

sha256("my-token")

Returns a hash that your origin can validate to authenticate requests.

Compute the SHA256 hash of a string and encode the result to Base64 format:

encode_base64(sha256("my-token"))

Combines hashing and encoding for systems that expect Base64-encoded signatures.

For more information, refer to the Functions reference.

Original source

New functions

Function Description split(source, delimiter) Splits a string into an array of strings using the specified delimiter. join(array, delimiter) Joins an array of strings into a single string using the specified delimiter. has_key(map, key) Returns true if the specified key exists in the map. has_value(map, value) Returns true if the specified value exists in the map.

Example use cases

Check if a country code exists in a header list:

has_value(split(http.response.headers["x-allow-country"][0], ","), ip.src.country)

Check if a specific header key exists:

has_key(http.request.headers, "x-custom-header")

Join array values for logging or comparison:

join(http.request.headers.names, ", ")

For more information, refer to the
Functions reference.

Original source

The ip.src.metro_code field in the Ruleset Engine is now populated with DMA (Designated Market Area) data.
You can use this field to build rules that target traffic based on geographic market areas, enabling more granular location-based policies for your applications.

Field details

Field Type Description ip.src.metro_code String null

Example filter expression:

ip.src.metro_code eq "501"

For more information, refer to the Fields reference.

Original source