Tantrafest
HTML cached at the edge and purged automatically when content changes. Page weight fell from 2.9 MB to 1.3 MB after eager reCAPTCHA was removed, icons and fonts were subset, and the hero image was preloaded.
Learn more →Speed and infrastructure: caching, CDN and server strategy
Fast sites are designed in layers. We decide what is cached where, how it is refreshed, and what the server has to do when nothing is cached.
The request path, layer by layer
- 1
Browser
Static files are content-hashed and cached for a year, so returning visitors download almost nothing.
- 2
CDN edge
HTML for anonymous visitors is cached close to the user. Logged-in users, carts, checkout, forms and APIs bypass the cache.
- 3
Origin page cache
When the edge misses, a page cache serves stored HTML without starting PHP.
- 4
Application and object cache
WordPress runs only when it has to, with expensive queries cached where measurements justify it.
- 5
Database
Indexed, lean and rarely asked the same question twice.
Cache strategy
Cache in layers, purge on change.
- We decide per URL type what may be cached, for whom and for how long: public pages, product pages, carts, checkout, forms and APIs
- Automatic purge when content, menus, templates, translations or settings change, so faster never means stale
- We find what silently defeats caching: for example, a plugin that opened a PHP session on every page made every response uncacheable
- Cached pages stay safe: nonces and tokens are fetched at runtime instead of being baked into cached HTML
- Every change is verified with response headers (HIT, MISS, DYNAMIC), not just with a speed score
CDN strategy
Put the right things at the edge.
- Cloudflare in front of the origin: cache rules by URL and cookie, tiered caching, HTTP/3 and security headers
- Images and other heavy media offloaded to object storage (Cloudflare R2), so the origin serves HTML
- Right-sized images in modern formats only where they are actually smaller: we measure instead of assuming
- Critical assets preloaded, fonts self-hosted and subset, third-party scripts loaded on interaction (reCAPTCHA and Turnstile, for example)
- Multi-domain and multilingual setups handled explicitly: separate zones, canonical hosts and redirects at the edge
Server optimisation
Make the origin boring.
- WP-Cron replaced by real server cron, with locks and memory limits, so scheduled work never competes with visitors
- PHP-FPM workers, memory and timeouts sized to real concurrency; plugins that call their own site and can exhaust workers are found and fixed
- Database hygiene: indexes, autoloaded options and slow queries, with heavy imports moved off the request path
- Lean responses for expensive edge cases, such as a 404 page that skips the full theme
- Error, slow-query and cron logs reviewed, so problems surface before visitors report them
How we work
Baseline
Real response headers, page weight, PageSpeed medians and, where available, field data.
One layer at a time
One change at a time, with a documented way back.
Verify
Cache headers, repeat runs, and a check that logged-in and checkout flows still work.
Keep watching
Cache hit rates, cron logs and error logs stay under review (see the maintenance subscription).
What this looks like in practice
Ostlemine24
Scheduled jobs moved from WP-Cron to a real server cron job, so they are no longer capped by the web-request memory limit. Product images were offloaded to R2 and the 404 page shrank from 656 KB to 4.2 KB.
Learn more →This site
A static build on Cloudflare Pages: content-hashed assets cached for a year, security headers with a strict content security policy, and mobile PageSpeed scores of 99 to 100 in every category (measured 20 September 2026).
Want a review of your caching and hosting setup?
Tell us about your site and where it feels slow.