An audio product page has to do a lot of explaining. Buyers cannot hear a speaker through a screen, so shops compensate with room photos, frequency response graphs, spec images, review videos, awards, finance offers and a button to book a listening session. Headphone pages add colourway pickers and 360 spins.

Each of those helps the sale. Loaded carelessly, they also make the page jump, stall or feel slow to respond. This page explains where audio sites tend to lose speed and how to get it back, using Google’s own measurements.

What counts as slow

Google measures loading, responsiveness and visual stability with three Core Web Vitals, each taken from real Chrome visits and scored at the 75th percentile. Mobile and desktop results are reported separately, so a page can pass on one and fail on the other.

The first is Largest Contentful Paint: how long the largest image, text block or video takes to appear. Good means 2.5 seconds or less, and anything over 4 seconds is poor. The second is Interaction to Next Paint, the delay after a click, tap or key press before the page visibly reacts. It is good at 200 milliseconds or under and poor above 500. The third is Cumulative Layout Shift, a score for unexpected movement, good at 0.1 or below and poor above 0.25.

Lab tools such as Lighthouse help find causes, but they simulate one visit and cannot measure INP. The field data in PageSpeed Insights and Search Console reflects real visitors.

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

On 23 October 2026 I tested five UK audio product pages with PageSpeed Insights, one mobile run each, simulating a mid-range phone on slow 4G.

PagePerformance scoreLab LCPTotal Blocking TimeLab CLS
Retailer A3920.4 s680 ms0
Retailer B3215.6 s1,470 ms0.079
Retailer C578.6 s220 ms0
Retailer D2925.3 s1,900 ms0.032
Retailer E327.4 s1,440 ms0.052

The median score was 32, with a median lab LCP of 15.6 seconds and 1,440 ms of blocking time. Lighthouse flagged forced reflow on every page and DOM size on three, which fits long pages full of graphs, badges and widgets, and three also had images without set dimensions. Retailer E drew its main image fastest yet still scored 32, largely because its main thread was blocked for well over a second.

The usual limits apply:

  • These are lab timings from a throttled phone, far slower than most real visits, and lab LCP is not the figure Google uses.
  • Two URLs had page-level field data and both passed Core Web Vitals. Of the three judged on whole-site data, two passed.
  • Five audio pages are a small sample, not a ranking.

Frequency graphs, spec images and layout shift

Audio pages often carry a lot of technical images: frequency response plots, polar patterns, dimension drawings, connection panels and award badges. These are often added by hand in a content editor, which can drop their dimensions.

An image without width and height, or a CSS aspect-ratio, takes no space until it loads, then pushes everything below it down. The 2024 Web Almanac performance chapter found 66% of mobile pages had at least one unsized image, with a median of two per page, across all sites in mid-2024.

Layout shift was also the one Core Web Vital where desktop did worse than mobile in that data: 72% of sites had good CLS on desktop, against 79% on mobile. My guess is that wider desktop layouts, with sidebars and more widgets, give content more room to move.

  • Set dimensions on every graph and badge, including images inserted through the editor.
  • Make graphs readable on a phone, or render them as SVG with real text labels.
  • Put award badges in a fixed-size row rather than letting them load at random sizes.

Finance, demo booking and stock widgets

Higher-value audio products often carry a finance calculator, a “book a demo” panel, a stock checker across branches and a reviews widget. Many of these come from third parties and arrive after the rest of the page.

web.dev’s CLS guide names third-party widgets that resize, content inserted above existing content, and asynchronously loaded content among the causes of layout shift. It also notes that shifts within 500 milliseconds of a click, tap or key press are excluded. Scrolling and dragging do not count as input for this purpose.

  • Reserve a block of fixed height for the finance and demo panels, filled when the script loads.
  • Load the booking calendar on demand, when the buyer chooses to book, not on every product view.
  • Put branch stock below the buy button, so a late answer cannot move the button.

Review videos, 360 spins and AR

Headphone and speaker pages may embed a video review, a 360 spin or an AR viewer. Each brings scripts, and the video player can bring a lot.

The LCP guide treats a <video> as an LCP candidate, timed from its poster image or first frame, whichever is earlier. Google’s guide to optimising LCP adds that the LCP image should be in the initial HTML, never lazy-loaded, and served from the same origin as the page.

  • Lead with a photograph, not a player. Make the main product image the LCP element and give it fetchpriority="high".
  • Show a still frame with a play button in place of each video, and load the player on click.
  • Start a 360 spin or AR viewer only on request, and keep its frames sized to the space they will fill.

Room photographs of speakers are often wide, dark and detailed. Export them at the sizes the layout needs, in WebP or AVIF, rather than as one large master file.

Comparing models and the back button

Audio buyers compare. A typical session might move between three pairs of headphones or two amplifiers several times, using the back button. Browsers can make those return trips instant with the back/forward cache, which restores a page from memory. web.dev’s CLS guide notes that a restore of this kind resets CLS to zero.

Some pages cannot use that cache. Two common blockers are unload event handlers and Cache-Control: no-store headers. In the 2024 Web Almanac, 15 to 16% of pages used unload, and 21% sent no-store, across all sites.

  • Check product and category pages for unload handlers, which can come from older analytics or chat scripts.
  • Use no-store only where it is needed, such as account and checkout pages, not on product pages.
  • Test the back button in Chrome DevTools, which reports whether a page was eligible for the cache and why not.

Finish pickers and system builders

Speakers in four veneers and headphones in five colourways mean a picker on the product page. Some dealers go further with a system builder: choose an amplifier, a pair of speakers and stands, and see a combined price.

INP counts every click, tap and key press in the visit and usually reports the slowest. web.dev groups the delay into input delay, processing time and presentation delay, and links to guidance on long tasks, script evaluation and large DOM sizes.

  • Swap the photo and price first when a finish is chosen, then update stock and delivery text.
  • Preload the next finish image when the buyer hovers or focuses a swatch, keeping the current image until it is ready.
  • Run compatibility checks in a builder after the screen has updated, or in a web worker.

The audio configurator page covers system builders, and the audio demos show finish changes you can test on a phone.

Steps to test an audio product page

  1. In Search Console’s Core Web Vitals report, see which groups of similar URLs fail, on which device.
  2. Run a speaker page, a headphone page and a category page through PageSpeed Insights, and read the field data first.
  3. Load a speaker page on a phone and watch for movement as graphs, badges and finance panels arrive.
  4. Find any image without dimensions, including those added through the content editor.
  5. Move between two product pages with the back button, then check back/forward cache eligibility in DevTools.
  6. Tap through every finish on a product and note any tap that takes visibly long to respond.

If you want help, see Core Web Vitals and Shopify speed optimisation. The rest of the series covers audio ecommerce SEO and selling audio equipment online.

Sources