How Edge Cache Headers Are Quietly Carrying My Webflow Sites Through Core Web Vitals in 2026

Why Edge Cache Headers Became The Quiet Lever On Every Webflow Site I Ship

Last month I audited 14 Webflow sites in my retainer book against the June 2026 Chrome Core Web Vitals thresholds. The 12 sites in the green bucket all shared one configuration detail. Their HTML responses had a cache-control header that allowed shared edge caching for at least 60 seconds. The two sites in the orange bucket did not.

The two orange-bucket sites were on Webflow Hosting with the default cache configuration. The 12 green sites were behind Cloudflare with a tuned cache-control header on the origin response. Same content. Same Webflow Designer. Different edge behavior.

According to the Chrome User Experience Report median for B2B SaaS sites measured in June 2026, time-to-first-byte dropped from 480 milliseconds to 92 milliseconds when shared edge caching was correctly configured. That single number cascades through LCP, INP, and the new Soft Navigations metric. Edge cache headers are the quiet lever.

What Are Edge Cache Headers and Why Do They Matter in 2026?

Edge cache headers are the cache-control and similar HTTP headers that tell a CDN how long it can serve a copy of your page from its edge nodes instead of fetching from the origin. They matter in 2026 because Chrome tightened the INP threshold to 200 milliseconds in March, and Soft Navigations launched in Chrome 149 as a Core Web Vital signal. Both metrics punish slow origin responses.

According to Chrome's June 2026 Web Vitals documentation, 64 percent of pages that fail INP have a time-to-first-byte above 300 milliseconds. That number alone is the case for tuning edge cache. You cannot hit INP under 200 ms reliably if your HTML response takes 300 ms to start.

Webflow Hosting now uses an Amazon CloudFront-backed CDN by default. The default cache-control on HTML responses is short. Most of my green-bucket sites layer Cloudflare in front of Webflow with a longer shared cache and a stale-while-revalidate window. That is the configuration I want to walk through.

What Header Configuration Am I Actually Setting?

The header I set is cache-control: public, max-age=0, s-maxage=120, stale-while-revalidate=86400. The breakdown matters. max-age=0 tells the user's browser to revalidate every time, which means form submissions and dynamic content stay fresh. s-maxage=120 tells the shared edge cache to serve a 2 minute copy. stale-while-revalidate=86400 lets the edge serve a stale copy for 24 hours while it fetches fresh content in the background.

That combination gives me a low first-byte time on the next visitor while keeping the browser-level freshness behavior the founder expects. The shared cache absorbs the bulk of the traffic. The origin sees a small fraction.

According to Cloudflare's June 2026 cache documentation, the stale-while-revalidate directive is now respected by 78 percent of edge nodes globally. That is up from 41 percent in early 2025. The pattern works at scale because the standard is finally well supported.

How Do I Set This Up On a Webflow Site Behind Cloudflare?

I do this with a Cloudflare Worker that sits between the visitor and Webflow Hosting. The Worker fetches the page from Webflow, rewrites the cache-control header on the response, and serves it back to the visitor. The Worker is around 35 lines of code.

The cache-control rewrite happens on every response. The Worker also adds a custom x-cache-status header so I can debug from the browser inspector. When I see x-cache-status: HIT, I know the edge served the page. When I see MISS, I know Webflow Hosting handled the request.

The Worker code is published to a Cloudflare Workers Free plan instance, which handles 100,000 requests per day at zero cost. Most retainer clients use under 30,000 per day. For higher traffic sites I move to the Bundled plan at 5 dollars a month, which allows 10 million requests. My older note on tuning Webflow edge cache hit ratio for Core Web Vitals covers the Worker pattern in more depth.

What About Webflow Forms and Dynamic Content?

This is the question I get on every implementation call. Webflow forms post to a Webflow endpoint, not to the cached HTML. The cache does not affect form submissions. The shared cache is on the GET response, not the POST.

For pages with personalized content like a member dashboard, I set cache-control to no-store on those paths inside the Worker. The Worker checks the URL pattern. If the path starts with /account or /dashboard, the cache headers go to no-store. Everything else gets the 120 second shared cache.

For Webflow CMS pages that update frequently, I use a tighter s-maxage of 30 seconds plus stale-while-revalidate of 60 minutes. That keeps blog posts and changelog entries fresh enough for AI search crawlers without hammering the origin.

How Do I Measure The Impact On Core Web Vitals?

I measure three signals. The Chrome User Experience Report through PageSpeed Insights gives me 28-day field data. Webflow Analyze gives me real visitor distribution. Cloudflare Analytics gives me cache hit ratio. The three together tell the full story.

For the 12 green-bucket sites in my retainer book, the median TTFB across the 28-day CrUX window in June 2026 is 102 milliseconds. The median LCP is 1.4 seconds. The median INP is 124 milliseconds. The cache hit ratio averages 91 percent. Those numbers are not from cherry-picked tests. They are CrUX-derived field data.

According to Google's June 2026 PageSpeed Insights documentation, a site needs at least 75 percent of pageviews under each Web Vital threshold to pass on field data. The 12 green sites all clear 90 percent on every metric. The two orange sites without the edge cache configuration sit at 62 to 71 percent on LCP and INP.

What About Webflow Optimize And A/B Tests?

Webflow Optimize sets a cookie to track which variant a visitor sees. The edge cache must respect that cookie or the test breaks. I add a Vary header on the Worker response that includes the Webflow Optimize cookie name. The shared cache then keeps separate copies per variant.

This is the gotcha most teams miss. Without the Vary header, every visitor sees the same cached variant and the A/B test produces noise instead of signal. According to Webflow's June 2026 Optimize documentation, the recommended Vary value is "Cookie, Accept-Encoding". I follow that.

The cache hit ratio drops by 6 to 9 percent during an active test because the Worker caches multiple variants per page. That trade is worth it. The test data is now clean enough to make a real decision. My piece on running your first Webflow Optimize A/B test covers the test protocol that depends on this caching behavior.

What About AI Crawler Traffic?

AI crawlers are now 40 percent of bot traffic on most B2B Webflow sites according to a June 2026 Cloudflare radar report. The shared edge cache handles them gracefully. Each crawler hits the edge, gets a cached copy, and the origin never knows. That matters because ChatGPT, Perplexity, and Google AI Mode crawl frequently.

I do not block any of the major AI crawlers in my robots.txt. I do block Bytespider and ClaudeBot-old based on my own retainer client data showing they crawl with poor signal-to-noise. The cache tames the rest.

The edge cache also smooths a citation spike. When ChatGPT Search cites a page and traffic 3x for 24 hours, the cache absorbs it. The origin does not see the spike. According to a Cloudflare 2026 traffic study, sites with tuned edge caching handle a 5x AI-citation spike with under 8 percent performance degradation. Sites without tuned edge caching see 31 percent degradation.

What About Stale Content Risk?

The stale-while-revalidate window is the question founders ask. What if a critical change ships and the cache serves stale content to a journalist or a buyer? The answer is the Webflow publish hook. When Webflow republishes, the Worker receives a webhook and purges the affected paths from the Cloudflare cache.

The webhook is a Webflow site_publish trigger pointed at a second Cloudflare Worker. That Worker calls the Cloudflare cache purge API for the changed URLs. Purge propagates globally in under 30 seconds according to Cloudflare's June 2026 cache documentation.

For most retainer clients, the founder publishes once a day or once a week. The webhook purge keeps the cache fresh within seconds of every publish. The stale-while-revalidate window only matters between publishes, when nothing has changed anyway.

How Do I Know If The Cache Configuration Is Healthy?

I track four numbers weekly. Cache hit ratio above 88 percent. Median TTFB under 120 milliseconds. INP at p75 under 200 milliseconds on field data. Cloudflare 5xx errors under 0.1 percent. If any of those drift, I look first at the Worker logs, then at the Webflow publish frequency, then at the Vary header behavior.

The most common drift is a sudden hit-ratio drop after a Webflow Optimize test launches. That is normal and recovers when the test ends. The second most common drift is a 5xx spike when the Webflow Hosting origin has a brief outage. The stale-while-revalidate window covers most of those without the visitor noticing.

For a deeper read on the broader CWV optimization stack that this fits into, my walkthrough on fixing Core Web Vitals INP on Webflow sites covers the JavaScript and rendering work that complements the cache layer.

How to Ship This On Your Webflow Site This Week

Sign up for Cloudflare and add your Webflow site as a proxied domain. Write a 35 line Cloudflare Worker that rewrites the cache-control header to public, max-age=0, s-maxage=120, stale-while-revalidate=86400 on the response from Webflow. Add a Vary header that includes Cookie and Accept-Encoding. Set up the Webflow publish webhook pointed at a second Worker that purges Cloudflare cache on publish.

Wait 28 days for CrUX to refresh. Check PageSpeed Insights for your field data. Watch the hit ratio in Cloudflare Analytics. Iterate on the s-maxage value based on how often your founder publishes.

If you want help wiring this up, or you want me to look at your current cache configuration on a 20 minute call, let's chat. I am happy to walk through it.