Know How to Fix 6 Speed Killers On Your Storefront.
The product page is where buying decisions happen, so every second here costs money. A shopper who lands on a slow product detail page (PDP) from an ad or a Google search doesn’t wait around to admire your gallery. They leave.
A quick note on terms before we start:
- LCP (Largest Contentful Paint): how long until the biggest visible element, usually your main product image, appears. Aim for 2.5 seconds or less.
- INP (Interaction to Next Paint): how quickly the page responds when someone taps or clicks. Aim for 200ms or less.
- CLS (Cumulative Layout Shift): how much the page jumps around while loading. Aim for 0.1 or less.
1. Render-blocking CSS and JavaScript
Your browser wants to show the page, but first it has to download and process a pile of CSS and JavaScript. WooCommerce stores get messy quickly:
- Elementor or another page builder
- WooCommerce’s own styles and scripts
- Analytics and tracking scripts
- Review plugins
- Popups
- Chat widgets
Suddenly dozens of files load before the customer sees the actual product.
How to find the problem
Run the PDP through PageSpeed Insights or Lighthouse and look for “Eliminate render-blocking resources.” Then ask your developer a direct question:
“Which CSS and JS files are render-blocking on our PDP, and which of them are needed for the first screen?”
In Chrome DevTools, the Coverage tab (Ctrl/Cmd + Shift + P, then “Show Coverage”) shows how much of each file is actually used on the page. It’s common to find that most of a plugin’s CSS and JS is unused on product pages.
How to fix it
- Defer or delay JavaScript that isn’t needed for the initial view. Chat widgets, popups and analytics rarely need to run before the product is visible.
- Load plugin assets only where needed. A contact form plugin doesn’t need to load its scripts on every product page. Tools like Perfmatters or Asset CleanUp let you disable assets per page or per template.
- Inline critical CSS for above-the-fold content and load the rest asynchronously. Performance plugins such as WP Rocket, FlyingPress and LiteSpeed Cache can generate this for you.
- Minify and combine carefully. Combining files helps less than it used to on HTTP/2 and HTTP/3, and it can break things. Test before you keep it.
Don’t remove everything. Cutting the wrong script can break your variation selector or Add to Cart button. Work on a staging site, change one thing at a time, and test the full purchase flow after each change.
2. Your LCP image isn’t being prioritised
Picture the experience: a customer opens the product page. The header loads. The text loads. The buttons load. But the main product image appears two or three seconds later.
That image is usually the most important element on the page, and on most PDPs it is the LCP element. So the browser needs to know it’s important.
How to fix it
- Never lazy-load the LCP image. Lazy loading is great for images below the fold, but it tells the browser to wait, which is the opposite of what you want for your hero product shot. Some stores end up with the biggest visual on the page effectively being told: “Wait.”
- Add
fetchpriority="high"to the main product image so the browser fetches it early. - Preload it where appropriate, especially if the image is discovered late (for example, injected by a gallery script or slider).
- Check your gallery or slider plugin. Some load the first image through JavaScript, which delays discovery. Where possible, make sure the first image is in the initial HTML.
Recent WordPress versions handle some of this automatically for the first large image, but WooCommerce galleries, themes and optimisation plugins can override it. Inspect the rendered HTML on your live PDP rather than assuming.
A simple check: right-click the main product image, choose Inspect, and look for loading="lazy". If it’s there, you’ve found a quick win.
3. Massive product images
This one sounds obvious, yet it’s still everywhere. Common patterns include:
- 1MB+ product images
- Huge PNGs where a JPEG or WebP would do
- 4000px images displayed at 800px
- Uncompressed product galleries
One heavy image isn’t a disaster. Twenty of them are.
How to fix it
- Use modern formats. WebP is widely supported and AVIF can be even smaller. Use them where appropriate, with fallbacks handled by your plugin or CDN.
- Compress on upload. Plugins like ShortPixel, Imagify or EWWW can compress and convert automatically, or you can do it through an image CDN.
- Serve sensible sizes. A customer viewing a product at 800px doesn’t need a 4000px file. Make sure WooCommerce’s image sizes (Appearance > Customize > WooCommerce > Product Images) match your theme layout, and regenerate thumbnails after changing them.
- Use responsive images (
srcset) so mobile phones get smaller files than desktops. WordPress does this by default for images it manages, so watch for themes or builders that bypass it. - Set width and height attributes so the browser reserves space and the layout doesn’t jump (this helps CLS too).
As a rough target, aim to keep gallery images well under 200KB each without visible quality loss. Your own products and audience will decide how far you can push it.
4. Loading every product video immediately
Videos are big. Some WooCommerce stores load multiple product videos the moment the page opens, even though the customer may never scroll down to them. An embedded YouTube player alone can pull in a surprising amount of JavaScript.
How to fix it
- Show a poster image or thumbnail first. Only load the actual video when the customer clicks it, or when it’s about to enter the viewport.
- Use a facade for YouTube and Vimeo. A facade is a lightweight placeholder that loads the real player only on interaction. Many performance plugins offer this as a setting.
- Don’t autoplay videos on mobile unless you truly need to.
- Host and compress videos properly if they’re self-hosted, and avoid using video files as decorative backgrounds on product pages.
Don’t make a customer on a mobile network download videos they may never watch.
5. Plugins loading critical product data
This is a big one with WooCommerce. The problem isn’t necessarily the number of plugins. It’s what those plugins make the customer wait for.
Common culprits include:
- Reviews
- Subscriptions
- Wishlists
- Product bundles
- Personalisation and custom fields
- Recommendations
- Stock and inventory systems
- Shipping calculators
You might see this: the page loads, but the variation selector appears two seconds later. Or the price updates after another request. Or the Add to Cart button isn’t usable right away. That means the customer is waiting for JavaScript, API calls or plugin logic before they can actually use the product page.
How to find the problem
Open DevTools and go to the Network tab. Reload the PDP and filter by Fetch/XHR. You’ll often find requests firing that don’t need to happen immediately, especially from third-party services.
Also check the Performance tab and look for long tasks (over 50ms) that block the main thread. These are what make taps on variation swatches feel laggy, which shows up as poor INP.
How to fix it
- Load essentials first. Price, variation selector and Add to Cart should work immediately. Everything else can load afterwards.
- Defer secondary features. Wishlists, recommendation widgets and review carousels can wait until after the main experience is ready.
- Audit your plugin list. Ask what each plugin does on the PDP and whether it needs to run there at all. Remove or replace the ones that cost more than they earn.
- Watch the cart fragments request. WooCommerce’s
wc-cart-fragmentsscript can fire an AJAX request on page load to update the mini-cart. If you don’t need a live mini-cart on the PDP, disabling it there can cut a request. Test your cart and checkout thoroughly after any change like this. - Check your server, not just the front end. Product pages with many variations can be expensive to generate. Slow hosting, no full-page caching and no object cache (Redis or Memcached) will undo your front-end work, because everything waits on the first response (TTFB).
6. Loading everything below the fold
This is one of the biggest opportunities on most product pages. A WooCommerce PDP might load all of this before the customer has even scrolled:
- 20 product images
- Related products
- Recently viewed products
- Reviews
- Instagram feeds
- Recommendation widgets
- Footer content
- Chat widgets
- YouTube embeds
Why? The customer can’t see any of it yet. Your PDP doesn’t need to build the entire website in the first two seconds.
How to fix it
- Lazy-load anything below the fold, including images, iframes and embedded widgets.
- Delay non-critical third-party scripts until the user interacts (scroll, click or tap) or until the browser is idle. This works especially well for chat widgets and social feeds.
- Load sections as they approach the viewport. Reviews, related products and feeds can load just before the customer scrolls to them.
- Reserve space for these sections so they don’t cause layout shift when they appear.
- Clean up your tag manager. Old marketing pixels and abandoned tests pile up in Google Tag Manager. Removing dead tags often beats optimising live ones.
Just remember the rule from #2: lazy-load below the fold, never the hero image.
Bonus: small things that add up
A few more items worth a look once the big six are handled:
- Fonts: Limit the number of weights, self-host where possible, preload your primary font, and use
font-display: swapso text appears immediately. - Layout shift: Images without dimensions, late-loading review widgets and sticky bars or popups make the page jump. Reserve space for anything that loads late.
- Database and plugin bloat: Excess autoloaded options, leftover transients and unused plugins slow down page generation.
- Caching and CDN: Full-page caching for anonymous visitors plus a CDN can dramatically improve response times, especially for customers far from your server.
Don’t optimise only for desktop
Here’s a common trap. A WooCommerce PDP that feels fast on a MacBook with Wi-Fi can feel completely different on a mid-range Android phone on a mobile network. This matters even more for Indian customers, where a large share of shoppers browse on budget devices and variable connections.
Test the experience your actual customers are getting:
- Use Chrome DevTools throttling (mid-tier mobile, slow 4G) as a starting point.
- Run PageSpeed Insights and look at the field data (CrUX) section, which reflects real users.
- Check the Core Web Vitals report in Google Search Console to see which URLs are failing in the real world.
- Use WebPageTest with a mobile device profile and a location close to your customers.
- Test on an actual mid-range phone if you can.
Because these two statements are very different:
“My PageSpeed score is 90.”
“My customers can see and use the product quickly.”
A high lab score is nice. Fast, usable pages for real customers are what sell products.
A quick PDP speed checklist
- Identify and defer render-blocking CSS and JS
- Unload plugin assets that aren’t needed on product pages
- Main product image is not lazy-loaded and has high fetch priority
- Images are compressed, correctly sized and in WebP/AVIF
- Videos use posters or facades and load on demand
- Price, variations and Add to Cart work immediately
- Third-party requests on the PDP are audited
- Below-the-fold sections and widgets are lazy-loaded
- TTFB is healthy, with full-page caching and object cache in place
- Tested on a mid-range phone and a throttled connection
Final thoughts
Speed work on WooCommerce is rarely one big fix. It’s a series of small ones that add up to a page customers can use quickly. Start with render-blocking assets, the LCP image and below-the-fold loading, then work through the rest.
Leave a Reply