The Continued Importance of Core Web Vitals
Since Google incorporated Core Web Vitals into its ranking signals, web performance has rightly received increased attention from businesses and developers alike. In 2025, these metrics remain a significant factor in both search engine rankings and user experience, and the standards for what constitutes acceptable performance continue to rise as user expectations grow and competitors improve their sites.
Understanding, measuring, and optimising Core Web Vitals is no longer optional for any business that relies on organic search traffic, values user engagement, or cares about conversion rates. Performance is not a technical nicety — it is a business-critical factor that directly affects revenue and customer satisfaction.
The Current Metrics Explained
As of 2025, the Core Web Vitals consist of three key metrics, each measuring a distinct aspect of the user experience.
Largest Contentful Paint (LCP)
LCP measures the time taken for the largest visible content element to render on screen. This is typically a hero image, a prominent heading, or a large block of text — whatever the browser identifies as the largest element in the viewport. The target is to achieve LCP under 2.5 seconds for at least 75 per cent of page loads.
LCP reflects the perceived loading speed of the page. Users do not care about technical metrics like time to first byte in isolation; they care about when they can see the content they came for. LCP captures this perception directly.
Interaction to Next Paint (INP)
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it represents a significantly more demanding measure of interactivity. Whereas FID measured only the delay of the first user interaction, INP considers all user interactions throughout the page's entire lifecycle — every click, tap, and keyboard input — and reports the worst latency experienced (with certain statistical adjustments).
The target for INP is under 200 milliseconds. Meeting this target requires that the page remains responsive not just on initial load but throughout the user's entire session, including after dynamic content has been loaded, third-party scripts have executed, and the page has been in use for an extended period.
Cumulative Layout Shift (CLS)
CLS measures the visual stability of the page by quantifying unexpected layout shifts that occur during loading and interaction. The target score is under 0.1. Layout shifts frustrate users, particularly on mobile devices where they cause misclicks — a user reaches to tap a button, the layout shifts, and they tap an advertisement or a different link instead.
CLS is calculated by multiplying the impact fraction (the proportion of the viewport affected by the shift) by the distance fraction (the distance elements moved relative to the viewport). Multiple small shifts can accumulate into a poor CLS score even if no single shift seems significant.
Optimising Largest Contentful Paint
LCP is most commonly affected by slow server response times, render-blocking resources, large unoptimised images, and client-side rendering delays. A systematic approach to optimisation addresses each of these factors.
Server Response Time
Everything starts with the server. Time to First Byte (TTFB) is a foundational metric that affects all downstream performance. If the server takes two seconds to respond, achieving an LCP under 2.5 seconds for any meaningful content is essentially impossible. Ensure your hosting infrastructure is performant, your server-side code is efficient, and database queries are optimised.
Using a CDN to serve content from edge locations geographically close to your users can dramatically reduce TTFB for visitors who are distant from your origin server. For dynamic content, consider edge computing solutions that execute server-side logic at the CDN edge.
Resource Loading Priorities
Preload your LCP image or resource using the link preload hint so the browser can begin fetching it as early as possible in the page load process, rather than discovering it only after parsing the CSS or JavaScript that references it. The fetchpriority attribute provides additional control over how the browser prioritises competing resource requests.
Image Optimisation
Optimise images aggressively with modern formats such as WebP and AVIF, appropriate sizing for different viewports, and efficient compression settings. An unoptimised hero image is one of the most common causes of poor LCP scores. Consider using the picture element with multiple sources to serve the optimal format for each browser.
Eliminating Render-Blocking Resources
Minimise render-blocking CSS and JavaScript that prevents the browser from rendering content. Inline critical CSS — the styles needed for above-the-fold content — directly in the HTML head, and load the remainder asynchronously. Load JavaScript with the defer or async attribute where possible, and consider removing JavaScript from the critical rendering path entirely for content that does not require it.
Optimising Interaction to Next Paint
INP improvement requires reducing the work the browser must perform in response to user interactions. This is fundamentally about keeping the main thread available and responsive.
Identifying Long Tasks
Long tasks — JavaScript executions that block the main thread for more than 50 milliseconds — are the primary culprit behind poor INP scores. Use browser developer tools and the Long Tasks API to identify which scripts and operations are blocking the main thread, and for how long.
Breaking Up Work
Break long tasks into smaller chunks that yield back to the main thread between each chunk. Techniques for achieving this include:
- Using setTimeout with a zero delay to defer work to the next task
- Using requestIdleCallback for non-urgent work that can wait until the browser is idle
- Using the scheduler.yield API, which is designed specifically for this purpose and provides better prioritisation than setTimeout
- Restructuring code to process data in smaller batches rather than in a single blocking operation
Reducing JavaScript Volume
Reduce the overall volume of JavaScript by removing unused code through tree-shaking and dead code elimination, deferring non-critical scripts until after the page is interactive, using code splitting to load only the JavaScript needed for the current view, and lazy loading heavy components that are not immediately visible.
Managing Third-Party Scripts
Third-party scripts — analytics, advertising, social media widgets, chat tools, and consent management platforms — are a common and often underappreciated source of main thread congestion. Audit your third-party scripts regularly, measure their impact on INP, and consider:
- Lazy loading third-party scripts that are not immediately needed
- Loading scripts with the async or defer attribute
- Replacing heavy third-party embeds with lightweight alternatives or facade patterns
- Removing third-party scripts that do not justify their performance cost
Optimising Cumulative Layout Shift
Layout shifts are prevented primarily by reserving the correct amount of space for content before it loads.
Images and Video
Always include explicit width and height attributes on images and video elements, or use the CSS aspect-ratio property, so the browser can allocate the correct space before the asset downloads. Without these dimensions, the browser reserves no space until the asset loads, causing everything below it to shift.
Dynamic Content Insertion
Avoid inserting content above existing visible content after the page has loaded. This pattern is common with dynamically loaded advertisements, cookie consent banners, notification bars, and promotional messages. Where dynamic content insertion is unavoidable, reserve space for it in advance using minimum height values or container queries.
Font Loading
Web font loading can cause layout shifts when the fallback font and the web font have different metrics, causing text to reflow when the web font loads. Mitigate this by:
- Using font-display swap with preloaded fonts to minimise the flash of unstyled text
- Applying size-adjust, ascent-override, and descent-override in your font-face declarations to match fallback font metrics to the web font as closely as possible
- Considering system font stacks where custom fonts are not essential to the brand
Animations and Transitions
Ensure that animations and transitions use CSS transforms and opacity rather than properties that trigger layout changes. Animating properties such as width, height, top, or left causes the browser to recalculate layout on every frame, which both harms performance and can trigger CLS if the animation occurs during the measurement period.
Measurement and Monitoring
Optimisation must be grounded in real-world data, not just laboratory measurements. The two categories of performance data serve different purposes and both are essential.
Field Data
Field data, collected from real users visiting your site in real conditions, provides the ground truth of your performance. Sources include the Chrome User Experience Report (CrUX), which feeds into Google Search Console and PageSpeed Insights, and real user monitoring (RUM) tools that collect performance metrics from your actual visitors. Field data captures the variability of real-world conditions — different devices, network speeds, geographical locations, and usage patterns — that laboratory tools cannot replicate.
Lab Data
Lab tools such as Lighthouse, WebPageTest, and the Chrome DevTools Performance panel are invaluable for debugging and identifying specific optimisation opportunities. They provide detailed, reproducible measurements in a controlled environment, which makes them ideal for diagnosing problems and verifying fixes. However, they do not capture the full range of conditions your real users experience.
Continuous Monitoring
Performance optimisation is not a one-time activity. New content, feature additions, dependency updates, and third-party script changes can all degrade performance over time. Continuous monitoring with alerting ensures that regressions are detected and addressed before they impact a significant number of users.
At GRDJ Technology, we build performance monitoring into every project from the start, establishing Core Web Vitals targets as part of the project requirements and maintaining them through development, launch, and ongoing operation. Our experience consistently demonstrates that performance optimisation delivers the strongest results when treated as an ongoing discipline integrated into the development process, rather than a periodic remediation exercise.