A slow online store is a serious problem. It can lower sales, make ads more expensive, and hurt SEO. The hard part is that the site may still “work,” so the problem is easy to ignore until the numbers start getting worse.
This is the story of how we improved the speed of a busy WooCommerce store. We reduced fully loaded time by 71%, without rebuilding the site, changing the design, or changing how the store looked.
Most of the work happened behind the scenes. We set up Cloudflare properly, added Redis object caching on the server, cleaned the database, and reduced the amount of CSS, JavaScript, and image data loaded by the browser.
Here is what we found, what we changed, and why it mattered.
The starting point: years of growth without much cleanup
The client runs an established ecommerce store in the safety and protective equipment industry. The store had been growing for years. It had thousands of products, good organic traffic, and steady sales.
From the outside, everything looked fine.
But under the surface, the site had built up a lot of weight over time. This is common with older WooCommerce stores. Plugins had been added one by one over the years. Each plugin solved some problem, but many of them also added extra database queries and extra code to the front end.
Images were often served in large sizes. There was no strong caching setup. Many pages were being built again and again by PHP and MySQL for every visitor. The database also had years of old data, expired sessions, old metadata, revisions, and leftover plugin data.
This was not caused by one big mistake. It was the normal result of a busy store running for years without regular performance work.
Temporary solutions on top of other temporary solutions… piling up to the level of losing the balance…
The symptoms were clear:
- pages took around 8–10 seconds to fully load,
- checkout felt slow, especially on mobile,
- Core Web Vitals had fallen into the “poor” range,
- the server was doing too much work on almost every visit.
For a store that depends on organic traffic, this was a real business risk.
What the numbers showed
Before making changes, we measured the site.
| Metric | Before | After | Change |
|---|---|---|---|
| Fully loaded time | 8.3 s | 2.4 s | −71% |
| Time to First Byte | 1,820 ms | 190 ms | −90% |
| Largest Contentful Paint | 6.4 s | 1.9 s | −70% |
| Total page weight | 5.6 MB | 1.7 MB | −70% |
| HTTP requests | 174 | 68 | −61% |
| Lighthouse performance score | 29 | 94 | +65 pts |
The most important number was the Time to First Byte, or TTFB.
TTFB tells us how long the server takes to start sending the page. In this case, the browser was waiting almost two seconds before it even started downloading the page properly.
That told us the main problem was not only in the browser. The server was also too slow.
Diagnosis: where the time was going
We checked the site in three areas:
- the network, using WebPageTest and Cloudflare analytics,
- the front end, using Lighthouse and GTmetrix,
- the WordPress application itself, looking at database queries and server-side performance.
The problems were quite clear.
First, almost every request was going directly to the origin server. There was no proper edge caching, so visitors far away from the server had to wait longer for assets and pages.
Second, dynamic WooCommerce pages were slow. Cart, checkout, account pages, and logged-in pages were running the same expensive database queries again and again.
Third, the browser had too much work to do. The site loaded large images, render-blocking CSS and JavaScript, and plugin files on pages where they were not needed.
So we worked on all three layers.
Part one: setting up Cloudflare properly
We put Cloudflare in front of the site as a CDN and reverse proxy.
This means that static files like images, CSS, JavaScript, and fonts could be served from Cloudflare’s edge network instead of always coming from the main server.
We also enabled Brotli compression and HTTP/3. These help reduce file size and improve delivery speed. Image optimization was also added, so modern image formats like WebP could be served where possible.
The important thing with WooCommerce is that you cannot cache everything without thinking.
Some pages are personal to the customer. Cart, checkout, and account pages must always be fresh. You do not want one customer seeing another customer’s cart.
So we set up caching rules carefully. Catalog pages and content pages could be cached. Cart, checkout, account pages, and WooCommerce cookie-based sessions were excluded from cache.
We also used Cloudflare’s firewall rules to block a lot of bad bot and scraper traffic. This reduced useless traffic hitting the server and gave the store more room for real customers.
This first layer already made a big difference. Many visitors were now served by Cloudflare instead of forcing the origin server to handle every request.
Part two: Redis object caching
Cloudflare helped with static and cacheable pages. But it did not solve everything.
WooCommerce still has dynamic pages that must run through PHP and the database. On this site, these database queries were a major reason for the slow TTFB.
WordPress was asking MySQL for the same information again and again: options, products, terms, metadata, menus, and other repeated data.
This is where Redis helped.
We installed Redis on the server and connected WordPress to a persistent object cache. Redis stores the results of many expensive database queries in memory.
So instead of asking MySQL for the same answer every time, WordPress can often get it directly from RAM.
This was the biggest single performance win.
TTFB dropped from around 1.8 seconds to under 200 milliseconds on many dynamic pages. More importantly, it stayed low even when traffic increased.
This is the part that Cloudflare alone cannot fix. For WooCommerce, server-side caching is often just as important as CDN caching.
We also cleaned up the database at the same time. We removed expired transients, old revisions, orphaned metadata, unused plugin data, and unnecessary autoloaded options.
A cleaner database means fewer things for WordPress and MySQL to process.
Part three: reducing front-end bloat
The last part was the front end.
Even after the server got faster, the browser still had too much to download and process.
We cleaned this up step by step.
CSS and JavaScript were minified. Some files were combined where it made sense. Non-critical JavaScript was deferred so it did not block the page from rendering.
We also removed scripts and styles from pages that did not need them. For example, some plugin files were loading across the whole site even though they were only needed on a few pages.
We reviewed plugins and removed or replaced several that were no longer needed.
Images were also a big part of the problem. They were the largest part of the page weight. We converted images to modern formats, served better image sizes for different devices, and added lazy loading so images below the fold did not load too early.
Fonts were also cleaned up. We reduced unnecessary font loading and preloaded the important files to avoid delays and layout shifts.
Together, these changes reduced page weight by about 70% and cut the number of HTTP requests by more than half.
The browser simply had less work to do.
The result: 71% faster
After all changes were in place, the fully loaded time dropped from 8.3 seconds to 2.4 seconds.
That is a 71% improvement.
Core Web Vitals also moved into the “good” range. This matters because speed is not only a technical metric. It affects SEO, user experience, conversion rate, and paid traffic performance.
The business impact was also visible.
Users stayed longer. Key landing pages had a lower bounce rate. Customers viewed more pages per session. Checkout felt smoother, especially on mobile.
For a store that gets a lot of organic traffic, this kind of improvement is not just a nice technical win. It can directly support rankings, conversions, and revenue.
What we would tell other store owners
Most slow WooCommerce stores have more performance potential than people think.
This project did not need a redesign. It did not need a full rebuild. It did not need a completely new platform.
The store looked the same after the work. It simply loaded much faster.
The biggest gains came from fixing the foundation:
- proper Cloudflare setup,
- Redis object caching,
- database cleanup,
- plugin cleanup,
- image optimization,
- CSS and JavaScript cleanup.
Even if your website feels too large or too complex to optimise, don’t assume that a complete rebuild is your only option. Many ecommerce stores have plenty of low-hanging fruit that can deliver significant improvements in performance, user experience, and ultimately revenue.
A full rebuild may still be the right long-term strategy, but it’s not always the best place to start. Sometimes the biggest gains come from developers who are willing to roll up their sleeves, dig into the existing codebase, and optimise what you already have.
While every website is different, we’ve found that careful optimisation can often deliver substantial improvements without the cost and disruption of a full rebuild.
The solution is Solid Craftsmanship.