WoodMart LCP optimization for product and category pages

Common culprits: a hero or slider that ships a huge, unoptimized image; the LCP image lazy-loaded when it shouldn't be; render-blocking theme CSS in the critical path; and a web font the heading waits on. On product pages the gallery is frequently the LCP element and often the heaviest asset on the page.

LCP improves when the main image can start downloading immediately and nothing blocks it:

• Serve the hero/gallery image as a properly sized AVIF/WebP with priority loading
• Never lazy-load the LCP image; preload it instead
• Inline critical CSS and defer the rest of the theme bundle
• Preconnect to the image host and preload the display font

If your LCP is close to target and driven by one big image or a render-blocking script, those are in-place fixes — no rebuild needed. The free audit identifies your actual LCP element per template and whether tuning gets you into the green.

The structural problem is that a theme renders in the browser after loading a large shared bundle. A Next.js storefront pre-renders the HTML and streams the LCP image first, so the main content paints early by design rather than after the theme boots.

Two WoodMart patterns delay LCP more than any single image setting. On demo-based homepages and category pages the hero is often a slider that boots in JavaScript and only paints its first slide after the script runs, so the largest element is late by design. On product pages the main gallery image is wrapped in WoodMart's zoom and lightbox scripts, which can hold back the very image that is the LCP. The most effective fix is frequently to replace the slider hero with a static, server-rendered banner and to let the gallery's first image load as a plain, prioritized image before the zoom behaviour attaches.

Even the right image loads late if the browser discovers it late or downloads the wrong size. Three signals matter: serve the LCP image as a real <img> with fetchpriority="high" rather than a CSS background the browser finds late; provide a responsive srcset sized to the slot so a phone does not download a 2000px file for a 400px space; and preload it so the request starts before the theme's CSS and scripts. Together these are usually worth more than another caching pass, because they attack when the image is discovered, not just how fast it travels.

• Use a real <img> with fetchpriority="high" for the LCP element
• Serve a responsive srcset sized to the actual rendered dimensions
• Preload the LCP image so its request starts early
• Avoid CSS-background heroes that the browser discovers late

Once the LCP image loads early, the last gains come from sending the smallest correct file. Serve modern formats — AVIF with a WebP fallback — which cut bytes substantially at the same visual quality. Provide a responsive srcset with a sizes attribute so a phone downloads an image sized to its slot rather than the desktop original, and never upscale a small source to fill a large space. Pick breakpoints that match your real layout instead of arbitrary widths. Combined with priority loading, this typically turns the heaviest asset on the page into one that arrives in a fraction of the time.

• Serve AVIF with a WebP fallback
• Use srcset + sizes so phones get a slot-sized image
• Never upscale a small source to a large display size
• Choose breakpoints from your real layout

We rebuild product and category templates so the LCP element loads first with the right format and priority, verify LCP in the field on staging per template, and switch only when it holds. WooCommerce keeps serving the product, price and image data through the API.