Start
On this page

How to diagnose and improve Cloudflare website speed

Separate a slow origin from a slow browser before changing cache rules.

Updated September 8, 2026 · Layzr

If a website behind Cloudflare is slow, first find out whether the delay happens before the HTML arrives or after the browser starts rendering it. Cloudflare can serve eligible cached resources near visitors, but it cannot make an oversized image, expensive application request or long browser task disappear.

Choose a public production URL, test it while signed out, and record the document timing, relevant response headers and the technical findings from Layzr. Compare the same page and device after each change. A higher cache-hit ratio by itself does not prove that the visitor's main content appears sooner.

1. Locate the delay on one page

  1. In browser developer tools, open Network and reload the public page. Select the main document and examine its timing.
  2. Record whether the document waits on a slow response or arrives quickly before a long chain of images, fonts and scripts.
  3. Run the same URL in Layzr: sign in, choose General audit, select Mobile or Desktop and click Run audit. Save the available performance scores and technical findings. Use the reported LCP issues to guide inspection in browser developer tools.
  4. Compare one faster page on the same site. Note differences in authentication, templates, queries, third-party embeds and image sizes.

Check Cloudflare's configuration for the hostname you tested: its CDN does not cache a resource that bypasses the proxy, and it does not automatically cache resources loaded from unrelated third-party hosts. A page can mix both kinds of requests.

2. Read cache headers in context

Inspect CF-Cache-Status on the specific response you expect to be cached. HIT means the response came from cache; MISS means the requested object was not present there. DYNAMIC generally indicates the resource was not eligible for caching at request time. BYPASS can reflect response-time instructions that prevent storage. Check the linked Cloudflare reference for the exact case.

Cloudflare does not cache HTML or JSON by default. Seeing an uncached HTML response is therefore not automatically a configuration error. Decide whether that response is public and identical for every visitor before making it eligible. A static image and a customer's account page require different policies.

If an asset should be cached but is not, inspect its Cache-Control, Set-Cookie behavior and applicable Cache Rules. Check whether a rule overrides what the application intended. Use a specific resource and a repeatable request when testing; do not change every route because one response missed cache.

3. If HTML is slow, inspect the origin work

  • Measure database and external API work needed to generate the route. Look for slow dependencies and requests that run sequentially without needing to.
  • Compare a signed-out page with a static page from the same application. The difference can help distinguish application work from asset delivery.
  • For genuinely public pages, consider pre-rendering or an appropriate shared-cache policy in the framework. Choose freshness requirements before choosing a TTL.
  • Keep personalized account, checkout and authenticated responses out of shared caches. Respect private and no-store instructions and test both signed-in and signed-out behavior.

Do not enable a blanket 'cache everything' rule as a general speed fix. If HTML caching is justified, scope it to known public routes, define invalidation, and check that publishing a change updates the public response. Document the rule so a later authentication feature does not silently inherit an unsafe cache policy.

4. If HTML is fast, inspect the page itself

Use the LCP diagnostic to identify the image or text block that matters. Inspect when it is requested and when it becomes visible. A cached image can still be unnecessarily large; an optimized image can still load late because a script inserts it after startup.

  • Resize and compress the image that actually delays the first screen. Check mobile delivery and avoid delaying an essential hero image with lazy loading.
  • Keep important headings visible without waiting for a long entrance animation or client-side application initialization.
  • Reserve space for images and embeds so they do not move nearby content when they arrive.
  • Profile slow controls and test one optional third-party script at a time. Cache settings cannot remove the CPU work a script performs in the browser.

For a site hosted on Vercel behind Cloudflare, review both layers deliberately. Use the Vercel speed guide for framework and route-level diagnosis instead of adding overlapping cache overrides without a measured reason.

5. Verify performance and correct content

Retest the same URL, device and interaction. Compare document timing and the metric that motivated the change. Confirm that the public page shows the latest published content, forms still work, and authenticated pages show the correct user's data. Keep the rule or code change only when it produces a repeatable benefit without changing the intended response.

Speed is one part of a useful search landing page. Continue with the landing page audit checklist for copy, trust and conversion issues, and use Search Console to distinguish indexing trouble from weak rankings.

Cloudflare and performance references

Review the landing page beyond its cache

Layzr combines performance checks with AI feedback on copy, design, UX and SEO. Compare the same URL and device after a fix. An account and audit credits are required.

Run a website audit in Layzr