Kitchen Website Performance: Core Web Vitals for Kitchens

Kitchen websites sell with big pictures. Many range pages open on a full-width photograph of a finished room, often inside a slider. Below it sits a door colour picker, then a long list of units, each with its own image. Worktop pages add a price calculator, and many sites add a planner, a brochure pop-up, a finance widget and an appointment booker. Every one of those can be built to load quickly, and every one can also hold a page back.

Here is how Google measures that, and where kitchen sites often need work.

The three measures, applied to a kitchen page

Google’s Core Web Vitals are collected from real Chrome visits and assessed at the 75th percentile, so three out of four visits need to pass. Mobile and desktop are scored separately.

Largest Contentful Paint marks when the largest image, text block or video in view is drawn. On a range page that is often the room-set photo. It should happen within 2.5 seconds, and anything beyond 4 seconds counts as poor.

Interaction to Next Paint measures the wait between a click, tap or key press and the next frame. It splits that wait into input delay, processing time and presentation delay. A response within 200 ms is good; over 500 ms is poor. Scrolling and hovering are not included, but typing is.

Cumulative Layout Shift scores the largest burst of unexpected movement of page content during the visit. A score of 0.1 or less is good, and above 0.25 is poor.

Search Console and PageSpeed Insights show field data for these. Lighthouse gives lab results that are useful for diagnosis, though it cannot record INP and uses Total Blocking Time in its place.

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

On 23 October 2026 I put five UK kitchen product pages through the mobile test in PageSpeed Insights: one run each on an emulated mid-range phone over slow 4G.

Page	Performance score	Lab LCP	Total Blocking Time
Retailer A	57	9.6 s	0 ms
Retailer B	54	5.7 s	650 ms
Retailer C	53	12.6 s	390 ms

Only three pages gave results, with a median score of 54 and a median lab LCP of 9.6 seconds, so none came near the 2.5 second target. None shifted in the lab, but Lighthouse flagged forced reflow on all three: a script making the browser recalculate layout mid-task, the sort of work that slows a door colour change or a worktop calculator. Their weak points also differed, with Retailer B drawing its main image fastest but blocking the main thread for 650 ms, and Retailer A blocking nothing but drawing more slowly.

Three caveats:

Lab figures from a throttled phone lag well behind most genuine visits, and they are not the LCP figure Google uses.
One URL had its own Chrome UX Report data, and it passed Core Web Vitals. The other two had only site-level data: one site passed and one failed.
Three pages are a very small sample, not a ranking.
Of the five pages tested, one returned a 404 and one test did not complete, so both were left out.

In 2024, phones failed more often than desktops

The 2024 Web Almanac performance chapter shows how wide the gap was across all websites in mid-2024. These are not kitchen figures:

INP was good on 74% of mobile sites against 97% on desktop.
LCP was good on 59% of mobile sites.
Time to first byte was good on only 42% of mobile sites.
35% of mobile LCP elements were not discoverable in the initial HTML.

A kitchen site checked on an office desktop can look fine while its mobile visitors have a different experience. Test on a phone.

Room-set heroes and sliders (LCP)

The opening photograph sells the range, so it tends to be large, and it is often placed in a rotating slider. Google’s LCP optimisation guide explains what slows it.

Make the first slide a real <img> in the HTML. Sliders that build slides with JavaScript, or set them as CSS backgrounds, stop the browser finding the photo early. If a CSS background cannot be avoided, preload it with fetchpriority="high".
Prioritise only the first slide. Give the others fetchpriority="low" and load them later.
Never set loading="lazy" on the hero.
Serve a size that fits the screen. A phone does not need the photographer’s full-resolution export. Use AVIF or WebP from your own origin with long cache headers.
Do not hide the hero until a script runs. Some sliders keep slides invisible until their JavaScript initialises, which delays LCP for no gain.

Server response time also counts towards LCP. Brochure emails and paid campaigns add tracking parameters to links, and Google’s guide notes that unique URL parameters can stop a CDN serving its cached copy. Configure the CDN to ignore parameters that do not change the page.

Range pages that list every unit

A range page might show dozens of base, wall and tall units, each with a thumbnail, sizes and a price. That is a lot of images and a lot of page structure.

Give every unit thumbnail width and height, or an aspect-ratio, so the list does not jump as images arrive.
Lazy-load thumbnails below the first screen, and size them for the space they occupy.
Group units into sections such as base, wall and tall, and load each group on request, so the page does not draw everything at once.
When a door colour changes, swap image sources only. Re-rendering the whole unit list on each colour tap can make INP worse.

Door colours and wood-grain swatches

Door colour swatches are easy to overload. Painted colours can be flat CSS colours or tiny images. Wood grains and textured finishes need an image, but a swatch shown at 48 pixels needs a file of roughly double that size for sharp screens, not a crop of the full door photograph.

Load a colour’s room photography only when the buyer picks that colour, and keep the current photo on screen until the next one is ready. For worked examples of colour choice, see the kitchen configurator demos.

Calculators and key presses (INP)

Kitchen sites ask buyers to type. A worktop length, a door height, a cornice run or a postcode for delivery all go into form fields. INP counts key presses, so typing “2875” into a length field is four interactions.

If each key press triggers a price recalculation, a request to the server and a redraw of the summary, any one of those key presses can be slow on a mid-range phone. INP usually reports the worst of them.

Update the field itself immediately. That is what the buyer is looking at.
Wait until typing pauses before recalculating, and run the calculation off the critical path.
Show the new price in a space that already exists, so it does not push the add-to-basket button down.

Pop-ups, finance and booking widgets (CLS)

Google’s CLS guidance lists content inserted above existing content and asynchronously loaded content among the causes of layout shift. Kitchen sites often have both.

A brochure offer drawn as a fixed overlay does not move the page. The same offer inserted as a bar at the top pushes everything down.
Finance calculators and review widgets need a reserved height that matches what they will display.
Appointment booking tools are often iframes from another service. Give the iframe a fixed height.
Animate panels with transform rather than by changing height.

Planners and 3D design tools

A kitchen planner can be one of the heaviest things a site runs. Load it only when the buyer opens it, ideally on its own page, with a still image or short description in its place on product pages. For 3D, compress models with Draco or Meshopt and textures with KTX2. More detail is in how a 3D product configurator is built.

A kitchen site speed checklist

In Search Console’s Core Web Vitals report, compare mobile and desktop. Across the web in 2024, mobile had the lower overall pass rate.
Run a range page through PageSpeed Insights and note which element is reported as LCP.
View the page source and search for the hero image’s file name. If it is absent, a script is adding it.
Check the CDN cache status on a URL with and without a campaign parameter.
Type a worktop length on a mid-range Android phone and watch for lag between key presses.
Change door colour on a range page and record a performance trace of the tap.
Load a range page on a slow connection and watch for banners or widgets pushing content down.

For help with any of this, see my Core Web Vitals service, or WooCommerce speed, caching and scripts for WordPress shops. The related pages are kitchen ecommerce SEO, kitchen ecommerce and the kitchen configurator.

Sources

web.dev, checked October 2026: Web Vitals for the 75th percentile rule, LCP and Optimise LCP for room-set heroes and caching, INP for calculator key presses, CLS for pop-ups and widgets.
HTTP Archive, Web Almanac 2024: Performance, November 2024, mid-2024 data for all websites rather than kitchen retailers.
My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026, for the kitchen results table above.