Music shops have good reasons for heavy pages. An individually photographed guitar might have twenty images covering the top, the back, the headstock and every mark. The page may also carry a sound demo, a video, a finance calculator and a “notify me” form. Category pages for used and vintage stock can show hundreds of unique instruments, none of which share a photo.
None of that should go. The goal is to load it in the right order, so the first photo appears quickly, the page holds still and the controls respond. This page explains how Google measures that, and where instrument sites are likely to need work.
Speed targets and how they are measured
Google’s Core Web Vitals come from real Chrome visits, collected in the Chrome UX Report. Each metric is judged at the 75th percentile, which means three visits in four must meet the target. Phones and desktops are assessed separately.
| Metric | What a musician would notice | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint | The main photo takes a while to show | up to 2.5 s | more than 4 s |
| Interaction to Next Paint | A finish or option tap feels sluggish | up to 200 ms | more than 500 ms |
| Cumulative Layout Shift | The page jumps while you read or tap | up to 0.1 | more than 0.25 |
INP has been a Core Web Vital since 2024, when it replaced First Input Delay. It records clicks, taps and key presses, not scrolling or zooming. Lighthouse cannot measure it in the lab, so the field data in PageSpeed Insights and Search Console is the place to look.
The 2024 Web Almanac performance chapter gives a baseline for the whole web in mid-2024: 59% of sites had good LCP on mobile and 74% had good INP on mobile. Those are not music industry figures, but they suggest LCP was the harder of the two on phones.
What I measured on UK music shop product pages (October 2026)
On 23 October 2026 I put five UK instrument product pages through PageSpeed Insights. The test used mobile mode, emulating a mid-range phone on slow 4G, with one run per page.
| Page | Performance score | Lab LCP | Total Blocking Time | Lab CLS |
|---|---|---|---|---|
| Retailer A | 43 | 30.8 s | 570 ms | 0.000 |
| Retailer B | 43 | 32.0 s | 500 ms | 0.000 |
| Retailer C | 47 | 6.7 s | 1,250 ms | 0.001 |
| Retailer D | 56 | 7.3 s | 110 ms | 0.112 |
Across the four pages that loaded, the median performance score was 45 and the median lab LCP was 19.1 s. Two of them took more than 30 seconds to draw their main content in the lab. That is the weight of a big instrument gallery showing. Lighthouse flagged images without set width and height on three pages, and forced reflow (scripts making the browser recalculate layout mid-task) on three. It also flagged a late-discovered LCP image on two, the pattern a script-built gallery produces.
A throttled lab phone is much slower than most real visits, and Google’s Core Web Vitals do not use lab LCP. Read these numbers as diagnosis. Chrome UX Report field data existed for the exact URL on only one of these instrument pages, and it passed Core Web Vitals. The other three had only whole-site (origin) data, and two of those three sites passed. Four music shop pages are a small sample, not a ranking. One of the five URLs returned a 404 when tested and was left out.
Twenty photos of one guitar
The exact-instrument gallery is the music shop’s particular weight. Buyers want to see the grain, the binding and any wear, so photos are large and numerous.
On these pages the first gallery photo is typically the LCP element. Across all websites in 2024, the Web Almanac found an image was the LCP element on 73.3% of mobile pages and 83.3% of desktop pages. It also found 35% of mobile LCP elements were not discoverable in the initial HTML. A gallery that builds itself with JavaScript, or uses a data-src pattern, hides that first photo from the browser until the script runs.
Google’s LCP optimisation guide points to the fixes:
- Write the first photo into the HTML as an
<img>withsrcandsrcset, before any gallery script runs. - Never lazy-load that photo, and mark it
fetchpriority="high". Mark offscreen slidesfetchpriority="low". - Load the other nineteen photos as thumbnails, fetching the full image when the buyer opens it.
- Use modern formats. In the 2024 data, JPEG was the format of 61% of desktop LCP images, WebP of 7% and AVIF of 0.3%, with mobile similar. WebP or AVIF can keep wood grain detail at smaller file sizes.
- Serve photos from the page’s own origin, through a CDN if you use one, rather than from a separate image host.
Keep the original high-resolution file available behind a “view full size” link. Players who want to inspect a flame top can still do so.
Sound demos and video
A demo recording is often the most persuasive thing on an instrument page. It is also often the heaviest, once the video player, its scripts and its tracking come with it.
The LCP article counts <video> elements as LCP candidates, timed by the poster image or the first frame, whichever is earlier. A large self-hosted video above the gallery can therefore become the element Google measures.
- Use a placeholder image with a play button and load the player only when it is pressed.
- Give the placeholder the player’s exact size, so nothing below it moves.
- For audio-only clips, set
preload="none"on the audio element, so the file is not fetched until the buyer presses play. - Place demos below the gallery and the buy button unless they are the main selling point.
Category pages full of one-off instruments
A used or vintage listing is a grid of unique photos with prices, condition notes and “just arrived” labels. It changes daily, so it may be left uncached and be slow to build on the server.
The LCP optimisation guide treats server response as the first part of LCP, and suggests a faster server, fewer redirects and avoiding unique URL parameters that defeat CDN caching. Even a cache of a few minutes on a stock listing can help.
CLS is the other risk. Its causes include images without known dimensions, content inserted above existing content, and content loaded asynchronously.
- Set a fixed aspect ratio for every thumbnail. Guitars photographed upright and drum kits photographed wide should still fit the same card shape.
- Reserve space for labels and prices, even when they come from a separate stock feed.
- Add new items below the current ones when loading more.
Custom builders: finishes, pickups and hardware
Some shops and makers offer a custom builder: choose a body wood, a finish, pickups, hardware colour and a neck profile, and see the result. Many are image-based, layering transparent pictures on top of each other.
Each choice is an interaction for INP. web.dev splits the delay into input delay, processing and presentation, and links to guidance on long tasks, script evaluation and large DOM sizes. A builder that re-renders every layer and recalculates price, stock and lead time before showing the change can feel slow on a mid-range phone.
- Change only the layer that changed. A new pickguard should not reload the body image.
- Fetch the next layer when a swatch is hovered or focused, so it is ready by the tap.
- Keep each layer to the size it is displayed at, and use a format with transparency such as WebP.
- Update the price after the image, not before.
The musical instrument configurator page explains how these builders are put together, and the music demos show layered option changes you can try.
Testing an instrument page step by step
- Look at Search Console’s Core Web Vitals report and find which groups of similar URLs fail, and on which device.
- Run an individually photographed instrument page and a used stock listing through PageSpeed Insights. Read the field data first.
- View the page source and check that the first gallery photo is there as an
<img>. - Count how many full-size photos load before the first scroll.
- Press play on a demo with the network panel open, and check that nothing large loaded before you did.
- Work through a custom builder on a mid-range phone and note any tap that lags.
Most of this is invisible to the buyer apart from the speed. If you would like help, see Core Web Vitals or WooCommerce speed, caching and scripts. The rest of the series covers musical instrument ecommerce SEO and selling musical instruments online.
Sources
- Google’s web.dev articles, consulted October 2026: the Web Vitals overview, the LCP definition, how to optimise LCP, the INP definition and the CLS definition.
- Web Almanac 2024, Performance chapter, HTTP Archive, November 2024. Data from mid-2024 for all websites; not specific to music retail.
- My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026 (the music shop results in the table above).