Clothing sites are built for browsing. A shopper lands on a campaign home page and opens a category of several dozen products. They filter by size, open three or four items, go back to the grid and filter again. Speed problems are spread across that whole loop. Fixing the product page alone leaves much of the browsing untouched.
This guide sets out how Google measures each part of that loop, and where a fashion site tends to give time away. It keeps the photography and the filtering that clothing buyers rely on.
How Google scores each page in the loop
Google’s Core Web Vitals come from real Chrome visits. Each is judged at the 75th percentile, separately for mobile and desktop, so roughly three visits in four must reach “good”.
| Metric | Good | Poor | Typical source on a clothing site |
|---|---|---|---|
| Largest Contentful Paint (loading) | 2.5 s or less | over 4 s | The campaign image or video poster, or the first row of a product grid |
| Interaction to Next Paint (response) | 200 ms or less | over 500 ms | Filter and sort taps, quick view, size buttons |
| Cumulative Layout Shift (stability) | 0.1 or less | over 0.25 | Brand fonts, promo bars, recommendation rails |
The real-visit figures are what PageSpeed Insights shows at the top and what Search Console reports. Lab tools like Lighthouse simulate a single load. They help find causes but cannot measure INP, so Lighthouse shows Total Blocking Time instead.
For context, the 2024 Web Almanac found that 43% of websites passed all three metrics on mobile and 54% on desktop. Those are all-web figures from mid-2024, not a fashion benchmark.
What I measured on UK fashion product pages (October 2026)
I ran five UK clothing product pages through PageSpeed Insights on 23 October 2026. Each was tested once, using its mobile test of an emulated mid-range phone on a slow 4G connection.
| Page | Performance score | Lab LCP | Total Blocking Time | Lab CLS |
|---|---|---|---|---|
| Retailer A | 32 | 5.6 s | 1,960 ms | 0.103 |
| Retailer B | 14 | 11.5 s | 1,510 ms | 0.354 |
| Retailer C | 38 | 6.2 s | 1,980 ms | 0.000 |
| Retailer D | 42 | 15.0 s | 300 ms | 0.231 |
| Retailer E | 54 | 20.2 s | 150 ms | 0.000 |
The median performance score was 38, with a median lab LCP of 11.5 s and median blocking time of 1,510 ms. Three of the five had a lab CLS above 0.1, which fits the promo bars, font swaps and late rails covered below. Lighthouse flagged late discovery of the LCP image and forced reflow on four pages each, plus an excessive DOM size on three. Hidden size, swatch and quick-view markup is one common cause of that last warning.
Field data tells a sharper story. Three of these clothing pages had Chrome UX Report data for their own URL. All three failed Core Web Vitals on INP, the measure of tap response. The other two had only whole-site (origin) data, and both of those sites passed. Remember that a throttled lab phone is much slower than a typical real visit, and lab LCP is not what Google assesses. Five pages is a small sample, not a ranking of fashion retailers.
Campaign images and video at the top of the page
Fashion home pages tend to lead with campaign photography or a short film. For a video, the LCP time is taken from the poster image or the first frame, whichever arrives first. That makes the poster the image to optimise. Keep it light, set it in the HTML and preload it with <link rel="preload" as="image" fetchpriority="high">, since the attribute does not go on the video itself.
Campaign images can leave retouching at print resolution. In the 2024 Almanac, 8% of mobile LCP images were over 1,000 KB. Google’s guide to optimising LCP recommends images sized to the layout, AVIF or WebP, compression, an image CDN and long cache lifetimes. It also advises serving critical resources from the same origin as the page.
Two further points apply to campaign layouts:
- Chromium does not count elements that cover the full viewport as LCP candidates. A full-screen campaign image may not be what is measured.
- Headlines baked into the image are not page text for screen readers or search. Set them as HTML text over the photo.
Product grids on category pages
A category page carries far more images than a product page. Each card may have a main image, a second image shown on hover and a row of colour dots.
- Do not lazy-load the first visible row. One of those images is likely to be the LCP element. The 2024 Almanac found 16% of mobile pages with an image LCP were lazy-loading it.
- Lazy-load everything further down, including the second images.
- Fetch hover images on demand. Hover is not an INP interaction, so loading the second image when the pointer arrives is not scored in itself. Keep the hover script light, though, or it can delay the next tap. Phones have no hover, so most mobile visitors never need it.
- Give every card image dimensions or a fixed
aspect-ratio. Clothing shots are usually one consistent portrait ratio, which makes this simple. In 2024, 66% of mobile pages had at least one image without dimensions.
Grid markup grows quickly too. A card that carries hidden quick-view markup, every size and every swatch multiplies across the grid. Google’s INP article lists a large DOM among the causes of slow interactions.
Filter taps, sorting and quick view
Filtering is where clothing sites get many of their taps. Each one often fetches new results and redraws the grid. If that redraw runs as one long task on the main thread, the next paint waits for it.
INP usually reports the slowest interaction in the visit. On pages with more than 50 interactions it ignores the slowest one for every 50. A long visit to one category page is therefore judged on the slow taps that keep happening, not on one outlier. In the 2024 Almanac, 74% of sites had good INP on mobile and 97% on desktop.
- Tick the filter and show a loading state straight away, then update the grid.
- Render only the cards that changed, rather than rebuilding the whole page.
- Load quick-view code on intent, such as focus on the card, rather than on the tap.
- Prefer server rendering for category pages. Google’s LCP guide favours server rendering or prerendering over client-side rendering, and the INP article lists client-side rendering among its causes. Some headless storefronts render category pages in the browser, so check how yours does it.
Brand fonts, promo bars and “complete the look”
Google’s CLS guidance includes web fonts that render at a different size from the fallback, content inserted above existing content, and content loaded later. Fashion sites can meet all three:
- A brand typeface swaps in and every heading reflows.
- A delivery or discount bar appears at the top after load and pushes the page down.
- A “complete the look” or “you may also like” rail loads late and lands above the reviews.
Put promo bars in the HTML from the start. Reserve space for recommendation rails at their final height. Choose font fallbacks that match the brand font’s size. For animated banners, use transform and respect the reduced-motion setting. In 2024, CLS was good on 79% of sites on mobile and 72% on desktop, so check desktop layouts too.
The back button and the grid
Clothing shoppers go back and forth between grid and product page all the time. The browser’s back/forward cache can restore the grid from memory instantly, with the filters and scroll position intact. The web.dev CLS article notes that such a restore resets CLS to zero for that view.
Two common settings can stop a page from being cached this way: unload event handlers and Cache-Control: no-store. In 2024, the Almanac found 15 to 16% of pages used unload, and 21% sent no-store. Check whether your category pages, or a third-party script on them, do either.
Testing scripts, personalisation and redirects
Fashion teams often run A/B tests. Many testing tools hide the page until their script has loaded, to stop the original version flashing up. Google’s LCP guide is clear that the LCP element should not be hidden until JavaScript loads. Personalisation that swaps the hero image after load can move the LCP time later and shift the layout as well.
Server response time is the other early cost. Google’s LCP guide gives it a guideline share of about 40% of the total. In 2024, only 42% of sites had a good Time to First Byte on mobile.
- Keep country and currency redirects to a minimum, or avoid them before the first page view.
- Watch for campaign links whose unique parameters stop the CDN serving a cached copy.
A fashion performance review
- In Search Console’s Core Web Vitals report, look at category and product URL groups separately.
- Put the home page, a large category and a product page through PageSpeed Insights, real-visit data first.
- On a phone, apply three filters in a row, sort, then open quick view. Note any lag.
- Find the LCP element on a category page and check it is not lazy-loaded.
- Reload a product page and watch the top of the screen for promo bars and font swaps.
- Open a product and press back. The grid should return at once, with filters intact.
- List every testing, personalisation and tag script, and note which ones hide content while loading.
Fashion speed work happens on the category page as much as on the product page. If you would like help, see Core Web Vitals and Shopify speed optimisation, or WooCommerce speed, caching and scripts. The fashion configurator demos show colourway, fit and trim options in use. For the rest of this series, read selling fashion online and fashion ecommerce SEO.
Sources
- web.dev articles on Web Vitals, LCP, Optimise LCP, INP and CLS, checked October 2026.
- HTTP Archive, Web Almanac 2024: Performance, published November 2024. All figures cover websites in general in mid-2024, using CrUX and lab data, and are not specific to clothing.
- My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026 (the fashion results in the table above).