Online store speed: a page-by-page plan
A store has five kinds of page, and each needs different speed work. What the data says about store platforms, and a plan from category pages to checkout.
In this guide
Why stores are different
A brochure site is a set of pages that look the same to every visitor. A store is a set of pages that change with the visitor: the basket, the prices, the stock, the address and the payment. That has two consequences for speed.
First, some pages cannot be cached the way others can. A shared copy of a cart page would show one shopper another's basket. Platforms handle this in different ways. For example, WooCommerce marks its cart, checkout and account pages as not cacheable, and Shopify renders its pages on its own servers.
Second, a store is heavy by nature. It has many pictures, many scripts for payments, reviews and tracking, and many plugins or apps. The 2025 Web Almanac's ecommerce chapter says that stores are unusually sensitive to performance because every extra second compounds: slower category pages reduce product views, slower product pages reduce add-to-carts, and slower checkouts reduce conversion. That is the chapter's reasoning about how a store works, not a measured result, but it matches how shopping flows run.
What the data says about platforms
The Almanac's chapter lists the share of stores that pass all three Core Web Vitals, using real-visitor data. On mobile, in 2025:
- Shopify: 76%.
- Squarespace Commerce: 69%.
- OpenCart: 68%.
- Wix eCommerce: 66%.
- PrestaShop: 50%.
- WooCommerce and Magento: 35% each.
The weak point on the lower platforms was mostly Largest Contentful Paint, the loading measure. Interaction was close across the group, and Magento also did poorly on layout stability.
The Almanac groups platforms by who runs the servers. Shopify is software as a service, so the platform owns the code and the hosting. WooCommerce is self-hosted, so a merchant or an agency runs it. The chapter's conclusion is that control tends to give steadier results, but nothing is fixed in advance: disciplined self-hosted and customized stores can do well.
So the data supports two statements at once. Some platforms give a better starting point. And a store's own choices decide a great deal. See Shopify speed, WooCommerce speed and hosted site builders for each.
Should you change platform for speed?
Rarely, and not on this evidence alone. A platform change is a large project with risks to your orders and your search visibility. These are medians across many stores, and they say little about one store with careful work. First work through the plan below. Consider a move when the numbers stay poor after you have fixed what you control, and when other needs, such as features or costs, point the same way.
The five kinds of page
1. Category and collection pages
These pages show many products at once, so they are made of images. What decides their speed is the number of products shown, the size and format of the thumbnails, how many scripts the filters and sorting add, and whether the page is cached.
What to do:
- Show a sensible number of products per page. Shopify's own theme checker has a rule on page size, with the stated aim of keeping response times low.
- Make sure the thumbnails are sized for their slots. Shopify's reference theme lists several widths for each product card and a matching
sizesvalue. See srcset and sizes. - Lazy-load the thumbnails below the first screen, but not the first row.
- Keep filter and sort scripts small, and load them when needed.
2. Product pages
The main product image is often the Largest Contentful Paint element. The gallery tools, reviews, recommendations and variant pickers add weight around it.
What to do:
- Do not lazy-load the main image, and give it high priority. See how to fix a slow LCP.
- Check the gallery. On a WooCommerce classic theme, the zoom, slider and lightbox are separate scripts, loaded when the theme supports them.
- Load review and recommendation widgets late, since they sit below the main image.
- Keep videos from loading until a shopper presses play.
3. The cart
The cart is personal, so it depends on the server, plus the scripts for the mini-cart or cart drawer.
What to do: keep small any script for a mini-cart or cart drawer, since it can load on every page. Test adding to the cart on a phone, because that tap is where interaction speed shows.
4. The checkout
The checkout depends on the server, the number of fields, the payment tools and the recalculation of totals.
What to do: see WooCommerce checkout speed for how the classic checkout works and how to test it. The 2025 Almanac calls payments a major dependency surface, because of third-party scripts, redirects and fraud tools. Offer the payment methods that your customers use, and test every change with a real purchase.
5. Search
Predictive search and filters run scripts as the shopper types.
What to do: make sure the search script loads without blocking the page, and that results come from a fast query. Shopify's reference theme, for example, loads its predictive search script with defer.
Where the time goes on a typical store
Across all five, the same four causes come up:
- Hosting and caching. The pages that can be cached must be, and the ones that cannot must be built quickly. See WordPress hosting and WordPress caching for WordPress stores.
- Images. Product photos are most of the weight. Right-sized, well-compressed, correctly prioritized images are the largest single gain on most stores.
- Scripts from other companies. Reviews, chat, pop-ups, loyalty tools, tracking pixels and payment tools. See third-party scripts.
- Plugins, apps and theme features. Each adds something to every page. Remove what you do not use.
How to measure a store
- Test every kind of page, not only the home page: a category, a product, the cart and the checkout, with a phone profile.
- Test with a cart. Online testers start with an empty basket, and WooCommerce, for one, sends an empty-cart visit to the checkout back to the cart page. In Chrome's own Lighthouse panel you can test the real thing. See the checkout guide.
- Use real-visitor data for the pages with the most traffic. See the Chrome UX Report.
- Keep a record. Write down the results before and after each change.
- Plan for busy days. A sale brings more visitors at once, and uncached pages put the most load on the server. Ask your host how it copes, before the sale starts.
A priority order
If you do not know where to start, this order tends to pay off, and the reasoning is in the guides linked above:
- Make sure the cache works for the pages that can be cached, and that the cart and checkout are excluded.
- Fix the main image on product pages and the thumbnails on category pages.
- Review the scripts from other companies, and remove or delay the ones you can.
- Review plugins or apps.
- Trim the checkout and test it with a real purchase.
- Re-measure, and repeat for the page type that is still weakest.
Questions for your developer or agency
- Which pages are cached, and which are not? How do you know?
- What is the host's response time for an uncached page, and for a cached one?
- Which scripts from other companies load on the product and checkout pages, and who reads their reports?
- How big are the product images, and how are they sized for phones?
- How do we test the checkout after each change?
- What happens to the site on a sale day?
Mistakes to avoid
- Testing only the home page. The money is made on the product and checkout pages.
- Caching personal pages. It exposes one customer's data to another.
- Adding apps for small features. Check what the theme already does.
- Changing platform for speed alone. Do the work you control first.
- Skipping the test purchase. A fast checkout that cannot take payment is no use.
Check your own page
Run the free audit on a category page and on a product page. Open LCP request discovery, Improve image delivery, 3rd parties and Reduce unused JavaScript. Fix the largest problem on the weaker of the two, then repeat.
Sources
- Ecommerce chapter, Web Almanac 2025: platform types, pass rates by platform, the argument about delays compounding, and payments.
- Dawn and Theme Check, Shopify's reference theme and its checker: product card images, predictive search loading and the pagination rule.
- WooCommerce source code: the cache rules for the cart, checkout and account pages, and the gallery scripts.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Speed optimization · Book a call