Why a caching plugin alone stops working

A caching plugin fixes the easy part: repeat visitors on pages that never change. A WooCommerce store has pages that must not be cached (cart, checkout, account), so the slow part is the server answering those requests. If the PHP workers are starved, the database is bloated with autoloaded options, or there is no object cache, a plugin cannot fix that.

That is why we start at the server and work up:

• Server response (TTFB): Nginx FastCGI cache, PHP-FPM worker tuning and OPcache.
• Object cache: Redis, so the database is not queried for the same data on every request.
• Database: slow queries, autoload bloat, HPOS order storage on stores that still run the legacy tables.
• Front end: images, render-blocking scripts, cart fragments and third-party tags.

Because we run our own Trellis servers on Hetzner, we can change the server itself when that is the bottleneck. On managed hosts such as Kinsta or WP Engine we tell you up front which of these are off limits. Not sure where your store loses time? Run the free store checkup first, or send us the URL and we will tell you what we would look at.

Faster, without breaking what already works

The usual horror story is a score that goes up while the site gets worse: a mobile menu that no longer opens, a contact form that stops sending, ad and analytics tags that quietly stop firing. We treat those as part of the job, not a side effect.

• Staging first: every change is tested on a copy, with a full backup and a way back before anything touches the live site.
• A checklist after each change: mobile menu, forms, checkout, search, buttons, and your Google Ads, Meta and analytics tracking, on phone and desktop.
• Your design stays: same layout, same image quality, same URLs, same SEO metadata and structured data.
• Before and after, in plain numbers: lab scores and real-visitor data side by side, plus a short list of what we changed and why.

We work with the setups most small businesses actually run: Elementor, Divi, WPBakery and block themes, on hosts such as SiteGround, Kinsta, WP Engine and Cloudways, with caching tools like WP Rocket, LiteSpeed Cache, Perfmatters and Cloudflare. If an earlier optimization broke something, we start by finding which setting did it.

How a speed project runs

1. Measure the starting point. We agree which pages count (usually the homepage, a key landing page and, for a store, a product page and checkout) and record mobile and desktop PageSpeed, Core Web Vitals and server response time. These are the numbers the no-invoice promise is judged on.

2. Find where the time goes. We work through each layer: server and PHP workers, object cache, database, then images, scripts, fonts and third-party tags. You get a short list of causes ranked by impact, not a generic plugin checklist.

3. Fix it on staging. Changes go onto a copy of the site first, with a backup in place. After each change we run the checklist above, so a faster page never comes with a broken menu or missing tracking.

4. Go live and report. We deploy the tested changes, re-measure the agreed pages and send a before-and-after report with what we changed and why. Real-visitor data in Google catches up over the following weeks, and we show you where to watch it.

Want to see the method in detail first? Our speed optimization checklist for small businesses walks through the same layers, and how to audit your WooCommerce store covers the store-specific checks.

Results from real sites

• Our own site: desktop PageSpeed from 73 to 99 and mobile to 95, by loading CSS without blocking the page, fixing a lazy-loaded hero image and serving correctly sized images. Read how we did it.
• Jochen Schweizer Corporate: total image payload cut by 48% (1.6 GB to 837 MB) without visible quality loss, YouTube and font loading fixed for mobile, and a Redis object cache tested on staging at a 97.5% cache hit ratio with 15.7% faster admin and API responses. Read the case study.
• 600 Dutch WooCommerce shops: we scanned them to see what slows stores down. Unused JavaScript was the top issue on 95% of the shops we analyzed in depth, and most of the slowest shops took 6 to 25 seconds to show their main content on mobile. See the findings.

More projects are on our case studies page.