Cloudflare can take work off a server and stop a lot of rubbish before it reaches PHP. It can also serve yesterday's page, block a real visitor or make a problem harder to find if you switch everything on at once. I get the best results by treating the edge as one part of the hosting setup. WordPress, PHP, OPcache, the application cache and the proxy all need to agree about who owns a response and when it expires.
Measure the whole request before tuning it
Start with a handful of representative journeys. Test a signed-out page, a logged-in page, a search, a form submission and a fresh piece of content. Record response time, cache headers, PHP and database work, and whether the result is correct. Run the same checks after each change. A better cache hit rate means little if editors see stale content or an account page leaks into a public cache.
For Sheffield Events, I would include a public event page, the event listings, an event submission and a newly published or corrected event. For TalkFuse, I would include a public story, a signed-in feed, profile activity and a comment. Those journeys exercise very different cache and security paths.
Give each layer a job
Cloudflare is well placed to serve public static files and selected anonymous HTML. The origin still has to handle sessions, writes, permissions and personalised feeds. An object cache such as Ace Redis Cache can save database work inside WordPress. OPcache saves PHP compilation work. Neither makes a personalised HTML response safe to share at the edge.
Write down the bypasses before adding a broad cache rule. WordPress administration, login, preview, REST writes, AJAX actions, forms with nonces and anything carrying a logged-in cookie need particular care. Some public REST endpoints can be cached, but only when their output is genuinely the same for everyone and their invalidation is understood. Check rule order too: Cloudflare applies the last matching cache setting when rules conflict. Cloudflare explains Cache Rule order.
Then decide how a publish, edit or deletion clears each cache. A purge at one layer does not automatically clear the others. This mattered on TalkFuse: after the analytics consent change was deployed, targeted Ace Redis and Varnish purges were needed before visitors received the new output. Prefer a targeted URL or tag purge where the application knows what changed. Keep a safe fallback for a wider purge when an event or story affects several listings. Cloudflare documents the purge methods and their limits.
Put abuse checks at the right place
Turnstile belongs on forms that attract automation. The browser widget is only the first half. The server must send its token to Siteverify and reject an invalid, expired or reused token. Keep ordinary WordPress nonce and permission checks as well. A nonce prevents an unintended action in a user's session; it does not prove the visitor is human. Cloudflare's Siteverify guide covers the required validation.
WAF and rate limiting can cut down floods against login, posting and expensive API paths. Start from real request data and choose thresholds that leave normal editing, crawlers and assistive tools alone. The Free plan has fewer rule fields and actions than the paid tiers, so check the rule against the plan before relying on it. Keep application-level limits too: requests can reach the origin through trusted internal routes, and edge rate counters are not a precise transaction limit. Cloudflare's rate limiting reference explains those limits.
The origin boundary matters just as much as the WAF. If the server accepts direct public traffic, visitors can bypass the edge. We covered the nginx side in our guide to locking an origin to Cloudflare.
Use Workers for small jobs with clear limits
A Worker can be a good home for a stable redirect or a small public response assembled from already published data. It should not become a second, poorly synchronised version of WordPress. Give it a narrow route, a clear owner, a failure path and usage limits. If the response depends on a user, permission or fresh database state, let the application handle it. The same applies to AI Gateway: usage analytics and rate controls can help, but private prompts and responses should not be stored just to make a dashboard look complete. Cloudflare documents the logging controls.
Keep analytics and email honest
Cloudflare Web Analytics can add a light view of traffic and page performance. Compare it with what the site already measures first, then make the privacy notice describe the scripts that actually load. Avoid collecting the same event in several services unless each one has a clear purpose.
Email Routing can be useful for a simple inbound alias, but it is not a replacement for the site's transactional mail service. Changing MX affects delivery for the whole domain. Inspect existing mailboxes, SPF, DKIM and DMARC before touching it, and keep sending from WordPress on its working outbound path.
What changed on our sites
Baseline, before this work: Five live requests per route gave median TTFB and total response times of 111 and 131 ms for the TalkFuse homepage, 120 and 137 ms for a TalkFuse story, 120 and 148 ms for the Sheffield Events homepage, and 107 and 131 ms for an event page. These are small samples of server response timing, not browser load or Core Web Vitals results. Both public homepage GETs returned CF-Cache-Status: DYNAMIC and Cache-Control: no-store. No HTML cache gain has been established. TalkFuse's Cloudflare zone had a Fuse Quest JSON cache rule and one heavy-crawler challenge at the time of the baseline.
TalkFuse: A Turnstile retry fix is live, so a visitor can recover from a failed or expired challenge without losing the form journey. Cloudflare Web Analytics loads only after consent, alongside the existing Google analytics path. Automatic analytics injection is disabled, preventing a second, uncontrolled beacon. AI Gateway is staged with logging off and its route disabled while the free quota resets. It carries no production traffic. Cache Rules, WAF and Workers have been assessed; no broad HTML cache or security rule has been added without a safe match and a useful measurement.
Sheffield Events, verified live: The analytics consent bug has been fixed and Cloudflare Web Analytics now follows consent. The privacy text reflects that behaviour. Email Routing was already in use, so this work did not move the domain's mail delivery.
Sheffield Events, cache lesson: A registration form served through Varnish carried a stale nonce and timestamp even though WordPress sent no-cache headers. A narrowly scoped VCL pass proved fresh per-request stamps in testing. That is a reminder to check the response visitors receive, not just the headers WordPress intended to send. Turnstile integration has been prepared and tested, but its live keys remain off until a real browser token passes Siteverify. It is not yet a live form protection claim.
These changes were about correctness, abuse resistance and control over what runs in a visitor's browser. Browser timings varied during the work, so I am not claiming a speed improvement. The next performance comparison needs matching routes, locations, cache states and sample sizes, plus a check that accounts, forms and newly edited pages still behave correctly.
The practical routine
- Map public, private and write paths before writing an edge rule.
- Measure representative requests at the browser, Cloudflare and origin.
- Introduce one rule or integration at a time, with a rollback path.
- Check both speed and correctness immediately, after a content update and after caches warm.
- Watch usage and errors for long enough to catch ordinary traffic patterns.
A sharp Cloudflare setup is not a dashboard with every switch enabled. It is a set of small decisions that make the site feel quick while keeping the content, forms and accounts right.