The worst thing about a slow store is that it never shows up in any report. There is no error, no alert - just sales lower than they should be, and someone who closed the tab after waiting two seconds for a product photo. Most store owners have no idea how fast their store really is, because they test it on their own fast connection and their own desktop - while the customer is on a phone, on a train, on 4G.
Good news: you do not need to be a developer to check this. One free Google tool and fifteen minutes is enough. I will show you exactly where to click, what to read and which numbers actually mean something - and which you can ignore. At the end you get a simple checklist plus the point at which it is worth calling someone in.
I work by one rule: measure first, fix second. Without numbers every change is guesswork - and in a store, guesswork costs money.
Start with PageSpeed Insights - and make sure you look at mobile
Go to pagespeed.web.dev, paste your store address and hit “Analyse”. A moment later you get a score. The single most common mistake I see in client stores: people look at the “Desktop” tab and feel good about themselves. What counts is “Mobile”.
Why mobile? Because phones now carry most of the traffic in e-commerce, Google grades a site mainly on its mobile version, and a phone is simply slower - weaker processor, worse connection. A desktop score can easily be 30-40 points higher and give you the false comfort that everything is fine. Look at mobile, because that is where the truth is.
You will see two sections. The upper, colourful one is “field data” (if the store has enough traffic) - how real users actually experienced the site over the last 28 days. The lower one is a lab test from a single run. If you have field data, trust it most - that is not a simulation, those are your customers.
What helps: run the test 2-3 times and take the middle result - a single measurement can lie because of a momentary spike in server load. And test more than the home page: check a product page and the cart too, because that is where a person decides to buy.
What those odd acronyms mean: LCP, INP, CLS, TBT
These are the Core Web Vitals - the set of metrics Google uses to describe how a page “feels” to a human. It sounds technical, but each one answers a simple question. Let me put them in plain language.
- LCP (Largest Contentful Paint) - “how fast do I see the most important thing on screen”, usually a large product photo or a headline. This is the number that matters most. A good result is up to 2.5 s. Above 4 s the customer feels the site crawling.
- INP (Interaction to Next Paint) - “does the page react when I tap it”. You tap “Add to cart” and nothing happens for a moment - that is a high INP. A good result is under 200 ms.
- CLS (Cumulative Layout Shift) - “does the layout jump around under my finger”. You land on the page, you go to tap a button, and right then a banner loads in and you tap something else. Annoying and expensive. A good result is under 0.1.
- TBT (Total Blocking Time) - a lab-test metric, “how long the page was frozen and nothing could be done”, usually because of heavy JavaScript. High TBT is almost always too many scripts: plugins, chat widgets, tracking tools.
You do not need to memorise the acronyms. It is enough to know: LCP says “how fast you see it”, INP and TBT say “how fast it reacts”, and CLS says “whether it shakes”. More on how these measures behave specifically in WooCommerce stores I set out in a separate piece on Core Web Vitals in WooCommerce.
How to read the score without panicking
The number at the top (say 38/100) is an index built from several metrics - it is indicative, do not treat it as a verdict. I look at it first to know whether there is a problem at all, then I go further down to the specifics.
Below the score, PageSpeed shows an “Opportunities” section - a list of things to improve, sorted by how many seconds each one could potentially give back. This is the most valuable part of the report and the part most people scroll past. Read it top to bottom: your biggest dead weight is sitting right at the top.
Typical entries you will see there, and what they actually mean:
- “Serve images in next-gen formats” / “Properly size images” - your photos are too heavy. A very common and very rewarding thing to fix.
- “Reduce unused JavaScript / CSS” - too much code from plugins and the theme is loading where it is not needed.
- “Reduce initial server response time (TTFB)” - the server thinks for a long time before it even starts sending the page. That points to a hosting problem or missing caching.
What helps: do not attack everything at once. Take the single top item on the list, the one promising the most saved seconds, and make that your first target. Fixing from the top down gives the biggest effect for the smallest cost.
Look under the bonnet - the waterfall in your browser
PageSpeed tells you “what” is wrong. If you want to see “why”, there is a free tool built into your browser. In Chrome, right-click on your store page, choose “Inspect” (or hit F12), go to the Network tab and reload the page. You will see the waterfall - a list of everything the store downloads, one file under another, with bars showing how long each one takes.
You do not need to understand all of it. You are looking for three things:
- The longest bars - what loads slowest? If those are huge images, you have your culprit.
- The number of entries - if the page pulls 200 files, that is almost always an excess of plugins and third-party scripts.
- The total weight at the bottom - how many megabytes the whole page weighs. Above 3-4 MB on a phone is already a lot. A well-optimised product page can get under 1.5 MB.
At the very top of the list you will also see the first request to your own address - the time labelled “Waiting (TTFB)” is exactly the moment when the server is “thinking”. If that is long (above 0.6-0.8 s), the problem sits with hosting or missing caching, not with your images.
Where the biggest dead weight usually sits
The blame almost always splits across three areas. This is the order worth looking in:
- Images. The most common and the easiest sin to fix. A photo uploaded straight from a camera weighs 4-6 MB, and there are hundreds of them in the catalogue. The fix: compression, WebP/AVIF format, serving the image at the size it is actually displayed at, and lazy-loading everything below the first screen.
- Plugins and scripts. It is not the count that matters, it is what they do. One badly written plugin loading its own code across the whole site can slow a store down more than twenty light ones. What helps here is an audit that shows who eats how much time, and then cutting the unnecessary ones without mercy.
- Hosting and TTFB. If the server takes a long time to respond before it sends anything, no amount of image optimisation will save it. Cheap shared hosting for 10 PLN a month is the first suspect. What helps is decent WooCommerce-grade hosting plus properly configured page caching.
If you run a store and want to understand how these three areas connect into one coherent repair plan, I described that in the context of speeding up WooCommerce stores - there, performance is part of the whole, not a patch bolted on at the end.
A checklist you can run yourself
Sit down for 15 minutes and go through this in order. Write the numbers down - without them, in a month you will not be able to tell whether anything improved.
- Test in PageSpeed Insights on the Mobile tab (not desktop).
- I checked the home page, a product page and the cart separately.
- LCP under 2.5 s? (above 4 s = urgent).
- CLS under 0.1? (nothing jumps around under my finger).
- I looked at the “Opportunities” list and wrote down the top 3 items.
- In the Network tab I checked the total page weight (target: under 2-3 MB on mobile).
- I checked TTFB - the server’s “thinking” time (target: under 0.6 s).
If every point is green - congratulations, you have a fast store and you are not losing money on it. If several are red, you now have something more valuable than a hunch: a concrete list of what to fix.
What you can do yourself, and when to call a developer
Some things on this list you will handle on your own or with a good plugin: compressing images, switching on basic caching, removing a few obviously redundant plugins. Those are real wins and worth taking.
It is worth reaching for help when: TTFB stays high despite caching (that smells of hosting or the database), you have no idea which of your twenty plugins is actually choking the store, or - the case I see most often - you are afraid to touch anything in case you break the store mid-sales-day. That is not weakness. That is the moment when someone experienced does in an hour what would cost you a weekend and a lot of nerves. What that help realistically costs I set out separately in the piece on what it costs to speed up a store.
The key thing is that you now walk into that conversation with numbers in hand. You know what is wrong, and nobody will sell you a “rebuild from scratch” when tidying up three things is enough.
Let’s do it together
If you ran the test and see red numbers but do not know where to start - send me a link to your store. I will do a free review, measure it properly and point out exactly what is choking your store and what can be sped up fastest and cheapest. No commitment and no “from X PLN” - you get specifics in writing.
Frequently asked questions
How often should I test store speed? Once a month in a quiet period, and beyond that after every bigger change: a new plugin, a theme switch, a large product import. A WordPress store slows down quietly, through the sum of small additions - regular measurement catches it before it hits sales.
Why does the PageSpeed score jump around between measurements? Because the lab test is a single run - a momentary spike in server or network load can move the score by a dozen or more points. That is why I measure 2-3 times and take the middle one, and when a store has field data I look primarily at that, because it describes 28 days of real visits rather than one simulation.
Why is the mobile score so much lower than desktop? The mobile test simulates a weaker processor and a slower connection, which is closer to the conditions most people actually shop in. A 30-40 point gap in favour of desktop is normal, and that is exactly why the desktop score lulls you into a false sense of security. Google grades a site mainly on its mobile version, so that is the real one.
Do I need 100/100 for the store to be fast? No. The number at the top of the report is an indicative index - the specific metrics matter more: LCP under 2.5 s, CLS under 0.1 and TTFB under 0.6 s. A store with a decent mobile score and good Core Web Vitals earns more than one chasing points at the cost of features.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.