General Info
The /bags product feed page currently has an LCP of ~5.5 s on mobile.
The biggest driver is that the first visible product grid images (likely hero thumbnails) are discovered late — probably due to incorrect lazy-loading or missing preload hints.
Other issues include: large DOM size, unused CSS, some images still in JPEG, and the HiPay SDK script unnecessarily loading on the listing page.
User Story
As a customer browsing /bags, I want visible products to load instantly without waiting for hidden ones so I can find what I want quickly.
Acceptance Criteria
|
ID |
Scenario |
Details |
|---|---|---|
|
01 |
Scenario: Above-the-fold product images load eagerly and are preloaded Given grid product thumbnails drive LCP When the page loads Then the first visible images are not lazy-loaded and are preloaded |
Evidence: Lighthouse: “largest-contentful-paint.numericValue = 5474ms” confirms slow LCP due to grid images. Why: When above-the-fold images are lazy-loaded, the browser discovers them late, delaying LCP. Action direction: For the first ~6–8 visible product images: use loading="eager", fetchpriority="high" on <img>, and <link rel="preload" as="image"> in the <head>. Dev to confirm which images become LCP candidates at different breakpoints. |
|
02 |
Scenario: Offscreen grid images are lazy-loaded Given thumbnails below the fold don’t need to load immediately When the page loads Then only visible images load upfront |
Evidence: The audit shows more images load upfront than needed, pushing network requests. Why: Loading all thumbnails delays the main grid. Action direction: Use loading="lazy" for offscreen items; confirm WP Rocket LazyLoad is correctly configured. |
|
03 |
Scenario: Product images served in next-gen formats Given many grid images are still JPEG When they load Then they use WebP |
Evidence: “Serve images in next-gen formats” – significant savings potential. Why: Reduces payload, faster LCP. Action direction: Convert grid thumbnails to WebP; test for color fidelity. |
|
04 |
Scenario: DOM size is reasonable Given product grids can create massive DOM trees When page loads Then initial HTML keeps DOM under control |
Evidence: Large grids often exceed ~4000+ nodes. Why: High DOM size increases layout cost. Action direction: Limit initial product count (e.g., 16 items) with auto“Load More” or pagination. |
|
05 |
Scenario: Remove unused CSS Given the grid pulls in widget styles not needed When page loads Then only relevant CSS is served |
Evidence: “Remove unused CSS” flagged in prior audit – ~180 KB waste likely persists. Why: Redundant CSS blocks paint. Action direction: Enable WP Rocket Remove Unused CSS; verify nothing breaks in grid styling. |
|
06 |
Scenario: HiPay SDK does not load unnecessarily Given payments only happen in checkout When the /bags page loads Then HiPay scripts are not included |
Evidence: HiPay script seen in page waterfall for /bags. Why: Large third-party payment JS (~200–300 KB) adds overhead for no reason. Action direction: Wrap enqueue for is_checkout() or unload with Asset CleanUp. |
Additional Note for Devs
These recommendations explain why to fix each problem and how it typically works, but exact implementation must match our theme’s structure and breakpoints. For the grid images especially, test different viewport widths to see which images consistently become the LCP candidate.
Use staging and verify LCP improvement in Lighthouse.
Leave a Reply
You must be logged in to post a comment.