From 71 to 85 on mobile: speeding up a WooCommerce store without rebuilding it

A 71 that wouldn’t budge

The online store of AMI Informatique, a tech retailer in Dakar, was about to open. Eighty-six products, a carousel on the home page, a buying guide, a comparison tool, a WhatsApp button, customer reviews, attribute filters. All of it on Elementor Pro, WooCommerce and around twenty plugins. On desktop, PageSpeed Insights gave 97. On mobile, 71, and mobile is where these customers buy.

Two figures in the detailed report jumped out at me. The LCP, which is the time the largest visible element on the page takes to appear, was 5.3 seconds. The CLS, which measures how much the page “jumps” while it loads, was 0.14.

The cause was structural. To show the home page, a phone had to download 43 stylesheets, 824 KB in all, plus 328 KB of styling dropped straight into the page and 1.9 MB of scripts. Most of it did nothing on that page. The shop filters or the customer-review gallery have no reason to load on the home page. They did anyway, because a plugin loads its files everywhere by default.

What I refused to do

Rebuilding the site with native blocks would have given the best result. But this wasn’t the moment. The client was waiting, and a full rebuild is rarely justified for a few points on a score. I also ruled out installing yet another all-in-one optimisation plugin. The site already had enough of them, and every extra plugin is another source of conflicts.

Everything that follows fits into a few small settings added with the Code Snippets plugin, which lets you slip instructions into WordPress without touching the theme, and into the options of Autoptimize, which was already installed.

First lead: load only what the page uses

The most effective lever turned out to be the simplest. On the home page and the editorial pages, I stopped the shop-only plugins from loading their files. WordPress can do this natively, provided you tell it what to remove and on which pages. Each file is known by the name its plugin gives it, and it’s only kept on the shop, the basket, the checkout and the customer account.

On the home page, that removed the YITH filters, the variation swatches, the customer reviews, the PhotoSwipe gallery and the SelectWoo component. We went from 31 to 25 stylesheets and from 45 to 30 scripts. Then I reloaded the page as a visitor, and a gallery template, printed at the bottom of the page by the reviews plugin, was showing in plain view. It had always been there, hidden by the very styling I’d just removed. Two lines of styling fixed it, but you do have to look at the whole page, not just the score.

The report said the culprit was the cookie banner

I assumed the LCP element was the carousel image. The Lighthouse report said otherwise: it was the text of the cookie banner. The banner is added by a script after the page has loaded, and its seven-line paragraph was the largest visible block on a phone screen. So Google was timing the moment the banner appeared, more than two seconds after everything else.

I rewrote the banner message. Two lines instead of seven, without taking away any of the choices on offer. The banner heading became the LCP element again, and the score went from 78 to 80 without a single asset being touched. The overall score never tells you which element is dragging it down; you have to go and find it in the detail.

The carousel was loading 1.5 MB of images nobody saw

The home page carousel has five slides, but only one is visible when the page opens. The images for the other four, 1.5 MB of PNG in total, loaded straight away and competed with the main image. None of them had their dimensions filled in. The browser therefore couldn’t reserve the space before the files arrived, and the page jumped with every image that came in. Hence the CLS of 0.14.

First, I made each slide pick up the dimensions recorded in the WordPress media library. From there, WordPress adds lazy loading to the images that aren’t visible at the start all by itself, and the browser reserves the space. Then I asked the browser to load the main image and the two fonts used at the top of the page as a priority. CLS came down to 0.05, and the first paint of content went from 2.3 to 1.5 seconds.

The setting that lowered the score first time round

That left the scripts that block rendering. Autoptimize was already deferring everything except jQuery, which it excludes by default because so many small scripts depend on it. Since it was also deferring those small scripts while keeping their order, I could defer jQuery itself. I did it with a setting added in Code Snippets. The page broke, but only for me. The WordPress admin bar, which only a logged-in user sees, needs jQuery immediately. I limited the setting to logged-out visitors. Testing only while logged in, or only while logged out, misses half the problems.

That left combining the stylesheets. In Autoptimize, one checkbox merges every style file into a single one, which cuts the round trips to the server. On a first attempt, that box had lowered the score. The single file weighed more than 800 KB and blocked everything. Once the unnecessary plugins had been taken off the page, I ticked the same box again. The file now weighed 54 KB compressed, and 25 requests became two. The order of operations matters: combining files you don’t need only moves the problem.

What it came to, and how I checked it

The mobile score went from 71 to 85, and the desktop score from 97 to 99. LCP came down from 5.3 to 3.8 seconds under simulated conditions, with 1.3 seconds observed in real conditions. CLS went from 0.14 to 0.05, first paint from 2.3 to 1.5 seconds. On the home page, 43 stylesheets became 2, and 45 scripts became 30.

After each step, I went through the whole journey again as a visitor, with the browser console open. Home page, carousel, counters, menu, search, shop with its filters, product page, add to basket, basket, checkout. If the score goes up while add-to-basket stops working, all you’ve done is close the shop faster.

Why I’m stopping at 85 for now

On an Elementor and WooCommerce site, the weight rarely comes from a single asset, more from the pile-up of plugins loading their files everywhere. Loading only what the page uses is still the most cost-effective lever, and it doesn’t cost a single extra plugin.

To get past 90 on mobile, the remaining step would be to put the critical styling straight into the page, which is visually more delicate and which I’d rather keep for after the launch. On my own site, built with native blocks, the question doesn’t arise in the same way. That’s what I describe in Elementor or the block editor: how to choose.