Troubleshooting a slow website

This guide helps you identify and resolve performance issues affecting your website. It starts with basic diagnostics and progresses to advanced troubleshooting techniques.

Before you start: Verify traffic goes through Cloudflare

Before troubleshooting performance, confirm that your traffic is actually going through Cloudflare. If requests bypass Cloudflare, the issue is not related to Cloudflare and this guide will not help.

Check for the cf-ray header

Every response served through Cloudflare includes a cf-ray header. Check for this header:

bash
PowerShell

curl -s -D- -o /dev/null https://www.example.com | grep -i cf-ray

(Invoke-WebRequest -Uri "https://www.example.com" -Method Head).Headers["cf-ray"]

If you see a cf-ray header (for example, cf-ray: 8a1b2c3d4e5f6g7h-SJC), your traffic is going through Cloudflare. If not, check your DNS configuration.

Verify DNS is pointing to Cloudflare

Your domain must resolve to Cloudflare IP addresses for traffic to be proxied:

bash
PowerShell

dig +short www.example.com

Resolve-DnsName -Name www.example.com | Select-Object -ExpandProperty IPAddress

The returned IP addresses should be Cloudflare IPs ↗. If they point directly to your origin server, your DNS records are not proxied.

To fix this:

Go to the Cloudflare dashboard ↗.
Find the DNS record for the slow hostname.
Ensure the Proxy status is set to Proxied (orange cloud icon).

Gather information about the slow requests

Performance issues are easier to solve when you can pinpoint exactly what is slow. Start by gathering the following information:

Identify specific slow requests - Determine which URLs, assets, or API endpoints are slow.
Measure the slowness - Quantify the delay (for example, "this image takes 5 seconds to load").
Reproduce the issue - Confirm the slowness is consistent and not a one-time occurrence.

Step 1: Use Observatory to analyze performance

Observatory provides synthetic tests and real user monitoring (RUM) data to assess your website's performance.

RUM is particularly important as these metrics are captured from your actual visitors' browsers so it's an objective view of how they are experiencing your website, rather than lab data, which is typically more detailed (useful for debugging) but doesn't always correlate with the devices or connectivity real people have access to.

Run a speed test

Go to the Cloudflare dashboard.
Go to Observatory
Select Observatory.
Enter the URL you want to test and select Run test.

Understand the results

Observatory reports key metrics:

Metric	What it measures	Target
Largest Contentful Paint (LCP)	Time until the largest visible element loads	Under 2.5 seconds
First Contentful Paint (FCP)	Time until the first content appears	Under 1.8 seconds
Cumulative Layout Shift (CLS)	Visual stability during page load	Under 0.1
Time to First Byte (TTFB)	Time until the first byte of response is received	Under 800 ms
Total Blocking Time (TBT)	Time the main thread is blocked	Under 200 ms

Real User Monitoring reports similar metrics but you'll see Interaction to Next Paint (INP) in place of Total Blocking Time (TBT).

TBT only measures during page load but INP measures every interaction real visitors make with your website.

Enable recommended optimizations

Based on Observatory results, enable relevant Speed optimizations:

Brotli compression - Compress responses for faster transfer
Early Hints - Preload critical resources
HTTP/2 and HTTP/3 - Use modern protocols with multiplexing, allowing multiple requests over a single connection instead of opening separate connections for each asset
Image optimization - Automatically optimize and resize images
Rocket Loader - Defer loading of JavaScript to improve paint times

Step 2: Identify slow resources

If Observatory and RUM data point to specific issues, use browser developer tools to investigate individual resources.

Use browser developer tools

Open your browser's developer tools.
Go to the Network tab.
Reload the page and observe which requests take the longest.
Sort by Time or Duration to identify the slowest assets.
Note the specific URLs of slow resources.

Look for:

Large images or videos
Slow API calls
Third-party scripts
Render-blocking resources

Step 3: Analyze origin performance

If your website is slow, the issue may be at your origin server. Use Origin Analytics to understand how your origin is performing.

Check origin response times

In the Cloudflare dashboard:

Go to Speed > Origin Analytics.
Review the Origin Response Time metrics.
Look for patterns in slow responses (specific paths, times of day, or geographic regions).

High origin response times indicate your origin server is struggling. Consider:

Upgrading your hosting plan
Optimizing database queries
Implementing server-side caching

Check for slow Workers

If your zone has Cloudflare Workers deployed, they execute on every matching request and add to the total response time. A slow Worker is a common cause of high TTFB.

To check if Workers are affecting performance:

Go to Workers & Pages in the Cloudflare dashboard.
Review which Workers are deployed on your zone.
Check the Analytics for each Worker to see execution times.
Temporarily disable Workers to isolate whether they are causing the slowness.

If a Worker is slow, review its code for:

Slow external API calls or fetch() requests
Inefficient loops or data processing
Missing await statements causing sequential instead of parallel execution

Step 4: Measure performance from the command line

For detailed timing metrics on specific requests, use command-line tools to measure performance.

curl -w "\n\nDNS Lookup: %{time_namelookup}s\nTCP Connect: %{time_connect}s\nTLS Handshake: %{time_appconnect}s\nTime to First Byte: %{time_starttransfer}s\nTotal Time: %{time_total}s\n" -o /dev/null -s https://www.example.com/slow-asset.jpg

$url = "https://www.example.com/slow-asset.jpg"
try {
    $timing = Measure-Command {
        $response = Invoke-WebRequest -Uri $url -ErrorAction Stop
    }
    Write-Host "Total Time: $($timing.TotalSeconds)s"
    Write-Host "Status: $($response.StatusCode)"
} catch {
    if ($_.Exception.Response) {
        $statusCode = $_.Exception.Response.StatusCode.value__
        Write-Host "Error Status: $statusCode"
    }
    Write-Host "Error: $($_.Exception.Message)"
}

Example output (bash):

DNS Lookup: 0.025s
TCP Connect: 0.045s
TLS Handshake: 0.120s
Time to First Byte: 0.350s
Total Time: 1.250s

Understand the metrics

The curl timing breakdown shows the following:

Metric	Description	High value indicates
DNS Lookup	Time to resolve the domain name	DNS issues or slow resolver
TCP Connect	Time to establish TCP connection	Network latency or server distance
TLS Handshake	Time to complete SSL/TLS negotiation	Certificate chain issues or slow server
Time to First Byte (TTFB)	Time until first response byte	Slow origin processing
Total Time	Complete request duration	Large file size or slow transfer

Test from different locations

To test from different geographic locations, use online tools like:

Step 5: Investigate caching

Caching is one of the most effective ways to improve website performance. When content is cached, Cloudflare serves it directly from a data center close to your visitors, eliminating the round trip to your origin server. This can reduce response times from hundreds of milliseconds to just a few milliseconds.

Uncached content must travel from the visitor to Cloudflare, then to your origin server, and back again. Use Cache Analytics to understand your cache performance and identify opportunities to cache more content.

Check if assets are cached

Check the cache status of a specific asset:

bash
PowerShell

curl -s -D- -o /dev/null https://www.example.com/asset.jpg | grep -i "cf-cache-status"

(Invoke-WebRequest -Uri "https://www.example.com/asset.jpg" -Method Head).Headers["cf-cache-status"]

Possible values:

Status	Meaning	Action
HIT	Served from Cloudflare cache	No action needed
MISS	Not in cache, fetched from origin	May need cache rules
DYNAMIC	Not eligible for caching	Create a cache rule if static
BYPASS	Cache intentionally bypassed	Review cache rules
EXPIRED	Cached copy was stale	Increase Edge TTL
REVALIDATED	Cloudflare confirmed content is current	Increase Edge TTL

For a complete list, refer to Cloudflare cache responses.

Use Cache Analytics

Go to the Cloudflare dashboard.
Go to Overview
Review the Cache Performance section.
Filter by Cache status equals MISS or DYNAMIC to identify uncached content.

Investigate why static content is not cached

If static assets (images, CSS, JavaScript) show a cache status of DYNAMIC, BYPASS, or MISS, investigate the cause:

Symptom	Likely cause	Solution
`DYNAMIC` status	Content type not in default file extensions	Create a Cache Rule to cache the content
`DYNAMIC` status	Origin sends `Cache-Control: private` or `no-store`	Create a Cache Rule to override origin cache control
`BYPASS` status	A Cache Rule is bypassing cache	Review your Cache Rules configuration
`MISS` on every request	Response includes `Set-Cookie` header	Configure your origin to not set cookies on static assets, or use a Cache Rule to ignore cookies
`MISS` with query strings	Different query strings create different cache entries	Use a custom cache key to ignore or normalize query strings

Cache additional static content

By default, Cloudflare only caches certain file extensions. To cache additional static content:

Go to Caching > Cache Rules.
Create a rule to cache specific content.
Set appropriate Edge TTLs.

Use Cloudflare Trace to debug cache rules

If your cache rules are not applying as expected, use Cloudflare Trace to simulate a request and see exactly which rules match. Trace shows you how your Cloudflare configurations (including cache rules, page rules, and other settings) would affect a specific URL.

This is particularly useful when:

A cache rule should be caching content but the response shows DYNAMIC or BYPASS
You are unsure which rule is taking precedence
You want to test a "what-if" scenario before making changes

Step 6: Diagnose network issues

If curl shows high TCP Connect or TLS Handshake times, the issue may be network-related rather than application-related.

Test your Internet connection

Visit speed.cloudflare.com ↗ to test:

Download and upload speeds
Latency (ping)
Jitter
Packet loss

Poor results indicate issues with your local network or ISP.

Run MTR from your location to Cloudflare

MTR combines traceroute and ping to show latency and packet loss at each network hop.

macOS/Linux
Windows

mtr -rw www.example.com

Look for:

High latency at specific hops (indicates slow network segments)
Packet loss (indicates network congestion or issues)
Timeouts (may indicate firewalls or routing issues)

For more details, refer to How to read MTR ↗.

Run MTR from your origin to Cloudflare

If you have access to your origin server, run MTR from the origin to a Cloudflare IP address ↗ to test the network path between your origin and Cloudflare.

mtr -rw 104.16.132.229

High latency or packet loss on this path affects all requests that miss the cache.

Step 7: Understand network routing

How requests are routed to Cloudflare data centers can significantly impact performance.

Identify which data center serves your requests

Add /cdn-cgi/trace to your domain to see which Cloudflare data center is serving your requests:

bash
PowerShell

curl https://www.example.com/cdn-cgi/trace

Invoke-RestMethod -Uri "https://www.example.com/cdn-cgi/trace"

The colo field shows the three-letter airport code of the serving data center (for example, colo=SJC for San Jose). You can find the full list of Cloudflare data centers and their codes on the Cloudflare status page ↗.

Why routing matters

When a request reaches Cloudflare:

The request is routed to a nearby Cloudflare data center based on anycast routing ↗.
If the content is cached, it is served immediately.
If not cached, Cloudflare fetches from your origin server.

If your origin server is geographically distant from the Cloudflare data center serving your users, uncached requests will be slow.

Troubleshoot unexpected routing

If requests are being routed to a data center that seems far from the user, this may be due to Cloudflare's automated traffic engineering or a user’s ISP routing traffic.

While Cloudflare always strives to provide the best possible performance by serving traffic from the closest location, reliability is the top priority. In instances where performance and reliability are in conflict, Cloudflare's systems are designed to prioritize a stable connection over a local one.

For more details, refer to Cloudflare traffic not being sent to the geographically closest data center.

Common causes of unexpected routing:

Symptom	Explanation
Requests route to a distant data center	Cloudflare traffic engineering for reliability, or ISP routing decisions
Routing changes between requests	Normal behavior - routing adapts to network conditions or ISP load balancing
Consistent routing to a distant region	ISP peering location or Cloudflare capacity management
High latency despite nearby data center	Network congestion on the path

Solutions for origin distance

Consider these solutions based on your needs:

Solution	Description	Best for
Improve cache hit ratio	Cache more content to reduce origin fetches	All sites
Tiered Cache	Use upper-tier data centers to reduce origin requests	Sites with global traffic
Argo Smart Routing	Route traffic over faster network paths	Sites with slow origin connections
Move origin closer	Deploy origin servers in multiple regions	Large-scale applications

Enable Argo Smart Routing

Argo Smart Routing analyzes network conditions in real-time and routes traffic over the fastest paths, reducing latency by an average of 30%.

Argo Smart Routing is part of Smart Shield, which bundles multiple Cloudflare performance and reliability features.

To enable Argo Smart Routing:

Go to the Cloudflare dashboard ↗.
Follow the Smart Shield setup guide to enable the feature.

Argo is particularly effective when:

Your origin is far from your users
Network congestion affects certain paths
You need consistent performance globally

For detailed information about how Argo Smart Routing works, refer to the Argo Smart Routing documentation.

Contact Support if the problem persists

If you have followed the steps above and the performance issue persists, contact Cloudflare Support for assistance.

When contacting Support, provide as much evidence as possible to help diagnose the issue:

HAR file - Generate a HAR file that captures the slow requests. This provides detailed timing information for every request.
Observatory results - Share screenshots or links to your Observatory test results.
RUM data - If you have Web Analytics enabled, share relevant metrics showing the performance issue.
curl output - Include the timing breakdown from curl --write-out for the slow assets.
MTR results - If you suspect network issues, include MTR output from your location to the affected domain.
Specific URLs - List the exact URLs that are slow, along with the expected and actual response times.

The more evidence you provide showing the slowness, the faster Support can identify and resolve the issue.

Observatory - Test and monitor website performance
Cache Analytics - Analyze cache hit rates
Cache Rules - Control what gets cached
Argo Smart Routing - Optimize network routing
Gathering information for troubleshooting - Collect diagnostic data