Hardware buyers often compare the same part across several shops, one tab each, so a slow page is easy to close. Yet hardware pages carry a lot of content. A graphics card page can hold a spec table with sixty rows, a gallery of transparent renders, a benchmark chart, an embedded review video and a live stock checker. A category page can list a hundred motherboards with a filter panel down the side.

This page covers where that weight hurts Google’s Core Web Vitals, and what to change first. It is written for the person who owns the shop’s results, not only the developer.

Three numbers, scored on real visits

Google’s Web Vitals programme names three Core Web Vitals, judged on field data from real Chrome users. A page passes a metric when at least 75% of visits reach the “good” level, and mobile and desktop are scored separately.

  • Largest Contentful Paint (LCP) is the time until the largest image, text block or video in view appears. The target is 2.5 seconds or under, and anything above 4 seconds counts as poor.
  • Interaction to Next Paint (INP) is the delay between a click, tap or key press and the screen updating. Good is 200 milliseconds or less; poor is over 500.
  • Cumulative Layout Shift (CLS) scores unexpected jumps in the layout. Good is 0.1 or less; poor is over 0.25.

INP took over from First Input Delay as a Core Web Vital in 2024. Lighthouse, the lab test inside PageSpeed Insights, cannot measure INP and shows Total Blocking Time instead. For a hardware shop that runs a PC builder, that gap matters, because the builder is where INP problems are most likely.

It is tempting to assume hardware buyers all shop at a desk. Some will, but phones are scored on their own. The 2024 Web Almanac performance chapter, using mid-2024 data across all websites, found 97% of sites had good INP on desktop against 74% on mobile. The same page can pass on one and fail on the other.

What I measured on UK PC hardware product pages (October 2026)

PageSpeed Insights tested five UK PC hardware product pages for me on 23 October 2026, once each, in mobile mode with an emulated mid-range phone on slow 4G.

PagePerformance scoreLab LCPTotal Blocking TimeLab CLS
Retailer A665.1 s170 ms0.004
Retailer B578.4 s390 ms0.009
Retailer C628.8 s110 ms0.001

These were among the better results in my tests, with a median score of 62 against 41 across all 103 pages, and low blocking time and layout shift. Even so, lab LCP was more than double the 2.5 second target on every page, with a median of 8.4 seconds, so the sections on renders and server response below still apply. Lighthouse also flagged layout shift culprits on all three pages and images without set dimensions on two, even though the measured shift was tiny.

How far to trust this:

  • A test on a throttled phone runs much slower than most real visits, and its LCP is not what Google assesses.
  • None of the three URLs had page-level data in the Chrome UX Report. All three sites passed Core Web Vitals on their site-wide field data.
  • Three pages cannot rank an industry. They only show where to look.
  • Two of the five pages were left out: one returned a 404, and the other test did not complete.

Spec tables, comparison grids and page size

Hardware pages are long. A full spec table, a “compare with similar” grid, question and answer threads and reviews can add thousands of elements to the page. web.dev’s INP guide lists a large DOM and costly layout work among the causes of slow responses, alongside long tasks and client-side rendering.

The fixes are mostly structural:

  • Render the key specs in the HTML and put the full table behind a “show all specifications” control, still in the page source for search engines.
  • Avoid rebuilding the whole table when a buyer switches between capacities or editions. Update the cells that changed.
  • Cap comparison grids at a sensible number of products, and load extra columns when asked.
  • Paginate questions and reviews. A page with four hundred answered questions does not need them all in the first load.

The PC builder: every click checks compatibility

A custom PC builder is the hardest page on a hardware site to keep fast. Each part choice can trigger a compatibility check against the socket, the case clearance and the power budget, a price recalculation and a stock lookup. If all of that runs on the main thread before the screen updates, every click feels sticky.

INP counts clicks, taps and key presses across the whole visit, and usually reports the slowest. On pages with more than 50 interactions, web.dev says one of the highest is ignored for every 50. A long builder session may pass that number, but the slow clicks still largely decide the score.

  • Show the choice first. Highlight the selected part and update the summary straight away, then run the slower checks.
  • Move rule checking off the main thread. web.dev’s INP material points to web workers for heavy script work. A compatibility engine is a good candidate.
  • Fetch stock and price once per part list, not once per click, and cache the answers for the visit.
  • Keep the list of parts short on screen. Two hundred cards in a picker is a lot of layout to redo after each filter tap.

I go into builder structure on the PC hardware configurator page, and the PC and gaming hardware demos show option changes you can try.

Transparent renders and the LCP image

Manufacturers often supply product shots as large PNG renders with transparent backgrounds, so they sit on any page colour. Those files are often much larger than an equivalent JPEG or WebP. In the 2024 Web Almanac, across all websites, PNG was the format of 26% of LCP images on desktop, with mobile similar.

Google’s LCP optimisation guide sets out what to check for the main product image:

  • Convert renders to WebP or AVIF, both of which support transparency. Serve sizes that match the layout, not the supplier’s master file.
  • Put the first image in the HTML with src and srcset, never injected by script or set as a CSS background.
  • Do not lazy-load it, and give it fetchpriority="high". The guide says the benefit drops if more than one or two images get that hint.
  • Serve it from the same origin as the page. A supplier image host or a third-party image service on another domain adds a connection before the download.

RGB lighting shots and dark cases on black backgrounds deserve a separate look. Exported at maximum quality they stay heavy, while hard compression can show banding in dark gradients, so check a few settings by eye.

Launch days, deal traffic and server response

New hardware launches can create sharp traffic peaks. Deal sites and price comparison sites then often send visitors with long tracking parameters attached. Both hit the first part of LCP: the time to the first byte from the server.

Across all websites in mid-2024, the Web Almanac found only 42% had a good Time to First Byte on mobile. As a guideline, web.dev’s guide gives server response about 40% of the LCP time, and lists ways to cut it: fewer redirects, a faster server, and avoiding unique URL parameters that stop a CDN from caching the page.

  • Cache product and category pages at the edge, and make sure tracking parameters do not create a new cache entry for every visitor.
  • Keep queue pages and stock checks separate from the cacheable product page, loaded after it.
  • Remove redirect chains from affiliate and comparison links where you control them.

Prices and stock that arrive late

Hardware prices change often, so many shops load price, stock and delivery estimates by script after the page appears. If those blocks have no reserved space, they push the buy button down as they arrive. web.dev’s CLS guide names late-loading content and third-party widgets that resize among the causes of layout shift.

Give price, stock and finance blocks a fixed minimum height. Shifts within half a second of a click or tap are excluded, so opening a spec section on demand is fine. A finance banner that appears two seconds after load is not.

Testing a hardware shop: step by step

  1. Open Search Console’s Core Web Vitals report and find which groups of similar URLs fail, and on which device.
  2. Run a busy graphics card page, a motherboard category and the PC builder through PageSpeed Insights. Read the field data before the lab score.
  3. Check the LCP element on a product page. If it is a transparent PNG, check its file size.
  4. In the builder, use Chrome DevTools’ Performance panel while choosing ten parts. Note any click that takes longer than 200 milliseconds to update the screen.
  5. Request a product URL with a tracking parameter and check whether your CDN serves it from cache.
  6. Count the elements on a long product page, and see what loads before the first scroll.

Most of this work changes nothing a buyer would notice except speed. If you would like it done for you, see Core Web Vitals or Shopify speed optimisation. The rest of the series covers PC hardware ecommerce SEO and selling PC and gaming hardware online.

Sources