Most Developers Optimise Core Web Vitals for the Wrong Metric
After more than 100 Core Web Vitals optimisation projects and direct certification from Google, I can confidently state: 90% of developers who “optimise” CWV do it incorrectly. Not because they are bad programmers — but because they don't understand how Google truly measures user experience.
At ZDS Digital, our experience since 2018, and especially with the Core Web Vitals changes in 2024, has shown us that the key lies in a deep understanding of the interaction between technical performance and user perception. What was an emerging trend in 2018 is now an unavoidable standard for SEO and user retention. Ignoring these principles not only affects ranking but also conversion rates and brand image.
Mistake #1: Optimising for Lighthouse Instead of Real Users
The most common mistake. A developer opens Lighthouse, sees a score of 60, makes changes until it reaches 90, and declares victory. Problem: Lighthouse shows lab data. Google uses field data (CrUX — Chrome User Experience Report) for ranking.
The difference? Lighthouse simulates a 4G connection on a mid-range device. Your real users might be on an iPhone 15 with fibre optic or a 4-year-old Android with 3G. Field data captures this diversity — Lighthouse does not.
What to do: Set up CWV tracking with real field data. Google's web-vitals library, sent to Google Analytics 4 or a Looker Studio dashboard, gives you the real picture. It is crucial to understand that CrUX data is the decisive factor for Google. A 2023 Ahrefs study revealed that, although there is a correlation between Lighthouse and CrUX, many sites with high Lighthouse scores still failed in CrUX due to real-world variability. In our experience, a RUM (Real User Monitoring) approach is indispensable for obtaining actionable and accurate metrics.
The Importance of GA4 for CWV Tracking
With the complete transition to Google Analytics 4 (GA4) in 2023, the way Core Web Vitals data is collected and analysed has evolved. Unlike Universal Analytics, GA4 is designed for event-based tracking, making it ideal for capturing detailed performance metrics. Configuring custom events for LCP, INP, and CLS through Google's web-vitals library allows for unprecedented granularity. For example, we can segment data by device type, geographical location, or even user connection speed, revealing patterns that Lighthouse could never identify. This is fundamental for meeting Google's “Helpful Content” and E-E-A-T requirements, as a fast, functional site is inherently more useful and trustworthy.
Mistake #2: Not Understanding INP
Since March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital. And the difference is stark:
- FID only measured the first input and only the delay (time until the browser starts processing). Most sites passed easily.
- INP measures all interactions throughout the entire session and the complete time (delay + processing + visual presentation). It is much more demanding.
Result: sites that had an FID of 50ms (excellent) can have an INP of 500ms (poor). Many developers haven't even noticed the change.
The complexity of INP lies in its holistic nature. It considers not just the first click, but every user interaction: clicks, taps, drags, etc., throughout the page's lifecycle. This means that a site with heavy JavaScript or a complex DOM can have poor INP, even if it loads quickly. The key to optimising INP is to identify and reduce “Long Tasks” (JavaScript tasks that take longer than 50ms to execute) and ensure the main thread is free to respond to user interactions. Tools like Chrome DevTools with its “Performance panel” are essential for debugging and visualising these tasks. At ZDS, we have seen how INP optimisation can significantly improve user perception, especially on e-commerce sites where every micro-interaction counts towards conversion.
Mistake #3: Aggressive Lazy Loading That Kills LCP
Lazy loading is an important optimisation. But when you apply loading="lazy" to all images — including the hero image or the LCP element — you are telling the browser not to load your most important content until it is visible. Result: LCP skyrockets.
Rule: Above-the-fold images (especially the LCP element) should have loading="eager" and fetchpriority="high". Only below-the-fold images should be lazy.
Largest Contentful Paint (LCP) is the metric that measures when the main content of a page has loaded and is visible to the user. A high LCP translates to a poor experience. In addition to proper lazy loading management, other crucial techniques for optimising LCP include image compression (using modern formats like WebP or AVIF), using a CDN (Content Delivery Network) to serve assets closer to the user, and preloading critical resources (<link rel="preload">). A 2024 Google study showed that every 100ms improvement in LCP can increase conversion rates by up to 1%. This is an area where small improvements can have a big impact.
Mistake #4: Render-Blocking Fonts
Loading Google Fonts with a simple link tag blocks rendering. The browser waits to download the font CSS before painting anything. Solution: self-hosting with font-display: swap and preloading critical woff2 files.
The impact of fonts on performance is often underestimated. When fonts are not loaded optimally, they can cause “Flash of Unstyled Text” (FOUT) or “Flash of Invisible Text” (FOIT), both detrimental to user experience. The font-display: swap technique allows the browser to display fallback text while the custom font loads, improving the perception of speed. Furthermore, preloading the most critical fonts (e.g., .woff2 files for headings and body text) ensures they are available as soon as possible. At ZDS, we have implemented self-hosting solutions for clients with strict privacy requirements, which also contributes to greater speed by eliminating external dependencies and reducing DNS lookup times.
Mistake #5: Main-Thread Blocking JavaScript
Tag managers, analytics, chat widgets, A/B testing tools — all execute JavaScript on the main thread. Each script competes for CPU time. When a user clicks, the browser cannot respond until it finishes executing the current JS. Result: high INP.
Solutions:
- Defer all non-critical scripts
- Use
requestIdleCallbackfor non-urgent tasks - Implement a tag manager that loads scripts conditionally
- Measure the Long Task budget of each third-party script
JavaScript is one of the main causes of poor performance, especially for INP. JavaScript optimisation goes beyond simply deferring scripts. It involves techniques such as “code splitting” (dividing code into smaller chunks that load on demand), virtualising long lists to avoid rendering off-screen elements, and eliminating unused code (“tree-shaking”). A 2024 Akamai study revealed that 47% of users expect a page to load in 2 seconds or less, and inefficient JavaScript is a common obstacle to achieving this. At ZDS, we use tools like WebPageTest and the Chrome DevTools performance panel to identify exactly which scripts are causing bottlenecks and how to refactor them for more efficient execution.
The Impact of Third-Party Scripts and Privacy
In the Privacy-first era, managing third-party scripts has become even more complex. They not only affect performance but can also introduce security and regulatory compliance risks (GDPR, CCPA). A well-configured “Consent Management Platform” (CMP) not only manages user consent but can also defer the loading of analytics or marketing scripts until permission is granted. This, in addition to being a legal requirement, contributes to better initial page performance. Evaluating the “Long Task budget” of each third-party script is essential; if a script from an external provider consumes too much main thread time, it is a candidate for optimisation, replacement, or more intelligent loading.
How We Optimise CWV
- Diagnosis with real data: No Lighthouse — we configure RUM (Real User Monitoring) with Google's web-vitals library. This allows us to gain a precise view of user experience across different devices and network conditions, which is fundamental for a “Privacy-first” approach and for understanding the real impact of Google's “Helpful Content Update.”
- Bottleneck identification: Is it LCP? INP? CLS? Each metric requires a different approach. We use advanced performance analysis tools, such as SpeedCurve or New Relic, integrated with our GA4 dashboards to correlate technical metrics with user behaviour and business objectives.
- Quick wins first: Images, fonts, caching — changes that improve metrics in days. This includes implementing CDNs, optimising CSS and JavaScript delivery, and configuring robust cache policies to reduce load times for recurring pages.
- Deep optimisation: JS splitting, SSR, edge rendering — changes that require development. For complex sites, we explore modern architectures such as Server-Side Rendering (SSR) or Static Site Generation (SSG) to deliver pre-rendered HTML, drastically improving LCP and FCP. Edge computing through services like Cloudflare Workers or Vercel Edge Functions also offers opportunities to reduce global latency.
- Continuous monitoring: Looker Studio dashboard with regression alerts. A custom dashboard in Looker Studio (formerly Google Data Studio) allows us to visualise CWV trends over time, segment by audience and device, and set up automatic alerts to detect any performance regression. This is vital in an SEO environment where Core Web Vitals are a continuous ranking factor and where Google's “Helpful Content Updates” aim to reward consistent quality.
Is your PageSpeed not improving no matter how hard you try? At ZDS, we have Google certification and over 100 CWV projects optimised. Request a technical audit.
Beyond Metrics: The E-E-A-T Philosophy and AI Search
In the context of 2026, Core Web Vitals optimisation is not just a technical issue but an integral part of a global SEO strategy, especially concerning Google's E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) concept. A fast, responsive, and friction-free website directly contributes to user “Experience.” If a site is slow, difficult to use, or has interaction problems (INP), the perception of its trustworthiness and authority decreases, regardless of the quality of its content.
Furthermore, the emergence of conversational AI-based search, such as ChatGPT or Perplexity, means that user experience extends beyond traditional clicks. AI models evaluate the quality and usefulness of sources to generate responses. A site that performs well in Core Web Vitals is more likely to be crawled efficiently, its content is more accessible, and therefore, it is more likely to be considered a high-quality information source by these systems. At ZDS, we integrate CWV optimisation as a fundamental pillar to prepare our clients for the future of search, where speed and experience are synonymous with credibility.
Success Stories and Recommended Tools (2026)
We have worked with clients in the e-commerce sector, such as a fashion store that managed to reduce its LCP by 35% and improve its INP by 20% after implementing our recommendations. This translated into a 15% increase in mobile conversions in one quarter. To achieve this, we used a combination of tools:
- Google Search Console: For tracking CrUX metrics and identifying problematic URLs.
- Chrome DevTools: For detailed in-browser performance analysis, including the “Performance” and “Lighthouse” panels.
- WebPageTest: For load simulations in different locations and network conditions, offering a deep insight into load times and resource waterfalls.
- SpeedCurve/New Relic: Advanced RUM platforms for continuous monitoring and proactive alerts.
- Cloudinary/Imgix: Image optimisation and delivery solutions that automate compression and adaptive formatting.
- Webpack/Rollup: For JavaScript and CSS optimisation, including code splitting, tree-shaking, and minification.
The implementation of these tools and strategies, combined with our experience, allows ZDS Digital not only to solve current Core Web Vitals problems but also to build a solid foundation for future growth and adaptability to the constant evolutions of Google's algorithm and search technologies.
