A while back I took on a performance job for a European industrial parts manufacturer. Their website is a WooCommerce catalogue — hundreds of products, technical specifications, the kind of site engineers use to find a part number rather than browse for fun.

The brief was simple: the site felt slow, and mobile PageSpeed agreed. It was scoring 68 for Performance when I started. By the end of the first round of work, most tests settled around 90, with occasional runs at 91 and a clear path mapped beyond that.

This post covers what actually made the difference, what barely mattered, and what I’d check on your site if it feels sluggish. No theory — just what happened on a real catalogue site with real constraints.

The starting point

The site runs on Kadence, which is a solid, lightweight foundation — this was not a case of a bloated theme dragging everything down. Analytics were already cookieless, so there was no consent-banner JavaScript weighing on first load either.

That matters, because it shows something I see a lot: a site can be built on good foundations and still score poorly. Performance problems usually accumulate in the layers added after launch — plugins, images, embeds, tracking — not in the foundation itself.

Change one: removing a plugin that was doing nothing

The single cheapest win of the whole project was deactivating a WooCommerce add-on plugin that, after auditing, turned out to be redundant — nothing on the live site depended on it, but it was still loading its scripts and styles on every page.

This is the least glamorous performance advice there is, and the most consistently useful: audit what’s actually running. Plugins accumulate. Someone installs one to try a feature, the feature never ships, the plugin stays active for two years quietly adding weight to every page load.

Before touching anything clever, I list every active plugin and ask one question about each: what breaks if this is turned off? If the honest answer is “nothing”, it goes.

Change two: image optimisation with a CDN

The biggest sustained gain came from proper image handling — an image optimiser combined with its CDN, so images are compressed, converted to modern formats, resized to the dimensions actually displayed, and served from edge locations rather than the origin server.

On a catalogue site this compounds. Product photography is usually uploaded at whatever size the camera produced, and WooCommerce pages display a lot of images at once. Getting every image down to the right format and size, automatically, is worth more than any single clever optimisation — because it applies to thousands of files at once and keeps applying to every image uploaded in future.

One straggler proved the rule: a single oversized PNG being displayed far smaller than its actual dimensions was still costing real bytes on a key page. Automation catches most of it; a manual pass catches the rest.

Change three: preloading the hero image

The homepage hero image is usually the Largest Contentful Paint element — the thing PageSpeed times to judge how quickly the page feels loaded. By default, the browser discovers that image relatively late: it has to parse the HTML and CSS before it realises the image is needed.

A preload hint tells the browser to start fetching the hero image immediately. It’s one line, and on this site it directly improved LCP — one of the most heavily weighted metrics in the Performance score.

This is a good example of where the score and the visitor’s experience align. Nobody cares about the number itself; they care that the page appears quickly. LCP is the closest the metrics get to measuring that feeling.

What barely mattered

Worth being honest about the other side. A few things I tested had little measurable effect on this site — micro-optimisations that performance articles love but that were noise compared to the three changes above.

The pattern from this job, and most jobs like it: a handful of changes deliver almost all of the gain. Find the plugin that shouldn’t be running, fix the images, sort the LCP element. Everything after that is chasing single points.

Why it’s 90 and not 95 — yet

A jump from 68 to a stable 90 on mobile moved the site from Lighthouse’s “Needs Improvement” band into “Good”. Some runs reached 91, but most settled around 90. I mapped further work rather than claiming the job finished:

  • A third-party map embed on the contact page loads a chunk of external JavaScript whether or not anyone uses the map. The fix is a click-to-load placeholder — the map appears only when a visitor asks for it.
  • Font loading needed font-display: swap, so text renders immediately in a fallback font rather than waiting for the webfont.
  • Some CSS could be deferred so it stops blocking the first paint.

That’s the honest shape of performance work on an existing site: a first round that captures the big wins fast, then a mapped second round of smaller items, each with a known cost and benefit — rather than one heroic “optimisation” that claims to fix everything.

It’s also worth saying: retrofitting performance is always harder than building it in. On new builds I test against Core Web Vitals before launch, because every one of the problems above is cheaper to prevent than to unpick.

What I’d check on your site

If your site feels slow, the same audit applies:

  1. Run PageSpeed Insights on your homepage and your most important landing page — mobile scores, not desktop. Mobile is where the traffic is and where the problems show.
  2. List your active plugins and ask what each one is actually doing on the live site today.
  3. Check your largest image on each key page — right-click, open in a new tab, and look at its actual dimensions versus the size it displays at.
  4. Look at what loads from other people’s servers — maps, chat widgets, tracking scripts. Each one is weight you don’t control.

Or, if you’d rather I did the looking: I run this exact process as a structured audit, and it usually finds the same handful of expensive problems.

Have a website that feels slower than it should? Book a discovery call and tell me what it’s doing — or not doing.

On this page