There’s a number sitting inside the Chrome UX Report right now that should make every British frontend developer uncomfortable. Across a sample of UK e-commerce domains analysed through the CrUX dashboard earlier this year, fewer than 55% passed the INP (Interaction to Next Paint) threshold of 200ms. For context, INP became a Core Web Vital in March 2024, replacing FID, and Google has had over two years to let the ranking signal bed in. If your UK Core Web Vitals scores are still red, that’s not a future problem. That’s money leaving your client’s business today.
I’ve spent a fair amount of time digging through CrUX field data for UK-hosted sites across retail, SaaS, and publishing verticals. What I keep seeing is a gap between what developers think their site scores and what real users on real networks in Birmingham, Manchester, or rural Scotland are actually experiencing. Lab scores in Lighthouse look fine. Field data is a mess. The delta is always user diversity: 4G on an ageing Android handset, a slow broadband connection in a terraced house with three people streaming simultaneously. That’s your actual audience for a huge chunk of UK traffic.
What the CrUX data actually shows for UK sites
Google’s CrUX (Chrome User Experience Report) aggregates real-world performance data from opted-in Chrome users, which in the UK means a reasonably representative slice of actual browsing conditions. You can query it directly via BigQuery, or use the PageSpeed Insights API to pull field data for any URL. I’d recommend doing both.
A few patterns I keep seeing in 2026 UK data specifically:
INP is the problem nobody fixed. LCP (Largest Contentful Paint) has improved significantly since 2022 because lazy-loading images and server-side rendering became standard. But INP measures responsiveness across the full page lifetime, not just load. JavaScript-heavy React and Vue SPAs tend to hammer INP because long tasks on the main thread block the browser’s ability to respond to user input. A user clicking a filter on an e-commerce PLP (product listing page) and waiting 600ms for anything to happen is having a bad time, even if the page loaded quickly.
CLS is still broken on a surprising number of UK news and publishing sites. Cumulative Layout Shift above 0.1 is the threshold, and ad-heavy editorial properties routinely fail it. Late-loading ad slots that push content down, cookie banners that reflow the page, and web fonts swapping on render are the usual culprits.
LCP on UK SaaS dashboards is frequently image-free but still slow. When the LCP element is a large text block rendered by JavaScript rather than a server-side HTML string, you get LCP scores of 4-6 seconds on mid-range devices. This catches out a lot of React-heavy product teams who never questioned whether their marketing site needed a client-side router at all.
What sluggish scores are doing to conversions
The Portent research (now a few years old but consistently replicated) put the penalty at roughly a 4.42% drop in conversion rate per additional second of load time in the 0-5 second window. More recent data from Cloudflare and Google’s own web.dev case studies backs this up across verticals. For UK SaaS with a £50/month average contract value and 10,000 monthly visitors, shaving 1.5 seconds off LCP and bringing INP under 200ms can shift conversion rates by 1-2 percentage points. Run that maths. It’s not a small number.
E-commerce is even more sensitive. Basket abandonment on mobile is already brutal in the UK, where consumers expect fast experiences after years of conditioning by Amazon and ASOS. A slow PDP (product detail page) on a 4G connection isn’t just annoying; it’s a user who went back to Google, clicked the next result, and bought elsewhere. You don’t see that in your analytics beyond an exit rate and a nagging feeling.
How to actually fix INP on a JavaScript-heavy site
INP is harder to fix than LCP because it’s not a single moment but a score built from all interactions across a session. Here’s where I’d start.
Profile long tasks in Chrome DevTools. Open the Performance panel, record a session, and look for red bars in the main thread. Any task over 50ms is a long task; anything over 200ms is the INP killer. You’re looking for event handlers that do too much synchronous work, or third-party scripts that block the main thread during user interaction.
Yield to the main thread deliberately. The scheduler.yield() API (now available in all modern Chromium-based browsers and with a polyfill for Firefox/Safari) lets you break up long tasks explicitly. Wrapping expensive state updates in scheduler.postTask() with a ‘user-blocking’ priority gives the browser space to respond to input before continuing the heavier computation.
Audit your event listeners. A React component that fires a synchronous setState inside an onInput handler for a search field, triggering a full re-render of a large list on every keystroke, is a classic INP wrecker. Debounce it, or defer the render using useTransition to mark the update as non-urgent.
Move work off the main thread. Web Workers are underused in frontend codebases, particularly in UK agency projects where the brief was always “just make it work.” Filtering large datasets, parsing JSON from APIs, or running any sort of calculation that doesn’t touch the DOM is a strong candidate for a Worker.
LCP: the quick wins that are still being missed
If your LCP element is a hero image (check using the Performance panel or PerformanceObserver in the browser console), preloading it is the single highest-ROI fix available. A <link rel='preload' as='image'> in the document head, combined with correctly sized srcset attributes and a format like AVIF or WebP, will knock seconds off LCP scores for image-led pages. I’ve seen UK retail sites drop from 4.8 seconds to under 2 seconds LCP on mobile just from this change alone.
If the LCP element is text, the priority is Time to First Byte (TTFB). Slow server response times, which are common on shared hosting and poorly configured WordPress installs (still ubiquitous in UK small business e-commerce), cascade into every other metric. A CDN with edge caching for static assets and full-page HTML caching where possible is non-negotiable. Cloudflare’s free tier handles this adequately for most small UK sites.
Font loading is the other LCP trap. Using font-display: swap is not a complete solution; it trades invisible text for layout shift. The better approach is to subset your font files aggressively (only the characters you actually use), preload the critical weights, and keep the number of font families to two at most. I’ve written before about how open source font pairing is an increasingly smart approach for UK designers, partly because the files tend to be smaller and better optimised than some commercial typeface packages.
Tools worth adding to your workflow right now
Beyond PageSpeed Insights, the CrUX API is queryable for free and returns 28-day rolling field data. Pair it with Treo’s CrUX visualiser or build your own dashboard; I pointed to a walkthrough of that kind of project in a previous article on building a personal design dashboard using Railway and the Notion API, which is worth reading if you’re the type who’d rather have the data in front of you constantly than check it manually.
Web Vitals Chrome Extension gives you field and lab data side by side while you browse. It’s the fastest way to gut-check any URL during development. Combine it with Webpagetest.org (run a UK test node, Dulles is not your audience) for waterfall analysis.
For security-conscious teams handling client sites, anything that touches production performance should be monitored consistently. A compromised script injected into your bundle will tank INP immediately; if you ever notice a sudden unexplained regression in your INP scores, check your third-party scripts first. Services like dijitul Support handle malware removal and script injection issues specifically, which is relevant given how often performance regressions turn out to have a security root cause.
The uncomfortable truth about UK Core Web Vitals in 2026 is that the tooling to diagnose and fix these issues has never been better, the data has never been more accessible, and yet the median UK site is still underperforming on INP specifically. The gap isn’t knowledge; it’s prioritisation. Performance work doesn’t get a ticket raised because it rarely has a visible face. It shows up as a sluggish feeling, a higher bounce rate, a slightly lower conversion rate than last quarter. Put a number to it, surface it to whoever controls the roadmap, and suddenly it gets prioritised. The CrUX data is the number. Use it.
If you work across design and build (which is most of us on smaller UK teams), performance is a design decision as much as a technical one. The number of image carousels, the weight of a custom typeface, the choice to render a menu client-side instead of server-side: all of it lands in the field data eventually. Understanding what constrained design systems like GOV.UK get right is partly an object lesson in how limiting your component palette keeps your bundle lean and your users happy.
Frequently Asked Questions
What are UK Core Web Vitals and why do they matter for my site?
Core Web Vitals are three metrics Google uses to measure real-world user experience: LCP (loading), INP (interactivity), and CLS (visual stability). They matter because Google uses them as a ranking signal, and poor scores directly correlate with higher bounce rates and lower conversion rates on UK e-commerce and SaaS sites.
How do I check my site's Core Web Vitals field data for UK users specifically?
Use the PageSpeed Insights API or query the Chrome UX Report (CrUX) via Google BigQuery to get 28-day rolling field data. Run Webpagetest.org tests using a London or Manchester server node to simulate realistic UK network conditions rather than US-based test servers.
What is INP and why is it harder to fix than LCP?
INP (Interaction to Next Paint) measures how quickly a page responds to user input across the entire session, not just at load. It’s harder to fix than LCP because it depends on all JavaScript running on the main thread throughout the user’s visit, including third-party scripts, event handlers, and framework re-renders.
How much can improving Core Web Vitals actually improve conversion rates?
Research consistently shows a 4-5% drop in conversions per additional second of load time. Fixing LCP and INP on a UK SaaS product or retail site can shift conversion rates by 1-2 percentage points, which at meaningful traffic volumes represents significant revenue. Google’s own case studies document similar improvements across e-commerce clients.
Leave a Reply