Short answer
We focus on the templates that matter for sales: home, category or collection, product, cart and checkout. The work covers product image delivery, the scripts that apps and plugins add, filter and search performance, and caching that never touches personal pages such as the cart.
Why stores need their own approach
A store's slowest pages are often its most valuable ones. Product pages carry galleries, variants, reviews and recommendations. Category pages carry dozens of images and filters. Many store features arrive as apps or plugins, each adding its own scripts. And some pages, such as the cart and checkout, must never be cached for everyone. Speed work on a store has to respect all of that.
Shopify stores
Shopify controls the server and CDN, so the work concentrates on the theme and apps. Shopify's theme documentation sets the aim as "load only what's needed, only when it's needed" [1]. It recommends deferring non-critical scripts, auditing every script including apps and tracking pixels, and removing any that are not "earning their performance cost" [1]. It also warns that "badly written first-party code is just as damaging as a poorly implemented third-party script" [1], so we review the theme code as well as the apps.
On images, Shopify's guidance is to eagerly load images in the initial viewport, especially the LCP candidate, and apply lazy loading only further down [1]. Collection pages are a common place where this goes wrong.
WooCommerce stores
WooCommerce runs on your own hosting, so server response and caching matter more. WooCommerce's developer documentation recommends page, browser and object caching, while making sure dynamic content "such as cart and checkout pages" remains uncached [2]. It suggests evaluating plugins with profiling tools and to "remove or replace those that negatively affect your store's performance" [2], and it covers image formats, compression, lazy loading and right-sized images [2]. We follow that guidance and add a WordPress-level review of the theme and plugins.
Custom stores
For custom platforms we look at server response, how product data is fetched, how much JavaScript the storefront ships, and whether search and filters do heavy work on the main thread after each tap.
What we work on
| Template | Possible causes | Fixes to consider |
|---|---|---|
| Home | Large hero sliders, autoplay video, many app scripts | One prioritized hero image, delayed widgets, fewer scripts |
| Collection or category | Many full-size images, heavy filters | Responsive thumbnails, lazy loading below the fold, lighter filter code |
| Product | Large galleries, review and upsell apps, variant scripts | Gallery images sized per screen, apps loaded after the main content |
| Cart and checkout | Scripts carried over from other pages | Only what the purchase needs, with no shared caching |
Protecting sales and tracking
Every change is tested on a staging or preview copy, including add to cart, discount codes, checkout steps and the tracking that marketing relies on. We agree with you which events must keep firing, then confirm they do after each release. If an app is slowing the store but is important to the business, we look for ways to load it later rather than removing it.
What you receive
- Measurements for each key template before and after, with dates.
- An app or plugin table showing what each one adds and what changed.
- Image guidance for whoever uploads products, so new listings stay light.
Product images at scale
A store may have thousands of product photos uploaded over years by different people, at very different sizes. Fixing them one by one is not realistic. The work is usually about the system: making sure the platform or a CDN generates sizes and modern formats automatically, that the theme requests the right size for each slot, that the first product image on each page is prioritized and the rest wait until needed [1], and that new uploads follow simple rules. WooCommerce's guidance gives the same priorities: suitable formats, compression, lazy loading and right-sized images per device [2].
Filters, search and responsiveness
Category filters and on-site search are often where stores fail Interaction to Next Paint. Each tap can trigger sorting, re-rendering a large grid and several app scripts reacting to the change. The fixes come from web.dev's guidance on INP: show feedback immediately, break the work into smaller tasks, yield to the main thread, and avoid re-rendering more than needed [3]. We test these interactions on throttled mobile settings, because that is where they are slowest.
Seasonal timing
Many stores have busy seasons when changes feel risky. We plan around them: audits and lower-risk changes can happen at any time, while larger theme or app changes are scheduled for quieter weeks with time to test and monitor before peak traffic. If a deadline matters, tell us early and we will plan the work backwards from it.
What we need from you
Collaborator or staff access to the store, a list of apps and the features they provide, the conversion events your marketing team relies on, and access to a preview or staging theme if the platform supports it.
Checkout and payment pages
Checkout pages deserve their own attention because every delay there costs completed orders. They should carry only the scripts the purchase needs. Marketing tools, chat widgets and review apps that run on product pages often follow visitors into checkout without any reason to. On platforms where the checkout is managed by the provider, the scope for changes is limited, so the work focuses on the cart page and the steps before checkout. Wherever we work, carts and checkouts stay out of shared caches, as WooCommerce's guidance requires for dynamic content [2], and every change is tested with real test orders before release.
Questions about store speed work
Will you remove my apps?
Only with your agreement. Often an app can stay and simply load later or only on the pages that use it.
Does Shopify limit what you can change?
Shopify manages the server and CDN, so the work is in the theme, apps and media. That is usually where the biggest gains are anyway.
Can speed work affect conversion tracking?
It can if scripts are removed carelessly. We list the events you rely on and test them after each change.
Sources
Opened and checked on November 3, 2026.
- Performance best practices for Shopify themes, Shopify developer documentation. Primary platform documentation, checked November 3, 2026.
- How to optimize performance for WooCommerce stores, WooCommerce developer docs. Primary platform documentation, checked November 3, 2026.
- Optimize Interaction to Next Paint, web.dev. Primary documentation, last updated September 2, 2025.