Why is your ecommerce site slow (and what actually fixes it)

Speed problems rarely announce themselves. There is no error message, no outage, no angry email. What happens instead is quieter and more expensive: a share of your visitors, mostly on mobile, mostly on their first visit, decide the page is not loading and leave before it finishes. They do not complain, because as far as your inbox is concerned they were never there. Meanwhile the store looks perfectly fine to you, because your browser has cached half of it and you are testing on office wi-fi.

That is why slowness usually gets diagnosed late, after a conversion rate has been quietly drifting for months. The good news is that this is one of the more measurable problems in ecommerce. There are published thresholds, free data from your own real visitors, and a fairly short list of causes that explains most cases. The work is less clever engineering than disciplined removal.

How slow is too slow for an ecommerce site?

Google publishes a usable definition through Core Web Vitals, three metrics measured on real visits rather than lab simulations. Each is assessed at the 75th percentile of visits over a rolling 28-day window, which matters more than it sounds. The standard is not your best visit or even your average visit. It is the experience of your slower quarter of users, which skews heavily towards mobile, older devices and patchier connections.

Metric	What it measures	Good	What failing feels like
Largest contentful paint (LCP)	Time until the main content appears	2.5 seconds or less	A blank or skeletal page while someone waits
Interaction to next paint (INP)	How quickly the page responds to taps and clicks	200 milliseconds or less	Tapping Add to cart appears to do nothing, so they tap again
Cumulative layout shift (CLS)	How much the layout moves while loading	0.1 or less	The button shifts as they reach for it and they hit the wrong thing

A page needs to clear all three to count as good. Treat that as a floor rather than an ambition: clearing the thresholds means you have stopped actively losing people to performance, not that your store is fast. And measure the templates that carry your revenue, which are product and category pages on mobile, not the home page that owners instinctively test.

Why is my ecommerce site slow? Five causes that explain most of it

On a hosted platform such as Shopify, BigCommerce or managed WooCommerce, the underlying server is rarely the constraint. The weight is almost always something that was added deliberately, one decision at a time, by people who each had a good reason.

• Accumulated apps and third-party scripts. Reviews, upsells, pop-ups, live chat, loyalty, currency switchers, analytics, pixels, heatmaps. Each loads its own code, usually on every page rather than only where the feature appears.
• Oversized images and autoplay video. A hero image exported at full desktop resolution and served unchanged to a phone is the single most common cause of a failing LCP.
• Theme and page-builder bloat. Flexible drag-and-drop themes buy you layout freedom by shipping code for every feature you might use, including the ones you never enabled.
• Distance and delivery. If your assets are served from an origin on the other side of the world with no Australian edge, every visitor pays that round trip. Regional and mobile connections pay it hardest.
• Too much happening before first paint. Render-blocking scripts, custom fonts loading before text can show, carousels and chat widgets initialising ahead of the content someone actually came for.

How do I find out what is actually slowing my store down?

Separate field data, which is what real visitors experienced, from lab data, which is a simulated test on a machine somewhere. Lab scores fluctuate run to run and rarely reflect your actual customer mix. Field data is the version that counts.

A workable sequence: start in Search Console's Core Web Vitals report, which groups your URLs by template and tells you whether the problem is site-wide or confined to one page type. Run PageSpeed Insights on one representative product page and read the field section first, then the lab diagnostics for the specific files it blames. Open your browser's developer tools on a throttled mobile profile and watch the network waterfall, which shows which requests block rendering and how long each third party takes to answer. Check your platform's own speed or app report if it has one.

Then do the step most audits skip: test from an Australian location, not a default North American one, and cross-reference against your Google Analytics 4 setup to see which templates actually carry traffic and revenue. Fixing a slow page nobody visits is housekeeping, not growth. If performance has degraded suddenly rather than gradually, work through the broader checklist in why ecommerce sales suddenly drop, because a recent app install or theme update is a common shared cause.

What should I fix first?

Sequence by effort against impact. Most stores can recover a meaningful share of their load time without a developer, and the owner-level fixes are the ones that tend to stay fixed.

Fix	Effort	Typical impact	Who can do it
Compress and correctly size images, use modern formats	Low	High	Owner or assistant
Remove unused apps and clear their leftover code	Low	High	Owner, with a list
Audit and consolidate tracking tags	Low	Medium	Owner or marketer
Lazy-load below-the-fold images and embeds	Medium	Medium	Developer
Defer non-critical scripts until after first paint	Medium	High	Developer
Reserve space for images, banners and widgets (CLS)	Medium	Medium	Developer
Serve assets through a CDN with Australian presence	Low	Medium	Platform or host setting
Replace a heavy theme or page builder	High	High	Planned project
Change platform or hosting	High	Variable	Last resort

Work top down and re-measure after each change rather than shipping six at once, or you will never know which one earned the improvement. The bottom two rows are genuine options but poor starting points. If you do reach that conclusion, plan it properly so rankings and redirects survive the move, as set out in changing ecommerce platforms without losing SEO traffic. This kind of sequencing work sits inside Alpha Vault's e-commerce and digital services.

Do apps and tracking scripts really make that much difference?

More than almost anything else, for two reasons owners rarely anticipate. First, most apps inject their code on every page of the store, not only the page where the feature is visible, so a size-guide app can be loading on your blog and your checkout. Second, uninstalling an app frequently leaves its snippets behind in the theme, which means the slowdown persists after the subscription stops. It is common to find a store carrying code for a review widget replaced two years ago, a pixel from an agency that no longer works there, and two analytics tools reporting the same thing.

The audit is unglamorous and effective. List every app and every tag, and for each one answer two questions: what does it earn, and does it need to run on every page? Anything that fails both goes. Then check the theme files for orphaned snippets from apps already removed. The same discipline you would apply to reducing software subscription costs applies here, and the two reviews are efficient to run together, because the subscription you cancel is usually the script you were also carrying.

Does site speed affect Google rankings and ad costs?

Page experience is one modest input among many. It behaves more like a tie-breaker between pages of comparable relevance than a primary ranking factor, so speed work alone will not lift a page that does not deserve to rank.

The larger commercial effects are elsewhere. Slow pages lose buyers who had already decided, which is why speed is usually a conversion problem before it is an SEO one, and it sits alongside the other fixes in improving product page conversion rate. In paid search, landing page experience feeds Quality Score, so a slow destination can quietly raise what you pay for each click. And as more discovery happens through AI assistants and crawlers that time out on heavy pages, being cheap to fetch is becoming part of being found at all.

How do you keep a fast store fast?

Speed is not a project you finish. Stores get slow the same way garages fill up, one reasonable addition at a time, so the durable fix is a rule rather than a cleanup. Set a simple performance budget: a page weight and a load time your product and category templates are not allowed to exceed. Make every new app earn its place by answering what it will add and what it will cost in load time, and give someone the authority to say no. Re-measure quarterly and after every theme change, promotion or new app, because that is when regressions arrive. Keep a short record of what changed and when, so the next slowdown takes an afternoon to diagnose instead of a fortnight.

None of this requires a rebuild, and that is the point worth holding onto. The stores that stay fast are rarely the ones with the most sophisticated infrastructure. They are the ones that measure what real customers experience, remove more than they add, and treat every new script as a cost rather than a free feature. If your conversion rate has been drifting and you suspect the site is part of the reason, book a consultation and we will work through the numbers and the load together.