Store performance · 12 Nov 2026 · 6 min read
Ecommerce site speed: why product pages slow down and what to fix first
Stores get slow a little at a time, one image, app or tracking tag after another. This guide shows where the weight usually sits and how to test it properly.
The short answer
Ecommerce site speed usually suffers from oversized product images, apps and tracking scripts added over time, and heavy galleries or sliders. Fix images first, then remove scripts you do not use, then test the home, category, product, cart and checkout pages separately on a real phone and a normal mobile connection.
Why ecommerce site speed slips over time
Ecommerce site speed is harder to keep up than the speed of a brochure site, for plain reasons. Every page carries many images. Reviews, chat, analytics, advertising tags and recommendation tools each add their own code. The theme brings its own scripts and fonts. Nobody decides to make the store slow. It happens through a series of reasonable additions, each of which costs a little.
The weight is also uneven. Each type of page has its own usual culprits, so a test on the home page tells you little about the page where people actually decide to buy.
| Page type | What usually weighs it down |
|---|---|
| Home page | Banner sliders, background video, large hero images, several promotional blocks |
| Category page | Dozens of product thumbnails, filter and sort scripts, quick-view pop-ups |
| Product page | The photo gallery and zoom, variant swatches, a reviews widget, recommendation blocks, stock messages |
| Cart | Upsell widgets, shipping estimators, discount code tools |
| Checkout | Payment scripts, address lookup, fraud checks, tracking tags |
Product images: the first place to look
Images are usually the heaviest part of a product page, so they are the first thing to check. These are the faults that come up most.
- The file is far larger than the space it fills. A photo exported at the full size from a camera, then shown in a small box, still downloads in full.
- Category thumbnails are the full product photo scaled down by the browser instead of smaller copies made for the purpose.
- The photo has no width and height set, so the browser cannot reserve space and the page jumps as images arrive.
- Every gallery photo loads at once, including zoom versions that most visitors never open.
- The format is older than it needs to be. Modern formats such as WebP and AVIF are often smaller at similar quality, though you should check browser support for your audience.
- The first, main product photo is set to load lazily. Lazy loading suits photos further down the page. The main image at the top should load straight away.
The fixes sit in two places: how the photographer or team exports files, and how the platform serves them. Many platforms create smaller copies and pick one to suit the screen, but only if the theme asks for it. A custom build needs the same behaviour specified. The ecommerce product page checklist covers how many photos a product needs, and each photo should earn the weight it adds.
Scripts and apps: the hidden cost
Every app adds code. Often that code loads on every page, including pages where the app does nothing. Reviews, chat, loyalty pop-ups, currency switchers, countdown timers and several tracking tags can run side by side. Scripts that come from another company's server are outside your control, and a slow one can hold up the whole page or make taps feel delayed.
A script audit is the most useful speed job on most stores, and it costs nothing but time.
- List every script and app that loads, with what it does and who asked for it.
- Remove duplicates, such as two analytics tools, and old campaign tags for advertising you no longer run.
- For each remaining item, ask what it earns or saves. If nobody can say, test removing it.
- Remove one item at a time on a staging copy, and compare the results.
- Where a script is needed but not urgently, load it later, after the page is usable.
Some tools deserve a closer look. A bundle or kit picker is a heavy script, so check how a product bundle is built before adding one to every product page. A live stock badge that calls an outside system on each view needs caching, which is worth raising when you review inventory management. A shipping calculator widget adds code, while plain text near the buy button costs nothing, as the guide to writing shipping and returns policies shows.
Fonts, themes and layout shifts
Custom fonts must download before text appears in them. Each weight and style is another file, so a theme that uses six styles asks for six downloads. Use fewer, and make sure the page shows readable text while the font loads.
A heavy theme carries code for features you never switch on. When two themes look alike in a demo, the lighter one is the better start, and the difference is visible in a test.
Layout shifts happen when something arrives late and pushes content down. On stores the usual causes are images without set dimensions, a banner that appears after load, a cookie notice that shoves the page, a reviews widget that fills in late and a sticky bar that changes height. A shopper about to tap Add to cart who sees the button move will mis-tap, which makes this a sales problem as well as a technical one.
How to test an online store properly
Test each type of page, and do not stop at the home page. Use a lab test and real-visitor data together, because they answer different questions. A lab test, such as Lighthouse in Chrome or the lab section of PageSpeed Insights, is a controlled run that helps you find causes. Field data comes from real visitors, and Search Console's Core Web Vitals report groups similar pages when there is enough data. Field data tells you whether shoppers are actually affected.
Core Web Vitals cover three things. LCP times how long the main visible content takes to load. Interaction to Next Paint, or INP, measures how quickly the page responds to taps and clicks. Cumulative Layout Shift, or CLS, measures how much the layout jumps. Google publishes the ranges it treats as good on web.dev, so check the current figures there instead of relying on a number remembered from a blog.
| Test | What it tells you | Watch for |
|---|---|---|
| Product page on a mid-range phone, normal mobile connection | What most shoppers experience | Slow main photo, late-loading widgets, laggy taps |
| Category page with filters in use | Whether filtering feels instant | Delay after tapping a filter, shifting product grid |
| Add to cart and checkout, start to finish | Responsiveness where it matters most | Buttons that take a moment to react, payment scripts that load late |
| Signed-in versus signed-out visitor | Whether accounts add weight | Extra personalisation scripts |
| Cookie notice accepted versus declined | Which tags load under each choice | Pages that are quick only when tags are blocked |
Run each test several times, because results vary between runs. Keep a simple log with the date, the page, the tool, the settings and the change you made. Without a log, you cannot tell whether an improvement lasted.
A fix order that pays back
- Record a baseline for the five page types.
- Resize and compress product images, and set their dimensions.
- Make sure the main product photo is not lazy-loaded, and that photos lower down are.
- Run the script audit and remove what has no job.
- Simplify the gallery and any slider or video that sits above the fold.
- Cut fonts to what the design really uses.
- Ask about caching and a content delivery network if you run a custom build or your own hosting. On a hosted platform, the platform usually controls this and your choices are the theme and the apps.
- Test again and update the log.
Be realistic about limits. Speed work makes pages more pleasant to use, but it will not fix a weak offer, and it will not on its own change your search position. If you are still planning the store, build speed checks into the launch steps in how to start an online store so you test with your real photos before opening. For development help on an existing store, the ecommerce solutions page sets out what Liftup Technologies builds.
Related guides
- Ecommerce solutions
- Ecommerce product page checklist
- How to start an online store steps in order
- Shipping and returns policy how to write them
- Ecommerce inventory management basics
- Product Bundles for Ecommerce Stores: How They Work
Questions and answers
Why is my online store slow?
Usually because of accumulation: large product images, apps and tracking scripts added over time, a heavy theme and sliders or video near the top of pages. Test the home, category, product, cart and checkout pages separately to see where the weight sits.
What slows product pages down most?
Oversized photos and third-party scripts are the most common causes. Galleries that load every zoom image at once, reviews and recommendation widgets, live chat and several tracking tags add to it. Check images first, then audit scripts.
How do I test a store properly?
Test every page type on a real phone and a normal mobile connection, run each test more than once, and compare lab results with real-visitor data such as Search Console's Core Web Vitals report. Keep a log of each change and its result.
Should I lazy-load every image?
No. Lazy loading suits photos below the first screen. The main product photo at the top should load straight away, because delaying the most visible image slows the page for the shopper.
Do I need a CDN for my store?
Many hosted platforms already serve files from a network of servers, so check what yours does. On a custom build or your own hosting, a content delivery network is worth asking your developer about, especially for images.
Should I remove apps to make the store faster?
Remove any app that does not earn money or save work, and test the others one at a time on a staging copy. Keep an app if the business case is clear, but check what it adds to the pages where it loads.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.