How to Speed Up an E-Commerce Store in 2026 (Without Breaking Checkout)
Your homepage is not the problem. Product pages, variant switching and checkout are where store speed actually fails — and where the fixes pay for themselves.
Most site speed advice is written for brochure sites. A store is a different problem, because the pages that earn your money are the slowest ones you have.
Your homepage is light. Your product pages carry a gallery, a variant selector, reviews, related products and three tracking scripts. Your cart recalculates on every change. Your checkout loads a payment iframe. Those are the pages a buyer has to get through, and they are the ones nobody tests.
Here is how to fix store speed specifically, in the order that moves revenue rather than the order that moves a score.
The Three Numbers Google Measures
Core Web Vitals are assessed at the 75th percentile of real page loads, mobile and desktop separately. Passing means three-quarters of your visitors get an experience at or better than these thresholds:
- Largest Contentful Paint under 2.5 seconds — how quickly the main content appears
- Interaction to Next Paint under 200 milliseconds — how quickly the page responds when someone taps or clicks
- Cumulative Layout Shift under 0.1 — how much the page jumps around while loading
The 75th percentile matters more than it sounds. Your store can feel instant on your own laptop on office wifi and still fail, because a quarter of your customers are on a mid-range phone on mobile data. That is who the threshold is protecting.
Measure the Pages That Take Money
The single most common mistake is running a speed test on the homepage, fixing what it reports, and declaring victory.
Test four templates separately: your homepage, a product page with a full gallery and reviews, a category page with forty products, and the cart. These behave nothing like each other. In almost every store we audit, the product page is two to three times heavier than the homepage, and the category page is worse.
If you optimise only what your homepage test reports, you will spend real effort on the one page that was never the bottleneck.
Use field data where you have it. Lab tools give you a controlled score; field data tells you what actual customers experienced. If your store is new or low-traffic, field data will not exist yet, and lab numbers are all you have — just be aware you are optimising against a simulation.
Product Images Are Usually the Entire Problem
On most stores, images are the majority of page weight, and the hero product image is almost always the LCP element. Fixing images fixes LCP, and LCP is the metric most stores fail.
- Serve AVIF or WebP with the original as fallback. Modern formats are typically 25 to 50 percent smaller than the JPEG equivalent at the same visual quality.
- Set explicit width and height on every image. This costs nothing and eliminates a large share of your layout shift.
- Give the main product image priority loading, and lazy-load everything below the fold — including the rest of the gallery.
- Stop uploading 4000px photographs. Serve the size the layout actually renders, at 2x for retina, and no larger.
- Do not lazy-load the hero image. It is the LCP element; delaying it is the opposite of what you want.
That last point catches people constantly. Someone enables lazy loading site-wide, the hero image gets deferred, and LCP gets worse while the total page weight looks better.
Third-Party Scripts Are the Tax You Forgot You Agreed To
Every pixel, chat widget, review app, upsell tool, heatmap recorder and abandoned-cart script runs in the same main thread as your store. Each was added for a reason. Very few are ever removed.
Audit them properly. Open your network panel, list every third-party domain your product page contacts, and for each one ask who owns it, what it earns, and whether anyone has looked at its data in the last quarter. Stores routinely find two or three scripts nobody can account for.
For the ones that stay: load them after the page is interactive rather than in the head, use async or defer, and be especially suspicious of anything that injects visible content. Chat bubbles and review badges that appear late are a common cause of layout shift.
Variant Switching Is Where INP Goes to Die
This one is specific to stores and it is badly under-diagnosed.
When a customer taps a size or colour, the page usually updates price, availability, image and sometimes the whole gallery. If that work happens synchronously on the main thread — or worse, triggers a server request before anything visible changes — you get exactly the kind of delay INP is designed to catch.
The fix is to make the visible response immediate. Swap the image and price from data already on the page, then reconcile with the server if you must. A customer comparing four variants will do this repeatedly, and each sluggish interaction feeds your INP score.
Layout Shift Has Store-Specific Causes
Generic advice covers images and fonts. Stores shift for reasons of their own:
- Price and stock status injected by script after render
- Review stars and counts loading from a third-party app
- Discount badges and countdown timers appearing late
- Cart drawers and free-shipping bars pushing content down
- Related products and recently-viewed rails filling in after load
The fix is the same in every case: reserve the space before the content arrives. Give the review widget a fixed-height container. Render the price server-side rather than populating it client-side. If a promo bar might appear, leave room for it.
Cart and Checkout Deserve Separate Attention
These pages have the highest intent and the least tolerance. Someone who has reached checkout has decided to buy — every second of friction now is a lost order rather than a lost visit.
Cart pages are frequently slow because they recalculate totals, shipping and discounts on every quantity change, often with a full page reload. Update quantities without reloading, and debounce recalculation so three quick taps do not fire three round trips.
At checkout, cut everything not needed to complete a purchase. Marketing scripts, chat widgets, recommendation engines and heatmap recorders have no business on a payment page. They add risk as well as weight.
Platform Notes
WooCommerce
Hosting is the variable that matters most, and cheap shared hosting is the usual culprit. Beyond that: enable object caching, exclude cart and checkout from page caching so customers do not see each other’s baskets, keep WooCommerce and its extensions patched, and audit plugin count — every plugin loads on every page unless you actively prevent it.
Shopify
You do not control the server, so your levers are the theme and the apps. App bloat is the dominant cause of slow Shopify stores: each app injects scripts that stay in the theme even after you uninstall the app. Check your theme.liquid for orphaned snippets from apps you removed months ago. Also audit how many apps inject on every page versus only where they are needed.
What Not to Spend Time On
Chasing a perfect score. A 100 in a lab tool with failing field data means you optimised for the test. The thresholds above are what Google uses; beyond them you are gathering points, not customers.
Micro-optimisations before the big ones. Minifying CSS saves kilobytes. Fixing an unoptimised 3MB hero image saves megabytes. Do them in that order.
Rebuilding on a new platform for speed alone. Almost every slow store is slow because of images, scripts and hosting — all three of which travel with you.
If your store runs on WordPress, we have a deeper walkthrough of the WordPress-side work: hosting, caching layers, database overhead and plugin auditing.
Frequently Asked Questions
How fast does my store actually need to be?
LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured at the 75th percentile on mobile. Hit those and you have passed. There is no ranking bonus for going further, though customers will still notice.
Does site speed affect rankings, or just conversions?
Both, but not equally. Core Web Vitals are a ranking signal and a comparatively small one — relevance and authority matter far more. Speed earns its keep through conversion and crawl efficiency, not through outranking a better page.
Why does my store score well in tests but feel slow?
Because you are testing the homepage on a fast connection. Test a product page, throttled to mobile, and the number usually changes considerably.
Will a caching plugin fix everything?
It will help time to first byte on repeat views and it is worth having. It will not compress your images, remove third-party scripts, or make variant switching responsive. Caching accelerates delivery of whatever you built; it does not make what you built lighter.
How many apps or plugins is too many?
There is no number. One badly written script does more damage than fifteen well-behaved ones. Measure the impact rather than counting.
Want to know which of these is costing you most? Send us your store URL and we will test the four templates properly, on throttled mobile, and tell you the three things worth fixing first — in order, with the reasoning.
Why trust our experts?
At ARIOSETECH, every article is written by specialists who build and operate real e-commerce stores — not generalists. Our content is grounded in hands-on experience across WordPress, WooCommerce and Shopify, and reflects what actually works for stores in live markets. We keep it practical, current, and honest so you always get reliable, actionable guidance.
