On a tool site, the pages that need speed work are rarely the home page. They are the category grid with two hundred drills and a dozen filters, and the product page with a kit selector, spec table, demo video and branch stock checker. Site search matters too, because a trade buyer may well use it on a phone between jobs. Each of those pages asks the browser to do a lot, and often on a weak mobile signal.
This guide sets out how Google measures speed, which parts of a tool or workshop equipment site tend to strain it, and what to change first.
The three numbers that count
Google’s Web Vitals programme scores real visits on three measures:
- Largest Contentful Paint (LCP): when the biggest image, video or text block in view has rendered. Good is 2.5 seconds or under; poor is anything over 4 seconds.
- Interaction to Next Paint (INP): the delay between a click, tap or key press and the next frame on screen. Good is 200 milliseconds or under; poor is over 500.
- Cumulative Layout Shift (CLS): how far content moves unexpectedly. Good is 0.1 or lower; poor is above 0.25.
Each is assessed at the 75th percentile, with phones and desktops scored separately. Field data from Chrome users reaches you through the Chrome UX Report, PageSpeed Insights and Search Console. Lighthouse runs a single simulated load instead, so it cannot measure INP and shows Total Blocking Time as a proxy.
What I measured on UK power tool product pages (October 2026)
I tested five UK tool and workshop equipment product pages in PageSpeed Insights on 23 October 2026, with one mobile run per page on an emulated mid-range phone over slow 4G. The test on one of the five did not complete, so the table has four rows.
| Page | Performance score | Lab LCP | Total Blocking Time | Lab CLS |
|---|---|---|---|---|
| Retailer A | 36 | 8.2 s | 1,570 ms | 0.02 |
| Retailer B | 66 | 7.0 s | 260 ms | 0.03 |
| Retailer C | 42 | 10.8 s | 1,240 ms | 0.05 |
| Retailer D | 55 | 4.7 s | 290 ms | 0.27 |
The median score was 48.5. Median lab LCP was 7.6 seconds, quicker than the 12.8 second median across all 103 valid pages I tested, yet still about three times the 2.5 second mark. Blocking time is the bigger worry for a tool site: two pages exceeded 1,200 ms, and the median was 765 ms. Total Blocking Time is Lighthouse’s stand-in for responsiveness, so this points straight at the filter and kit-selector work covered below. Late discovery of the LCP image and layout shift culprits were flagged on all four pages, and unsized images on three.
On caveats: the Chrome UX Report held no field data for these exact URLs, so each showed only whole-site (origin) data, and two of the four sites passed Core Web Vitals. A throttled lab phone runs well behind a trade buyer’s typical visit, and Google assesses field data, not lab LCP. Four tool pages are a small sample and not a ranking.
Why filter taps deserve the most attention
In my view, INP is where tool sites have most to lose, because so much buying happens through clicks. Ticking a voltage filter, switching between body only and a kit, toggling prices between inc and ex VAT, adding a model to a comparison: each one is a counted interaction. INP covers clicks, taps and key presses (not hovering, scrolling or zooming) and usually reports the slowest across the visit. On pages with more than 50 interactions, the single highest-latency one is ignored for every 50.
Phones find this much harder than desktops. In the 2024 Web Almanac performance chapter, 74% of sites had good INP on mobile, against 97% on desktop. Those figures cover the whole web in 2024, not tool shops. Even so, they suggest that a filter sidebar which feels instant on an office desktop deserves a test on a phone.
What usually helps on filter-heavy categories:
- Do the visible work first. On a filter tick, update the grid and the result count, then send analytics events and refresh recommendations afterwards.
- Change only what changed. A VAT toggle should rewrite price text, not rebuild two hundred product cards.
- Keep the grid smaller. web.dev’s INP article points to large DOM size and client-side rendering among the causes worth investigating. Loading products in batches keeps each update cheaper. Give every batch its own paginated URL, so crawlers can still reach every product.
- Question every tag. Chat, reviews, finance and stock widgets all compete for the same main thread. That is general experience rather than a web.dev rule, and it is worth checking each tag still earns its place.
Cut-out images and the largest element
Manufacturer imagery for tools typically arrives as cut-outs on white or transparent backgrounds, often as PNG files. In the 2024 Web Almanac, PNG was the format of 26% of LCP images on desktop, behind JPEG at 61%, with WebP at 7% and AVIF at 0.3%; mobile looked similar. A transparent PNG of a mitre saw is often far heavier than a WebP or AVIF copy that looks the same, and both of those formats support transparency.
Google’s LCP optimisation guide splits the time into server response, load delay, download time and render delay. For a tool product page, these steps address each part:
- Make the main image findable in the HTML. In 2024, 35% of mobile LCP elements across the web were not discoverable in the initial HTML. A gallery that injects its first image with script hides it from the browser’s early scan.
- Do not lazy-load that image, and give it
fetchpriority="high". Google notes that the benefit fades once more than one or two images carry it. - Host it on the page’s own origin, with a CDN in front if you use one, rather than on a separate image domain.
- Keep tracking parameters from breaking the cache. Trade emails and ad clicks add parameters to product URLs. Google warns that unique URL parameters can defeat CDN caching, which pushes server response time up on exactly the visits you paid for.
- Cut redirect chains. A superseded model code that redirects twice before reaching the current model adds a round trip each time. The SEO guide for tool shops covers when to redirect old codes.
Spec tables, comparisons and sample images
A long specification table written as HTML text is cheap to render. Problems start when the same data is assembled in the browser by a comparison tool or a tabbed widget that waits for script before showing anything. Render the spec on the server where you can, so it appears with the page.
Accordions that open when tapped are safe for CLS: shifts within 500 milliseconds of a discrete input are excluded. A “compare” tray that slides in above the grid unprompted is not.
Test meter and thermal camera pages often carry many sample images showing readings and heat maps. Only the first belongs in the initial load. The rest can lazy-load further down the page.
Demo videos, stock checkers and promotions
Demonstration videos are common on tool pages, and a third-party video player can bring a large amount of script. Show a poster image with a play button and load the player only on a click. For a video element, LCP uses whichever comes first, the poster image loading or the first frame, so a light, well-compressed poster matters.
The other usual sources of layout shift on a tool page arrive late and push content down:
- branch or click-and-collect stock checkers;
- next-day delivery countdowns;
- manufacturer promotion banners, such as a free battery with a kit;
- finance offers on larger machines such as laser cutters.
web.dev names five causes of layout shift. They are unsized images and video, web fonts that differ in size from the fallback, resizing third-party widgets, content inserted above existing content, and content loaded asynchronously. Reserve each widget’s space in the layout before its data arrives, and animate with transform rather than changing height or position.
A test plan for a tools site
- Open Search Console’s Core Web Vitals report and see which group of similar URLs fails: categories, products or site search.
- Run your busiest category through PageSpeed Insights and read the field INP for mobile.
- On a mid-range phone, tick three filters in a row and switch VAT display, noting any lag.
- Find the LCP element on a product page and check its file format and whether it appears in the raw HTML.
- Open a product link carrying tracking parameters and check the response headers for a CDN cache hit.
- Follow an old model code URL and count the redirects.
- List every third-party script on a product page with its owner and purpose.
Buyers never see most of this work, only the result. I offer it as a service through Core Web Vitals and Shopify speed optimisation; WooCommerce shops can start with my guide to speed, caching and scripts. You can try the tools and workshop demos, and selling tools and workshop equipment online covers the rest of the series.
Sources
- web.dev: Web Vitals, LCP, Optimise LCP, INP, CLS. Checked October 2026.
- HTTP Archive: Web Almanac 2024, Performance. All websites, CrUX and lab data from 2024.
- My own tests: PageSpeed Insights, 5 UK product pages per industry, 23 October 2026, speed results for tool pages.