A bike product page asks a lot of a phone. It may carry wide studio shots with zoom for the drivetrain, a frame size picker and a fit calculator that asks for height and inside leg. Add a stock check against every store, a finance or cycle-to-work calculator, reviews and a geometry table. Each feature helps sell a bike. Together they can produce a page that appears slowly, jumps as stock messages arrive and hesitates when the rider taps a size.

This guide covers how Google measures that experience and where cycle sites are likely to lose time, with fixes that keep the features buyers rely on.

Three numbers, judged on real visits

Google’s Core Web Vitals are measured at the 75th percentile of real page loads, so three visits in four need to reach “good”. Phones and desktops are scored separately.

MetricGoodPoorWhere it bites on a bike page
LCP, loading2.5 s or lessover 4 sthe first side-on product shot
INP, responsiveness200 ms or lessover 500 msframe size taps, colourway taps, typing into a fit calculator
CLS, visual stability0.1 or lessover 0.25store stock lines and finance banners that arrive late

INP took over from First Input Delay as a Core Web Vital in 2024. Real-visitor numbers come from the Chrome UX Report, which feeds PageSpeed Insights and Search Console. Lighthouse and similar lab tools simulate a single visit to one bike page. They are good for finding causes, but Lighthouse cannot measure INP and reports Total Blocking Time in its place.

What the 2024 Web Almanac says

The Web Almanac 2024 performance chapter used Chrome UX Report data from mid-2024 across all kinds of site. Its figures are not about cycling, but they describe mistakes a bike page can easily make:

  • In 2024, 43% of sites passed all three Core Web Vitals on mobile and 54% on desktop.
  • The largest element was an image on 73.3% of mobile pages and 83.3% of desktop pages.
  • Among mobile pages whose largest element was an image, 16% lazy-loaded that image.
  • Only 15% of mobile pages put fetchpriority="high" on the LCP image, though that was up from 0.03% in 2022.

For a cycle shop, the takeaway is that the main product photo is likely to decide LCP, and many sites still load it late.

What I measured on UK bike product pages (October 2026)

I tested five UK bike product pages with PageSpeed Insights on 23 October 2026. Each had one run on the mobile setting, an emulated mid-range phone on slow 4G.

PagePerformance scoreLab LCPTotal Blocking TimeLab CLS
Retailer A215.2 s4,670 ms0.333
Retailer B1652.8 s730 ms0.710
Retailer C653.8 s570 ms0.000
Retailer D623.7 s1,920 ms0.686

The median performance score for the four bike pages was 18.5, against 41 across all 103 valid pages I tested in every industry. Their median lab LCP was 14.5 s, and one page took 52.8 s. Lighthouse flagged late discovery of the LCP image on all four, the hero shot problem described below. Three had a lab CLS above 0.3, the scale of shift that late stock lines and finance banners produce. Retailer A also blocked the main thread for 4,670 ms.

Lab tests on a throttled phone run far slower than most real visits, and Google’s Core Web Vitals rest on field data, not lab LCP. No bike page had Chrome UX Report data for its own URL. On whole-site (origin) data, two of the four sites passed. Four pages is a small sample, not a ranking of cycle shops. A fifth test did not complete, so that page is left out.

The side-on hero shot (LCP)

Google’s guide to optimising LCP splits the time into four parts: server response, the delay before the image starts loading, the download itself and the delay before it is drawn. Its guideline is that the two delays should be close to zero.

Bike photos have their own quirks. They are wide, so on a phone the hero shows at a small height but is often served at full desktop width. Studio exports are frequently large enough to read the chainring teeth, because the same file feeds the zoom view. My advice is to separate the two: serve a gallery image sized to the layout, and fetch the zoom file only when the buyer opens zoom.

Google’s other fixes apply directly:

  • Write the first bike photo into the HTML as an <img> with src and srcset. A gallery that injects it with JavaScript hides it from the browser’s early scan.
  • Do not lazy-load it. Lazy loading belongs on the second photo onwards.
  • Mark one image fetchpriority="high". The benefit drops if more than one or two images get it. Offscreen gallery slides can take fetchpriority="low".
  • Serve it from your own origin. Dealers sometimes hot-link product shots from a brand’s media server, which adds a connection before the download starts. Copy the file to your own domain, with a CDN in front if you use one.
  • Use WebP or AVIF and long cache lifetimes, so a rider comparing three sizes is not downloading the same photo again.

Size pickers and fit calculators (INP)

INP records clicks, taps and key presses through the whole visit. Each frame size tap is one. Every key press typed into a fit calculator is another. Scrolling the geometry table or swiping the gallery is not counted. INP usually reports the slowest interaction, ignoring one of the highest per 50 interactions on long visits.

Each interaction has three phases: the wait before the handler runs, the handler itself and the time to draw the result. On a bike page, the handler is a likely place for time to go. A size tap might update the price, query stock for that size across stores, rebuild the geometry highlight and fire several analytics events.

  • Show the selected size and its stock status first. Run slower work, such as store lookups and tracking, after the screen has updated.
  • Let the fit calculator wait until the rider has finished typing before working out a size, rather than recalculating on every key press.
  • Avoid re-rendering the whole product form for one change. The INP article points to large page structures and layout thrashing as causes of slow interactions.
  • Load chat, reviews and finance scripts after the page is usable, and review the list each season.

Store stock, finance and layout shift (CLS)

A cycle shop with several branches often shows live stock per size per store. That data arrives from a stock system after the page has loaded, and the line it adds can push the basket button down the screen. Finance offers, cycle-to-work calculators, review stars and cookie banners do the same.

Google’s CLS guidance names five causes: images and video without dimensions, web fonts that render at a different size from the fallback, third-party widgets that resize, content inserted above what is already shown, and content loaded asynchronously.

One detail matters for size pickers. Shifts within 500 ms of a tap, click or key press are excluded. If the stock line for a new size appears quickly, it does not count. If the stock system takes a second and a half to answer, the shift counts against you.

  • Reserve the space for the stock line, with a placeholder such as “Checking stock” at the same height.
  • Give the finance and review areas a fixed minimum height.
  • Set width and height, or aspect-ratio, on every product image and category card.
  • Animate drawers and accordions with transform rather than by changing their height.

Category grids, colourways and video

A category page of bikes is a grid of wide images. Load the first row normally and lazy-load the rest. If each card offers colour dots, avoid loading every colourway’s photo up front. Fetch a colour’s image when the buyer hovers over or focuses its dot, and keep the current image visible until the new one arrives.

Brand home pages often open with ride footage. A video can be the LCP element, timed from when its poster loads or its first frame shows, whichever is earlier. A light, compressed poster image keeps that number low.

A 3D bike viewer should load only when the buyer asks for it, with a still image standing in until then. I explain how that is built in how a 3D product configurator is built, and the bike configurator page shows where it fits for cycling.

Measuring a cycle site, step by step

  1. Start in Search Console, under Core Web Vitals. Similar URLs are grouped, so model pages, category pages and store pages usually appear apart.
  2. Run a bike page with many sizes, a category page and the home page through PageSpeed Insights. Look at the real-visitor figures first and the lab diagnosis second.
  3. On a mid-range Android phone, tap through four frame sizes and type into the fit calculator. Note any delay you can feel.
  4. In Chrome DevTools, check which element is the LCP on a bike page. If it is a banner, a logo or the zoom image, find out why.
  5. Time the store stock check after a size tap, and watch whether the page moves when it answers.
  6. List every third-party script on a bike page and who owns it. Remove anything nobody can explain.

Most of this work leaves the design as it is. If you would like it done for you, see Core Web Vitals, Shopify speed optimisation or, for WooCommerce shops, speed, caching and scripts. The rest of the cycling series covers selling bikes online and bike shop SEO.

Sources