Fixing Slow Product Pages
Product pages are usually the heaviest pages in a shop. They carry a large image gallery, zoom, reviews, recommendations, delivery estimates, pay-later messages, chat and tracking, and each extra app adds code that every shopper downloads.
The result is a main image that appears late, a price that jumps when a banner arrives, and a size picker that hesitates when tapped. This guide shows how to find what is slowing your product template, then fix the gallery, app scripts, late-loading widgets and the variant and basket interactions, so the fix applies to every product at once.
Why product pages are slower than the rest of the shop
The home page and category pages are mostly images and links. A product page is where every app wants a place, because it is where people decide to buy. A typical product template may load:
- A gallery with several full-size images, thumbnails, a zoom library and sometimes a 360-degree viewer or video.
- A review widget with its own stylesheet, fonts and star icons.
- "You may also like" and "frequently bought together" blocks, often built by a separate recommendation service.
- Pay-later messaging, delivery date estimates, stock counters and countdown timers.
- Live chat, a pop-up for email sign-ups, and several tracking and advertising tags.
- Variant logic that swaps images, prices and stock when a size or colour is chosen.
None of these is wrong on its own. The trouble is that each was added at a different time, often by a different person, and nobody ever looked at the total. Because every product shares the same template, one heavy app slows the whole catalogue.
What each Core Web Vital means on a product page
Google's Core Web Vitals are judged at the 75th percentile of real visits, from Chrome users, over the previous 28 days. On a product page each one maps to something a shopper feels.
| Metric | Good | On a product page it is usually | Common cause of a poor score |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 s or less | The main product image | Image lazy-loaded, built by a gallery script, or far too large |
| Interaction to Next Paint (INP) | 200 ms or less | Choosing a size or colour, opening the gallery, pressing add to basket | Long scripts running on the main thread when the shopper taps |
| Cumulative Layout Shift (CLS) | 0.1 or less | The price, buttons and description jumping down | Banners, star ratings and pay-later messages inserted after load |
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. Unlike its predecessor, it looks at the responsiveness of interactions throughout the visit, which is why product pages with heavy variant logic often pass on older reports and fail now.
Finding what slows your product template
Start with field data
Run a best-selling product URL through PageSpeed Insights. The top section, from real Chrome users, shows whether that URL or its group actually fails; the lab section below is a single simulated load that is useful for finding causes but is not what Google assesses. If the product URL has too little traffic for its own data, PageSpeed Insights shows the origin as a whole.
Identify the LCP element
In PageSpeed Insights, open the diagnostic for the Largest Contentful Paint element. On most product
pages it is the first gallery image. Note its file size, its dimensions and whether it has loading="lazy".
In Chrome developer tools, the Performance panel shows the LCP phases: time to first byte, how long before
the image request started, how long it took to download, and how long before it was painted. A long delay
before the request starts almost always means the image was discovered late, typically because a script
builds the gallery.
List every third party
Open the Network panel, reload, and sort by domain. Group the requests by the service they belong to, and add up the transfer size and script time for each. The Performance panel's third-party summary helps here. Keep this list; it becomes the basis for the app audit in the fix below.
Test the interactions
With the Performance panel recording, select a different size, click a thumbnail and press add to basket. Long tasks, shown with red corners, that follow each tap tell you which scripts delay the response. Chrome's Performance panel also shows INP for interactions you perform on the page, which is a quick way to compare before and after.
The gallery: the biggest single cause
The main image is the LCP element on most product pages, so how the gallery loads decides most of your LCP score.
<!-- First image: in the HTML, not lazy, high priority, responsive -->
<img src="/images/walking-boot-800.jpg"
srcset="/images/walking-boot-400.jpg 400w,
/images/walking-boot-800.jpg 800w,
/images/walking-boot-1200.jpg 1200w"
sizes="(min-width: 990px) 50vw, 100vw"
width="1200" height="1200"
fetchpriority="high"
alt="Brown leather walking boot, side view">
<!-- Other gallery images: lazy, loaded when needed -->
<img src="/images/walking-boot-sole-800.jpg" loading="lazy"
width="1200" height="1200" alt="Walking boot tread pattern">- Put the first image in the HTML. If a slider library builds the gallery from a data list after its script runs, the browser cannot start downloading the main image until then. Render the first slide as a normal image and let the library enhance it.
- Never lazy-load the first image. Many themes apply
loading="lazy"to every gallery image. It is right for the rest, wrong for the first. - Serve the right size. A 3000-pixel supplier photo shown in a 600-pixel column wastes
the shopper's data. Use
srcsetandsizes, or your platform's image service, and modern formats such as WebP or AVIF where supported. - Load zoom on demand. The high-resolution zoom image and the zoom library are only needed when someone hovers or taps to zoom. Fetch them then.
- Treat video and 360 viewers the same way. Show a poster image and load the player when the shopper chooses to play.
Image formats, alt text and file naming are covered in Fixing product image SEO; this guide is only about how the gallery affects speed.
App scripts: what to keep, delay or remove
Uninstalling an app does not always remove its code. On Shopify, older apps inserted snippets directly into theme files that stay behind after removal, while newer apps use app embeds that can be switched off in the theme editor. On WordPress, a deactivated plugin stops loading, but tag manager containers can keep loading third-party tags that nobody remembers adding.
| Type of script | Usual verdict | How |
|---|---|---|
| Review widget | Keep, but load the full list lazily | Print the rating summary on the server; load the widget when the reviews section nears the viewport |
| Recommendations | Keep if they sell, load late | Load after the main content, below the fold, with space reserved |
| Live chat | Delay | Show a lightweight button; load the chat script only when clicked |
| Email pop-up | Question it | If kept, load after a delay or on exit intent, never during the first seconds |
| A/B testing with an anti-flicker snippet | Review carefully | Anti-flicker snippets hide the page until the test script loads, which delays everything the shopper sees |
| Tags for ads and analytics | Keep what you use | Remove tags for campaigns and tools you no longer run; check the tag manager for duplicates |
| Countdown timers, "X people viewing" counters | Often remove | They add script and layout shift, and fake urgency is a consumer protection risk |
The fix, step by step
Step 1
Measure the product template, not one page
Pick three product pages that share your main template, ideally a best seller, a product with many variants and one with many reviews. Run each through PageSpeed Insights and note the field data for LCP, INP and CLS, the LCP element, and the heaviest third-party domains. Check the product URL groups in Search Console's Core Web Vitals report. Because every product uses the same template, you are diagnosing the template, and a fix there reaches every product at once.
Step 2
Make the main product image load first
Change the template so the first gallery image is a normal <img> in the
server HTML, without loading="lazy", with fetchpriority="high", width and height
attributes, and a srcset offering sensible sizes. If a slider script builds the gallery,
render the first slide yourself and let the script take over afterwards. Then re-test and confirm in
the Performance panel that the image request starts early instead of waiting for scripts.
Step 3
Trim the gallery and zoom code
Make every gallery image after the first lazy-loaded, and serve thumbnails as genuinely small files rather than scaled-down full images. Load the zoom library and high-resolution zoom image only when a shopper hovers or taps to zoom, and replace any embedded video or 360-degree viewer with a poster image that loads the player on click. If the gallery library is large and you use only a fraction of it, consider a lighter one or your theme's native gallery.
Step 4
Audit and remove app scripts
Take the list of third-party domains from the Network panel and match each one to an app, plugin or tag. For each, decide whether to keep it, delay it until interaction, or remove it. Uninstall apps you no longer use and then search the theme files for their leftover snippets, and clear old tags out of your tag manager. Make changes one at a time, checking that sales tracking and key features still work after each.
Step 5
Reserve space for late widgets
Watch
the page load in slow motion using the Performance panel's screenshots and note everything that pushes
content down: star ratings under the title, pay-later messages under the price, delivery estimates, stock
badges and promotion banners. Give each container a fixed min-height in CSS matching its
final size, or render its content on the server, so the price and add to basket button stay put while
scripts arrive.
Step 6
Make variant and basket taps respond quickly
Record a Performance trace while choosing a size and pressing add to basket. If long tasks
follow the tap, update the visible selection straight away and move slower work, such as recalculating
recommendations or sending tracking events, to after the next paint, for example with setTimeout
or requestIdleCallback. Avoid rebuilding the whole gallery or product form on every variant
change, and make sure several apps are not all listening to the same click.
Step 7
Set a budget and recheck after changes
Write down simple limits for the product template: the maximum size of the first image, the number of third-party domains allowed and the total script weight. Check these before installing any new app, and after theme updates or seasonal campaigns. Rerun the Ecommerce Audit and PageSpeed Insights on the same three products, and watch the Search Console groups, remembering the field data covers 28 days so improvements appear gradually.
Platform notes
Shopify
Use the theme's image filters to request sized images rather than the original upload, and check Online Store, Themes, Customise, App embeds for apps that can be switched off without uninstalling. After removing apps, search the theme code for their names to find leftover snippets. The platform's own CDN serves images well; the usual problems are theme code and apps, not hosting.
WooCommerce
Server response time matters more here because the page is built by your own hosting. Page caching cannot cover the basket and checkout, but product pages can usually be cached for guests. Check that the gallery's zoom, lightbox and slider scripts are only loaded on product pages, and that plugins are not each loading their own copies of the same libraries.
Headless and custom
Render the product and first image on the server or at build time, not in the browser after an API call. Watch the size of the JavaScript sent to hydrate the page; a product page that ships a full application bundle can load fast and still respond slowly to taps.
For wider speed work across the site, see Fixing LCP, Fixing INP and the Core Web Vitals fixes.
1. Why is my product page slower than my home page?
Product pages usually carry far more apps than any other page: galleries with zoom, review widgets, recommendation blocks, pay-later messaging, delivery estimates, chat and tracking. Each adds scripts, styles and requests, and many load on every product regardless of whether the shopper uses them. The home page is often mostly images and links. Because all products share one template, the extra weight is repeated across your whole catalogue, which is why the product group often fails when other pages pass.
2. Should I preload the main product image?
Usually the better fix is to make the first image a normal image in the server HTML with fetchpriority set to high and no lazy loading, so the browser finds it straight away. A preload link helps mainly when the image cannot be in the HTML, such as a background image or one inserted by a script. Preloading the wrong image size, or several images, wastes bandwidth and can slow the page, so test the effect before and after.
3. Will removing apps hurt my sales?
Some apps earn their place, and removing them could cost sales. Others are left over from trials, duplicate a feature the theme already has, or add little. Look at what each app actually contributes, using its own reports or your analytics, before deciding. Remove one app at a time and compare conversion over a few weeks. Often the best option is not removal but loading the app later, when the shopper scrolls to it or clicks it.
4. Why does my product page fail INP when it feels fast?
INP measures how quickly the page responds to taps and clicks throughout a visit, based on real shoppers at the 75th percentile, many of whom use mid-range phones that are much slower than a developer laptop. Choosing a size, switching colour or pressing add to basket can trigger scripts from several apps at once. On a fast computer that feels instant; on a busy budget phone the same work can delay the next frame noticeably.
5. Do pay-later and delivery estimate widgets cause layout shift?
They often do, because they are inserted beside the price or the add to basket button after the page has already been drawn, pushing everything below them down. That movement counts towards Cumulative Layout Shift and can cause mis-taps. The fix is to reserve their space in advance with a fixed minimum height in your CSS, or to render the message on the server, so the price and buttons stay exactly where they first appeared while the widget loads.
6. How long before Search Console shows the improvement?
Core Web Vitals in Search Console are based on real Chrome visits over the previous 28 days, so a fix appears gradually as new visits replace old ones. Expect it to take up to about a month for a group to change status, longer for products with little traffic. PageSpeed Insights field data follows the same window. You can confirm the fix immediately with lab tests and the Performance panel, then wait for the field data to follow.
7. Does product page speed affect rankings much?
Page experience is one of many signals and good content that matches the search usually matters more, so speed alone rarely moves a product from page three to page one. The stronger reason to fix it is shoppers. A main image that arrives late, a price that jumps or a size picker that stalls loses trust at the moment someone is deciding to buy. Faster product pages help customers first, and search performance tends to benefit alongside.
The Ecommerce Audit checks product page speed across your top store pages, alongside product page completeness, category depth, Product and review schema, faceted navigation, product images and internal links.
Open Ecommerce Audit Fixes →