Testing Cloudflare on WordPress: Does It Speed Up Your Site?

How To

Cloudflare can speed up a WordPress site, but it is not automatic magic. It helps most when it can cache static assets, serve visitors from a closer edge location, compress files, and reduce traffic hitting the origin server.

The only honest way to know whether Cloudflare helped your site is to measure before and after under similar conditions.

What Cloudflare Usually Improves

Cloudflare sits between visitors and your origin server. For a normal WordPress site, it can help with:

  • Static file caching for images, CSS, JavaScript, fonts, PDFs, and similar assets.
  • Lower bandwidth usage at the origin server.
  • Faster asset delivery for visitors far from the server.
  • Basic DDoS and bot filtering.
  • Better resilience during traffic spikes.
  • Compression and protocol-level improvements.

By default, Cloudflare does not cache normal HTML pages for WordPress. That matters because WordPress page generation can still require PHP, plugins, theme code, and database queries.

What Cloudflare Will Not Fix By Itself

Cloudflare is not a substitute for a healthy WordPress install.

It will not automatically fix:

  • Slow PHP execution.
  • Too many WordPress plugins.
  • Heavy page builders.
  • Slow database queries.
  • Huge uncompressed images.
  • Bad hosting.
  • Uncached logged-in or admin pages.

If the origin server takes two seconds to generate HTML, Cloudflare may still serve static files quickly while the main document remains slow.

Step 1: Record a Baseline

Test before changing DNS. Use the home page and at least one real article page.

Run this a few times:

curl -sS -o /dev/null \
  -w 'code=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/

The useful numbers are:

  • time_namelookup: DNS lookup time.
  • time_connect: TCP connection time.
  • time_starttransfer: time to first byte, often called TTFB.
  • time_total: total request time.

Save the output. One request is not enough; take several readings and look for the pattern.

Step 2: Run a Lighthouse Test

Chrome Lighthouse gives a broader view of page performance.

  1. Open the page in Chrome.
  2. Open DevTools.
  3. Go to the Lighthouse tab.
  4. Run a mobile performance test.
  5. Save the score and the key metrics.

Watch especially:

  • First Contentful Paint.
  • Largest Contentful Paint.
  • Total Blocking Time.
  • Cumulative Layout Shift.
  • Server response time.

Lighthouse scores vary, so compare the same page, same device class, and similar network conditions.

Step 3: Enable Cloudflare

The basic setup:

  1. Add the domain to Cloudflare.
  2. Let Cloudflare scan existing DNS records.
  3. Verify the WordPress A, AAAA, or CNAME records are correct.
  4. Set public web records to proxied, shown as the orange cloud.
  5. Change nameservers at the registrar to Cloudflare’s nameservers.
  6. Wait for DNS to update.

Confirm traffic is going through Cloudflare:

curl -I https://example.com/

Look for headers such as:

server: cloudflare
cf-cache-status: DYNAMIC
cf-ray: ...

DYNAMIC on the HTML page is normal unless you configured page caching.

Step 4: Retest the Same Pages

Run the same curl timing test again:

curl -sS -o /dev/null \
  -w 'code=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/

Then test a static asset such as a CSS file, JavaScript file, image, or font:

curl -I https://example.com/wp-content/themes/your-theme/style.css

For static assets, the important header is:

cf-cache-status: HIT

Common values:

  • HIT: Cloudflare served the asset from cache.
  • MISS: Cloudflare fetched it from the origin this time.
  • DYNAMIC: Cloudflare did not cache it.
  • BYPASS: a rule or header told Cloudflare not to cache it.
  • EXPIRED: cached copy was stale and had to be refreshed.

If you see MISS, refresh and test again. The first request often warms the cache.

Step 5: Interpret the Results

Cloudflare helped if you see some combination of:

  • Lower total request time for visitors far from the origin.
  • Static assets returning cf-cache-status: HIT.
  • Lower bandwidth or request load on the origin server.
  • Better Lighthouse scores for pages with many static assets.
  • More stable performance during traffic spikes.

Cloudflare did not solve the main bottleneck if:

  • HTML TTFB is still high.
  • Static files are cached but the document is slow.
  • Logged-in pages are slow.
  • The server CPU or database is overloaded.
  • Lighthouse still complains about large images or render-blocking scripts.

WordPress Settings Worth Checking

For a typical WordPress site behind Cloudflare:

  • Use HTTPS on the origin server.
  • Set Cloudflare SSL/TLS mode to Full or Full (strict), not Flexible.
  • Keep a WordPress page cache enabled if the site supports it.
  • Do not cache admin pages, checkout pages, account pages, or logged-in sessions.
  • Resize and compress large images before upload.
  • Purge Cloudflare cache after theme, CSS, or JavaScript changes.
  • Use page rules or cache rules carefully; test after every rule change.

Simple Results Table

Track a few readings like this:

Test Before Cloudflare After Cloudflare
Home page TTFB Write value here Write value here
Home page total time Write value here Write value here
Article page TTFB Write value here Write value here
CSS cache status No Cloudflare HIT/MISS/DYNAMIC
Lighthouse mobile score Write value here Write value here

Bottom Line

Cloudflare usually improves WordPress when the site serves lots of static assets, has visitors in multiple regions, or needs protection from traffic spikes. It helps less when the real problem is slow PHP, slow database queries, heavy plugins, or oversized images.

Measure first, enable Cloudflare, then measure again. If static assets show cache hits but HTML remains slow, the next fix is WordPress performance work, not another CDN setting.