The ads are running, plenty of people click, but orders are not coming in. Try opening your site on your phone, on 4G, out on the street. The page stays blank for several seconds before the first picture appears. If you were a customer, you would probably hit the back button too.
A slow site never throws an error. It quietly sends visitors away, and all you see is a low order count with no obvious reason.
How slowness costs you customers
Picture a shop with a very heavy front door. People push, nothing happens, and most walk into the shop next door. A slow page works the same way, except visitors leave within seconds and never leave a note.
Google commissioned a study from two independent firms (55 and Deloitte) that followed 37 European and American brands and more than 30 million mobile sessions. The results are published on web.dev. When four speed measurements each improved by just 0.1 seconds, retail sites saw people spend 9.2% more, and the share of visitors going from a product page to the basket rose by 9.1%. This is one study of large brands, not a promise for your shop. It does show the direction: faster pages let more people keep going.
Speed also touches search. Google treats page experience, which includes speed, as one of many ranking signals. I have no number for how heavy that signal is, and you should be wary of anyone who gives you a confident one. What is certain is that real visitors feel the delay.
A five-minute self check
Open pagespeed.web.dev, Google's free tool. Paste the address of a page you care about, such as the home page or a best-selling product, and run the analysis. Wait about half a minute.
You will see two blocks. The upper one, when it exists, is "real user data" from the last 28 days, collected from Chrome browsers of actual visitors. The lower one is a test run done just now on a simulated device. Look at the Mobile tab first, because most shop visitors arrive on phones.
If your site is new or quiet, the real-data block may be empty. That is fine. Read the test run, and remember it varies from run to run. Test three times and take the middle result.
Three numbers in plain words
Google groups the experience into three numbers called Core Web Vitals. The "good" thresholds below come from the web.dev documentation.
The first is LCP (Largest Contentful Paint): the time until the biggest piece of the first screen appears, usually a banner or a product photo. It answers "how long until the visitor sees something real?" Good means within 2.5 seconds.
The second is INP (Interaction to Next Paint): after someone taps or clicks, how long before the page visibly reacts. If the add to cart button sits frozen for half a second, INP is poor. Good means 200 milliseconds or less.
The third is CLS (Cumulative Layout Shift), which measures whether the page jumps around while loading. You are about to tap a button, a banner slides in above it, the button moves down, and you tap the wrong one. That is high CLS. Good means 0.1 or less.
Google calls a page passing when 75% of real visits fall inside the good range for all three. So a test score of 95 does not automatically mean real customers see a fast site.
What you can do yourself
Most slowness on small shops comes from images. Photos taken on a phone are often several megabytes, while the page shows them small. Before uploading, resize them to roughly 1600 pixels wide and compress them. Tools such as Google's Squoosh do it right in the browser. WebP is usually lighter than JPG at the same quality.
Next, trim what you have bolted on. Every plugin, tracking snippet, chat widget and spin-to-win wheel adds a little loading time. List them, and remove the ones nobody uses. Also avoid autoplay video on the home page.
Finally, measure again after each big change. After a theme change or a new plugin, test once and write the score in a notebook. When the score drops, you will know which change caused it.
What to hand to a developer
Some things are not worth learning by trial and error. A slow server response (high time to first byte) usually comes from hosting or database setup. Page caching, blocking scripts that delay rendering, deferring code that is not needed yet, font loading, and images that jump because they lack dimensions all require touching code or server settings, and a wrong move can break the cart.
When you ask for help, send a screenshot of the PageSpeed result and say which page and whether it was mobile or desktop. A good developer names the exact metric that is poor and why, rather than promising to "make it faster". If you are a developer and want to see a step by step example with measurements, I wrote From 95 to 99 on Mobile Speed: What I Did to a Next.js Site.
Mistakes I see often
Some owners test the home page, see a good score and relax, while the product page, where people actually decide to buy, is twice as heavy because of a full photo gallery. Test at least three kinds of page: home, category, product.
Another is testing on an office computer with fibre internet and concluding the site is fast. Your visitor may be in a lift with one bar of signal. Use the Mobile tab and trust the moment you think "why is this taking so long".
The last is giving up because the score is not 100. You do not need 100. A sensible goal is all three numbers in the green, then put your energy back into products and ads.
What to do next
Today, test your three main pages, take screenshots and copy down LCP, INP and CLS. Fix the images first, since that is the cheapest job. If the result is still red, take it to a developer. If you want a second pair of eyes, message me. I take on custom web projects.
