Shoe pages ask a lot of a phone. A product page often carries a gallery of side, sole, heel and on-foot shots, often with a 360 spin. Below it sit a strip of colourways, a size grid that checks stock and a size-finder widget. Payment messages and reviews sit underneath. Many home pages open with a slider of new releases. Each of these can delay the first view, move the layout or hold up the response when a buyer taps a size.
This guide explains how Google measures those effects and where a footwear site is most likely to lose time. The aim is a faster page that keeps the spins and the size tools buyers rely on.
The three scores, applied to a shoe page
Google’s Core Web Vitals are measured from real visits, at the 75th percentile, with phones and desktops scored separately. In practice, three visits in four need to reach the “good” mark.
| Metric | Good | Poor | Where to look first on a shoe site |
|---|---|---|---|
| LCP: time until the main content appears | 2.5 s or less | over 4 s | The first slide on the home page, the first gallery shot on a product page |
| INP: delay between a tap or click and the screen updating | 200 ms or less | over 500 ms | Size buttons, colourway thumbnails, the add-to-bag button |
| CLS: unexpected movement of the layout | 0.1 or less | over 0.25 | Payment messages, fit widgets, stock notices, the sticky bag bar |
Real-visit data comes from the Chrome UX Report and appears in PageSpeed Insights and Search Console. Lighthouse runs a single simulated load instead. It is useful for finding causes, but it cannot measure INP and reports Total Blocking Time in its place.
What I measured on UK footwear product pages (October 2026)
My test covered five UK shoe and trainer product pages in PageSpeed Insights on 23 October 2026. Each ran once on mobile, as an emulated mid-range phone on slow 4G.
| Page | Performance score | Lab LCP | Total Blocking Time | Lab CLS |
|---|---|---|---|---|
| Retailer A | 27 | 11.9 s | 2,820 ms | 0.028 |
| Retailer B | 39 | 25.4 s | 1,060 ms | 0.004 |
| Retailer C | 35 | 13.6 s | 2,320 ms | 0.005 |
| Retailer D | 27 | 25.9 s | 2,060 ms | 0.022 |
| Retailer E | 53 | 5.8 s | 160 ms | 0.480 |
The median score was 35 and the median lab LCP 13.6 s, but blocking time is what stands out. Four of the five pages blocked the main thread for over a second, with a median of 2,060 ms. A size tap has to queue behind that work. Lighthouse flagged layout shift culprits on all five pages and images without set dimensions on four. Retailer E loaded fastest yet shifted the most, with a lab CLS of 0.480, nearly double the 0.25 “poor” line.
Lab results come from a deliberately throttled phone, so they run far slower than most real visits. Google judges Core Web Vitals on field data rather than lab LCP. Only one shoe page had Chrome UX Report data for its own URL, and it failed, on INP. The other four showed whole-site (origin) data, and just one of those sites passed. Five footwear pages make a small sample, not a league table.
Release sliders on the home page
A home page that opens with a slider of launches often has the first slide image as its largest element. That is a common pattern across the web: the 2024 Web Almanac found the LCP element was an image on 73.3% of mobile pages. The same chapter found that 35% of mobile LCP elements could not be found in the initial HTML.
A slider can easily end up in that 35%. Many slider scripts build the slides with JavaScript, or show them as CSS backgrounds, so the browser cannot start the download until the script has run. Google’s guide to optimising LCP gives the fixes:
- Put the first slide in the HTML as an
<img>withsrcandsrcset. - Never lazy-load it. The 2024 Almanac found 16% of mobile pages whose LCP was an image were lazy-loading that image.
- Add
fetchpriority="high"to the first slide only. Google notes the benefit falls when it is used on more than one or two images, and suggestsfetchpriority="low"for offscreen slides. Only 15% of mobile pages used it on their LCP image in 2024. - Do not keep the slider hidden until its script has loaded. A slide that fades in after the JavaScript runs adds render delay even when the image arrived early.
One detail is worth knowing. Chromium leaves out elements that cover the whole viewport when it picks the LCP element. A full-screen launch image may not be the element that is measured, so check what PageSpeed Insights names before optimising.
360 spins without the download
A spin is built from dozens of frames. If every frame loads with the page, a product view can download far more image data than the buyer ever sees. Those frames also compete with the first gallery image for bandwidth.
- Show a still image first and load the spin frames only when the buyer taps to open it.
- Size the frames to the viewer, not to the original studio capture, and serve them as WebP or AVIF. In the 2024 Almanac, JPEG was the format for 61% of desktop LCP images, WebP for 7% and AVIF for 0.3%, with mobile similar.
- Reserve the viewer’s space in the layout so the page does not move when the spin replaces the still.
INP counts clicks, taps and key presses, not scrolling or zooming, so the tap that opens the spin certainly counts. The web.dev article does not say how a drag is treated, so do not assume turning the spin is free: keep its handler light too. Behind the opening tap, show a loading state at once, then fetch the frames.
The size grid and the colourway strip
On a shoe page, many interactions are taps on a size. A single tap can update the price, the stock message, the delivery estimate and the state of the add-to-bag button. If that tap waits for a stock request and then re-renders the whole product area, the next paint waits with it.
Google’s INP article splits each interaction into input delay, processing time and presentation delay. INP usually reports the slowest interaction of the visit, so one sluggish size tap can set the score even when the page loaded quickly. Phones are where this shows. In the 2024 Almanac, 74% of sites had good INP on mobile against 97% on desktop.
Practical fixes for a size grid:
- Mark the chosen size as selected straight away, then update stock and delivery text when the data arrives.
- Avoid rebuilding the size grid for every colourway. Rendering hidden grids for every colour and width makes the page heavier for no gain.
- Load the next colourway’s main image when the buyer shows interest, such as on focus, and keep the current image until it is ready.
- Delay chat, analytics and marketing tags until the page is usable. Most of them run on the same main thread as the size grid.
Fit finders, payment messages and the sticky bag bar
Google’s CLS guidance names five causes of layout shift: images and video without known dimensions, web fonts that render larger or smaller than the fallback, third-party widgets that resize, content inserted above what is already there, and content loaded later. A shoe page can have all five. A size-finder widget adds a line under the title and a payment message appears beside the price. Review stars arrive late, and a “low stock in your size” note pushes the button down.
Shifts within half a second of a tap or key press are excluded. Scrolling is not treated as input, though. A sticky add-to-bag bar that appears as the buyer scrolls and pushes content down will count against CLS. Make it overlay the page instead, and animate it with transform.
- Reserve space for each widget at the height it will finally take.
- Give every gallery image
widthandheightattributes or a CSSaspect-ratio. The 2024 Almanac found 66% of mobile pages had at least one image without dimensions. - Load brand fonts so the swap does not change line lengths much.
Launch days and server response
Release days can bring short, sharp peaks of traffic to a small number of pages. Server response time, the first part of LCP, is where those peaks tend to show. Google’s LCP guide gives roughly 40% of the total as a guideline for it. In 2024, the Almanac found only 42% of sites had a good Time to First Byte on mobile.
- Serve product and launch pages from a CDN cache, and load stock levels separately so the page itself can be cached.
- Avoid unique URL parameters on launch links where they stop the CDN from using its cache, a point Google’s LCP guide makes directly.
- Keep redirects to a minimum, such as country or currency redirects in front of the product page.
Testing a footwear site
- Start with the Core Web Vitals report in Search Console. Because it groups similar URLs, problems on shoe product pages can surface as one group.
- Run the home page, a busy category and a product page with a spin through PageSpeed Insights. Read the real-visit data before the lab score.
- Note what PageSpeed Insights names as the LCP element on each one.
- On a mid-range Android phone, tap through several sizes and colourways and watch for lag.
- Scroll a product page slowly and watch for movement as the sticky bar and widgets appear.
- In the browser’s network panel, check whether spin frames download before anyone opens the spin.
- List every third-party script on the product page and who in the business uses it.
Footwear speed work is mostly about the first image, the spin and the size grid. If you would like help, see Core Web Vitals and Shopify speed optimisation, or speed, caching and scripts for WooCommerce. The footwear configurator demos show product options in use. The rest of this series covers selling footwear online and footwear SEO.
Sources
- web.dev guides behind the footwear advice above, checked October 2026, on Core Web Vitals, LCP, how to optimise LCP, INP and CLS.
- HTTP Archive, Web Almanac 2024, Performance chapter, published November 2024. Figures cover all websites in mid-2024, not footwear sites, and come from CrUX and lab data.
- My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026 (the footwear results in the table above).