Lighting Website Performance: Core Web Vitals for Lighting

Lighting is hard to sell without photographs, and lighting photographs are heavy. A product page may show the fitting unlit on white, switched on, in a room at dusk and in close-up on the finish. A category page can hold sixty tiles that each swap to a lit photo on hover, beside a filter panel with a dozen technical options. None of that is a mistake. It does mean a lighting site can be slow on a phone unless the weight is managed.

Below is how Google judges speed, where lighting pages tend to lose it, and what to change.

Three numbers Google looks at

Google’s Core Web Vitals come from real Chrome visits. Each is judged at the 75th percentile, with phones and desktops assessed separately.

Largest Contentful Paint times the largest image, text block or video in view. Good is 2.5 seconds or under; poor is over 4 seconds.
Interaction to Next Paint times the response to clicks, taps and key presses across the visit, and usually reports the worst one. Good is 200 ms or under; poor is over 500 ms. Hover, scroll and zoom are not counted.
Cumulative Layout Shift scores unexpected movement of the layout. Good is 0.1 or under; poor is over 0.25.

Search Console’s Core Web Vitals report and the top section of PageSpeed Insights show this field data. Lighthouse runs a lab test, which is useful for diagnosis but cannot measure INP. It reports Total Blocking Time in its place.

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

On 23 October 2026 I ran five UK lighting product pages through PageSpeed Insights on mobile, once each. That test emulates a mid-range phone on a slow 4G connection.

Page	Performance score	Lab LCP	Total Blocking Time	Lab CLS
Retailer A	51	20.0 s	290 ms	0
Retailer B	42	9.5 s	550 ms	0
Retailer C	26	10.9 s	630 ms	0.327
Retailer D	64	11.1 s	0 ms	0
Retailer E	60	10.7 s	150 ms	0

Lighting did better than most industries I tested, with a median score of 51 against 41 across all 103 pages, and a median blocking time of 290 ms. The first photograph was still slow: the median lab LCP was 10.9 seconds, and Lighthouse flagged how the LCP image was discovered on three pages. Four pages had images without set dimensions, and Retailer C’s lab CLS of 0.327 was in the poor range, the kind of jump a gallery that resizes per photo can cause.

Before reading too much into it:

Lab results on a throttled phone run well behind a typical visit, and Google does not judge pages on lab LCP.
The Chrome UX Report held no field data for any of these five URLs on their own, only for each whole site. Four of the five sites passed Core Web Vitals on that site-wide data.
Five pages show patterns worth checking. They are not a league table.

What the 2024 Web Almanac found about images

The 2024 Web Almanac performance chapter studied the whole web in mid-2024, not lighting sites. Its image findings are still likely to apply to a lighting product page:

The LCP element was an image on 73.3% of mobile pages and 83.3% of desktop pages.
Only 15% of mobile pages set fetchpriority=high on the LCP image, although that was up from almost none in 2022.
16% of mobile pages whose LCP was an image lazy-loaded that image.
On desktop, 61% of LCP images were JPEG, 7% WebP and 0.3% AVIF, with mobile similar.

Put simply, most pages in 2024 were waiting on an image, few told the browser which image mattered, and some delayed it on purpose.

The first photograph of the fitting (LCP)

On a lighting product page, the LCP element is typically the first gallery image. Google’s guide to optimising LCP splits that time into server response, load delay, download time and render delay. It suggests the two delays should be close to zero.

Decide whether the lit or unlit shot leads. Whichever it is, make it the only image with fetchpriority="high". Google notes the benefit fades when more than one or two images carry it.
Put it in the HTML as an <img> with src and srcset. A gallery that waits for JavaScript, or uses a data-src lazy pattern, hides the photo from the browser’s early scan.
Do not lazy-load it. Lazy loading suits the room shots further down, not the first frame.
Serve AVIF or WebP at sizes that match the layout, from the same origin as the page, with long cache lifetimes.
Check compression by eye. Soft glows and dark gradients can show banding when squeezed hard, so test settings on a few lit photos before applying them to the whole catalogue.

Finish swatches and lit or unlit pairs

A fitting in five finishes, with a lit and an unlit photo for each, has ten main images before any room scenes. Loading them all at once spends bandwidth the first photo needs.

Make finish swatches tiny images of the metal or glass, not shrunken copies of the full product photo.
Fetch a finish’s photos when the buyer selects that swatch or focuses it, and keep the current photo on screen until the new one has arrived.
If the gallery has a lit and unlit toggle, fetch the alternate shot once the page is usable, so it is ready without competing with the first image.
Fix the gallery’s aspect ratio. Long-drop pendants and wide room scenes have very different shapes, and a frame that resizes per photo moves everything beneath it.

That last point matters for CLS. A shift within 500 ms of a tap is excused, but a photo that arrives a second later and resizes the gallery is counted.

Category pages full of technical filters (INP)

Lighting listings filter by finish, room, IP rating, lamp cap, colour temperature, dimmability and number of arms. Every filter tap is an interaction that INP times. When a tap triggers a full client-side re-render of sixty product tiles, the next paint can miss the 200 ms target on a mid-range phone.

Respond at once. Tick the box and show a loading state on the grid, then fetch and draw the results.
Keep the page’s DOM modest. Paginate, or load more products on request, instead of drawing the entire range.
Avoid recalculating every filter count on the main thread after each tap. Let the server send the counts with the results.
Reserve space for anything that appears late, such as a result count or a “sort by” bar.

Hover swaps from unlit to lit tiles cost nothing for INP, since hover is not an interaction. They can still download a second image for every tile. Fetch those on hover only, and skip them on touch screens where there is no hover.

Room scenes, dimming videos and 3D viewers

Premium fittings often come with room-scene carousels, short videos showing the dimming range, or a 3D viewer.

Video. A <video> element can become the LCP element through its poster image or first frame, whichever arrives first. Give it a light, compressed poster, and keep heavy autoplaying files out of the first screen.
Carousels. Mark offscreen slides fetchpriority="low" and lazy-load them.
3D. Glass, polished metals and glowing shades can be expensive to render in a browser. Load the viewer only when the buyer asks for it, behind a still image that serves as the LCP element. Compress geometry with Draco or Meshopt and textures with KTX2.

The 3D side is covered in more depth in how a 3D product configurator is built, and examples sit in the lighting configurator demos.

Third-party scripts on lighting pages

Trade login checks, finance calculators, review widgets, live chat and analytics all compete for the main thread. A busy main thread delays the response to the first finish tap. Load each one after the page is usable, give any visible widget a reserved height, and remove scripts nobody can explain.

A speed check for a lighting site

In Search Console’s Core Web Vitals report, start with mobile. Note which group of similar URLs fails: products, categories or both.
Run a pendant page through PageSpeed Insights and read the field data before the lab score.
Find the LCP element in Chrome DevTools. Confirm it is the photograph you intended, lit or unlit.
Check that the hero has fetchpriority="high", has no loading="lazy", and appears in the page source.
On a category page, tap three filters in quick succession on a mid-range Android phone. If the grid lags, record a performance trace.
Count the images a product page with several finishes downloads before anyone touches it.
List every third-party script, what it does, and when it loads.

Most of these fixes leave the look of the site unchanged. For help, see my Core Web Vitals service, or Shopify speed optimisation and WooCommerce speed, caching and scripts. The rest of this series covers lighting ecommerce SEO and selling lighting online.

Sources

web.dev: Web Vitals, LCP, Optimise LCP, INP and CLS, all checked October 2026, used for thresholds and lighting gallery fixes.
HTTP Archive, Web Almanac 2024: Performance, published November 2024. Figures cover all websites in mid-2024, not lighting retailers.
My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026, for the lighting results table above.