Why Does Ecommerce Website Speed Affect Sales and Rankings?
An ecommerce site is slow because of decisions rather than bad luck. Almost all of those decisions were made during the build. The rest arrived later, when somebody added one more app for a reason that seemed good at the time.
Why Speed Matters Twice
Speed affects whether somebody stays long enough to buy. Separately, it affects how a site is assessed in search. Those are different mechanisms with different consequences. Shops routinely address one while assuming they have handled both.
The human consequence. A shopper waiting is a shopper deciding whether to keep waiting, usually on a phone, frequently on mobile data, often with other things competing for their attention. The effect is not a cliff at some particular number of seconds. It is continuous, so every additional delay costs some proportion of the people who were going to continue.
The search consequence. Google has published guidance describing page experience, including how quickly a page loads and becomes usable, as among the things its systems consider. It is not the dominant factor and it is not nothing. It matters most as a separator between pages that are otherwise comparable.
The two are related without being the same. A site can satisfy every technical measurement and still feel slow, because measurements largely describe loading while a shopper experiences responsiveness.
There is a reason this problem persists in businesses that are otherwise attentive. Speed failures are invisible in your own data. Nobody who left because a page took too long appears as a complaint. They appear as a session that ended, indistinguishable from somebody who simply changed their mind.
What Actually Makes A Shop Slow
Four causes account for nearly all of it. The order matters, because businesses reliably reach for the last one and skip the first.
Images. Almost always the largest single contributor and the least interesting to talk about. Photographs uploaded straight from a camera, at a resolution intended for print, then sent in full to a phone that will display them a few centimetres wide. A single product page can carry more image weight than the entire rest of the site.
Themes carrying features nobody uses. A theme sold to thousands of shops has to support all of them, so it arrives with code for sliders, galleries, quick views, countdowns and layouts you will never enable. Much of that loads regardless.
Third party scripts. Analytics, chat widgets, tracking pixels, review services, advertising platforms. Each one loads from somebody else's server, which means your page is waiting on infrastructure you neither control nor monitor.
Apps. Specific enough to ecommerce, plus consequential enough, to have the next block to itself.
Worth noticing what is not on that list. Hosting matters on self managed platforms and it is rarely the cause on hosted ones, despite being the first thing many businesses suspect. The commonest actual cause is a folder of photographs nobody resized.
The App Problem
Every app added to a shop brings code with it. The way that accumulates is peculiar to ecommerce.
It loads everywhere. An app doing something on the product page frequently loads on every page of the shop, including pages where it has nothing to do.
Apps do not coordinate. Two apps needing the same underlying library will usually each bring their own copy, because neither knows the other exists.
Each adds another dependency. Apps load resources from their own servers, so a page can end up waiting on several unrelated third parties before it finishes.
Removing one does not always remove it. This is the part almost nobody knows. Apps that insert code into a theme frequently leave it behind when uninstalled, so a shop can be loading code for an app it stopped paying for two years ago, doing nothing, on every page, for as long as that theme remains.
The result is accumulation nobody notices, because each addition was small and individually justified. A shop that felt fast at launch becomes slow over three years without a single decision that looked like a mistake.
The exercise worth doing is unglamorous and reliably productive. List every app, what it does, whether anybody uses it and what it costs each month. Most shops find several they had forgotten. The monthly saving frequently pays for the work of removing them properly.
Measuring It Properly
Most speed decisions are made on a number that was never intended to be a target, produced by a test that does not resemble a customer.
Laboratory data. A test run on demand in controlled conditions. Repeatable, immediate and excellent for diagnosis, since it tells you what a page is made of. It does not tell you what your customers experienced, because it was not any of them.
Field data. What real visitors actually encountered, gathered over time. Genuinely representative and slower to accumulate. It also needs enough visitors to be meaningful.
Use the first to find problems and the second to know whether they mattered. Businesses commonly do the reverse. Others use only the first and assume it describes reality.
Why a score is not a target. A score compresses many measurements into one figure for convenience. Optimising the figure can diverge from improving the experience, since there are ways to make a number rise while a page feels no better to use.
Why testing from your office misleads. A fast wired connection, a powerful computer and a browser that has already visited the page. Your customer has none of those. Test on a phone, on mobile data. Test category and product pages rather than only the homepage, since the homepage is usually the lightest page on the shop.
What Can Be Fixed Afterwards
A good deal, which is worth knowing before anybody proposes rebuilding a shop on performance grounds.
Images. Resized to the dimensions actually used, saved in a modern format and loaded only when needed. The single largest available gain on most shops and the least disruptive, since nothing about the site changes visibly.
Scripts. Removing what is no longer used, which is usually several things, then deferring what does not need to load immediately.
Apps. Removing the unused ones and, importantly, clearing the residue described in block three rather than assuming uninstalling did it.
Delivery and caching configuration. How and from where files reach a visitor, which is frequently left at whatever the defaults were.
Fonts. Loading fewer of them, in fewer weights, in a way that does not leave text invisible while waiting.
The reason this matters commercially is that these are all achievable inside a maintenance arrangement rather than a project. A shop being told it needs rebuilding for performance reasons should establish which of these five have actually been attempted first, because a rebuild that skips them will produce a new shop with the same photographs.
What Cannot
Three things are not fixable by tuning. Recognising them prevents money being spent on optimisation that cannot succeed.
Theme architecture. A heavy, poorly constructed theme sets a floor beneath which no amount of adjustment will take you. You can optimise around it and you cannot optimise it away.
Platform limits. On hosted platforms some parts of how a page is assembled and delivered are simply not reachable. That is the trade described in the platform guide, appearing here in concrete form.
Structural decisions. How page types are constructed, how much a category page has to assemble before it can show anything and how many separate requests a page inherently makes. These were settled during the build.
How to tell which situation you are in. Three checks, in order. Test a simple page on your own site with almost nothing on it, since if that is fast the problem is what you have added rather than the foundations. Test the theme's own demonstration site, because if that is slow the theme is the ceiling. And compare a product page against a category page, since a large gap points at how one page type is assembled rather than at the site as a whole.
Those three take about twenty minutes and they settle whether you are buying optimisation or a rebuild.
Platform Differences
Platforms differ on performance in a way that is easy to state without turning this into a comparison of products.
Hosted platforms put a floor under performance and a ceiling on it. The infrastructure is managed by people who do that professionally, so the baseline is consistent and a shop is unlikely to be catastrophically slow through hosting alone. The same arrangement means parts of the delivery are not yours to change, so when you reach the ceiling there is nothing further to do.
Self managed software removes both. Everything is reachable, so anything can be improved. Nothing is guaranteed, either. Performance becomes a direct function of hosting quality and maintenance discipline. A well run installation on good infrastructure can be very fast. A neglected one on cheap hosting will be slower than anything a hosted platform would have allowed.
Website builders sit closer to the hosted end, with a lower ceiling and a similar floor, which is generally acceptable at the catalogue sizes they suit.
The practical consequence for a buyer is that performance should not be the reason a platform is chosen, since the floor is adequate almost everywhere and the ceiling only matters to shops large enough to reach it. That decision belongs in which platform is best for ecommerce web design.
Common Mistakes
Each of these consumes effort that would have produced a genuine improvement elsewhere.
Chasing a perfect score. The last portion of any scoring scale is disproportionately expensive and delivers the least to actual customers. A shop that has reached a comfortable position and keeps spending is optimising a measurement rather than an experience.
Installing an optimisation app to fix the problem caused by apps. Stated plainly it is obviously circular. It happens constantly, because the alternative involves removing things somebody once wanted.
Uploading full size photographs. The largest cause of slow shops, the easiest to fix and the one nobody wants to talk about because it is not technical enough to feel like a solution.
Testing the homepage only. The homepage is usually the lightest page on the shop. It is not where people buy, either. Category and product pages carry the images, the variants and most of the app code, which makes them both slower and more important.
The pattern connecting all four is a preference for interventions that feel technical over interventions that work. Where these decisions get made permanently is covered in how web design affects ecommerce SEO.
We check the images
before quoting a rebuild.
Most slow shops are carrying unresized photographs and code from apps nobody uses. We establish whether the problem is what has been added or what it was built on, which decides whether you need maintenance or a new shop.
What a build covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Twenty guides.
One subject.
This page covers speed. The rest of the series covers where conversion is lost, how category and product pages should work, what a build costs and why the search ceiling is set during the build.
