Ecommerce Development · focused work
Ecommerce site speed optimization
Speed on a store is not a score out of a hundred. It is the gap between a tap and the product being visible, and the gap between choosing a filter and the results changing. Those two moments decide whether someone on a phone with an ordinary connection stays. So the work is measured on real visitors rather than on a test run from a fast machine on office broadband.
This is the right work if
- Field data shows the main product image taking seconds to appear for mobile visitors
- Nobody in the business can list every third-party script or say who asked for it
- The layout jumps while loading and shoppers tap something other than what they aimed at
- Category pages pause visibly between a filter being chosen and the grid updating
- Speed was improved once and has drifted back since a run of app installs
What it is
The scope of speed work on a store
The target is the templates that carry revenue, measured with data from real sessions: how long the largest thing on the screen takes to appear, how quickly the page responds to the first interaction, and how much the layout moves while it loads. Those three describe the shopper's experience better than any aggregate score, and they can be read per template and per device so the work goes where the money is.
On most stores the largest single cost is accumulation. Review widgets, chat, popups, personalisation, several analytics tags and sometimes two tag managers, each added for a reason that made sense at the time. So the first deliverable is an inventory of every third-party script with an owner and a purpose, and a decision on each. After that the work is structural: render the content that matters on the server, defer the rest, size and format images for the space they occupy, load fonts without blocking or shifting, shorten server response, and cache what can be cached. The last step is a budget, because speed that is fixed once and not defended drifts back within a few app installs.
How it is done
The work, in order
What changes
- The product image and price arrive quickly for visitors on ordinary phones and networks
- Every script on the store has a named owner and a reason to be there
- The layout stops shifting under the shopper's finger while the page settles
- New apps are judged against a budget before they are allowed to stay
Measure real sessions first
Pull field metrics segmented by template and device, and compare them against a lab test of the same pages. Where the two disagree, trust the field data. A page that scores well on a wired connection and poorly for actual visitors is the normal case, not an anomaly.
Inventory and cut the scripts
List every third party with the page it loads on, its owner and its purpose. Remove anything nobody claims, consolidate duplicated tracking, and move what remains behind the first paint. This step usually returns more than any code change that follows it.
Fix images for the space they fill
Serve dimensions that match the layout on each breakpoint, use modern formats with a fallback, lazy load everything below the fold, and load the main product image eagerly with high priority so it is never queued behind decoration.
Stop blocking the first render
Inline only the styles the first screen needs and defer the rest, self-host fonts and preload them with a fallback sized to avoid a shift, and remove unused scripts from templates that never call them. Reserve space for anything that loads late.
Shorten the server and cache the rest
Measure time to first byte separately for anonymous, logged-in and cart-bearing sessions, because the last two often bypass the cache and are where the slow pages hide. Cache markup at the edge where the platform allows it and cache the API calls behind dynamic sections.
Defend it with a budget
Set limits for page weight, script count and the three field metrics, check them as part of releasing, and re-test after each app install. Without this the work is a one-off improvement rather than a property of the site.
Platform notes
Shopify
Images are served through the platform's own image service with sizing parameters, and app code arrives either as a theme extension or as script injected into the theme; the second kind is where most of the weight and most of the removable weight sits.
WooCommerce
Hosting, object caching and the plugin count shape response time more than the theme does, and full-page caching has to be configured so cart and account pages stay dynamic while catalog pages are served from cache.
Is chasing a perfect performance score worth the effort?
No. The score is a summary of lab measurements that may not reflect what visitors experience. Push the real-session numbers for the templates that carry revenue and let the score follow. The last stretch of a synthetic score usually costs more engineering time than the shopper will ever notice.
Which hurts more, a slow server or heavy front-end code?
Whichever the data says. A slow first byte delays everything after it and is often caused by uncached dynamic pages, while heavy front-end code delays interaction after the page appears. Measuring both separately takes an hour and prevents weeks of work aimed at the wrong layer.
Do apps have to be removed to make a store fast?
Not all of them, but the list has to be justified. Many apps load on every page while serving one template, and several can be replaced by a small amount of code in the theme. The realistic outcome is fewer apps, each loading only where it is used.
How often does speed need re-checking?
Whenever anything ships and on a fixed schedule regardless. Stores change constantly, and a single new tag or an unsized image in a new section can undo a quarter of work. A monthly reading of the field data per template catches drift while it is still small.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.