Skip to content

How to Optimize Core Web Vitals – A Practical Guide

Understand and improve LCP, CLS, and INP: a practical guide with code examples, tools, checklists, and case studies for better rankings.

Mag. Deni Khachukaev

Mag. Deni Khachukaev

Founder & Technical Director

March 7, 202630 min read

With over 13 years of experience in web development and SEO, Deni leads the technical direction of GoldenWing. Specialized in performance optimization, technical SEO, and modern web technologies.

How to Optimize Core Web Vitals – A Practical Guide

Key Takeaways

  • ✓Core Web Vitals consist of three metrics: LCP (loading speed), CLS (visual stability), and INP (interactivity).
  • ✓Achieve LCP under 2.5 seconds through optimized images, server response time, and critical CSS inlining.
  • ✓Keep CLS under 0.1 with fixed image dimensions, font-display swap, and reserved space for dynamic content.
  • ✓Achieve INP under 200ms through code splitting, debouncing event handlers, and using web workers for heavy computation.
  • ✓Google has used CWV as a ranking factor since 2021 — poor scores cost you rankings and conversions.
  • ✓Regular monitoring with PageSpeed Insights, Search Console, and the Web Vitals extension is essential.
  • ✓The most common performance killers: unoptimized images, too many third-party scripts, and render-blocking CSS/JS.
Table of Contents

What are Core Web Vitals?

Core Web VitalsThese are three metrics defined by Google that make the user experience of a website quantifiable. Since 2021, they have officially been included in Google's ranking algorithm and are therefore no longer just a nice-to-have, but a business-critical factor.

The three metrics at a glance:

MetricMeasuresGoodNeeds ImprovementBad
LCP (Largest Contentful Paint)Loading speed≤ 2.5s2.5-4.0s> 4.0s
CLS (Cumulative Layout Shift)Visual Stability≤ 0.10.1-0.25> 0.25
INP (Interaction to Next Paint)Interactivity≤ 200ms200-500ms> 500ms

Important:All three metrics must reach the "good" threshold for Google to classify your site as performing well. It's not enough for only one or two to be green. Test your website now with our tool.Performance Checkerand see where you stand.

How are CWV measured?

Google distinguishes betweenField data(real users) andLab data(simulated):

  • Field dataThese results come from the Chrome UX Report (CrUX) and are based on anonymized data from real Chrome users. Google uses this data for ranking purposes.
  • Lab dataThey are measured by tools like Lighthouse, PageSpeed Insights, or WebPageTest in a controlled environment. They are ideal for diagnosis and optimization.

The key difference: Field data shows how your website actually performs; lab data shows how it performs under ideal conditions. Optimize for lab data, but measure success against field data.

How Google uses CWV for rankings

Google announced in May 2021 thePage ExperienceIntroduced as a ranking signal, with Core Web Vitals forming the central component. Here's what that means in concrete terms:

What we know:

  • CWV is a ranking factor, butnot the most importantRelevant content, backlinks, and domain authority carry more weight.
  • For otherwise identical pages, CWV can make all the difference — especially on the first page of search results.
  • Google uses the 75th percentile of the field data: If 75% of your users experience good results, the page is considered to pass.
  • CWV willper URLThe data is evaluated, not per domain. Individual slow pages do not affect the entire website.

The business impact:

  • According to Google studies, websites with good CWV have a24% lower bounce rate
  • E-commerce sites report ofup to 15% higher conversion ratesafter CWV optimization
  • News websites are recordingUp to 22% more page views per session

In our work asWeb design agencyAfter CWV optimization, we have observed ranking improvements of an average of 3-8 positions for competitive keywords for our clients — not only due to the CWV itself, but also due to the associated improved user experience and lower bounce rates.

Optimize LCP: Improve charging speed

Free Consultation

Let's talk about your project. No strings attached.

Book a Call

The Largest Contentful PaintMeasures when the largest visible element in the viewport has finished loading — typically a hero image, a video, or a large block of text. Goal:under 2.5 seconds.

The most common LCP problems and solutions

1. Unoptimized images (most common problem)

The hero image is the LCP element in 70% of cases. If it's 2 MB in size and only loads after CSS and JavaScript have been processed, a good LCP value is impossible.

Solution:













2. Slow server response time (TTFB)

If the server takes more than 800ms to deliver the HTML file, all subsequent resources will start late.

Solution:

  • Switch to better hosting (Managed VPS instead of Shared Hosting)
  • Setting up a CDN (Cloudflare, Fastly, AWS CloudFront)
  • Enable server-side caching (Varnish, Redis, Nginx Microcaching)
  • Optimize database queries (indexes, query caching)

3. Render-blocking CSS and JavaScript

CSS and synchronous JavaScript in the `<head>` block the rendering of the page.

Solution:














4. Third-party scripts cause delays

Analytics, chat widgets, social media embeds and advertising can significantly worsen the LCP.

Solution:Load third-party scripts only after the LCP event:












Optimize CLS: Prevent layout shifts

The Cumulative Layout ShiftIt measures how much elements unexpectedly shift during the loading process. Everyone's experienced it: you want to click a button, and at the last moment it jumps away because an ad banner pops up. Goal:below 0.1.

The most common causes of CLS

1. Images and videos without dimensions

If the browser doesn't know the size of an image, it doesn't reserve any space. As soon as the image loads, all the content below it shifts.

Solution:








2. Web fonts cause FOUT/FOIT

When a web font is loaded, the text may suddenly change size (Flash of Unstyled Text) or briefly disappear (Flash of Invisible Text).

Solution:











Additionally: Preload font files:


3. Dynamically inserted content

Cookie banners, newsletter popups, and lazy-loaded elements can cause layout shifts if no space is reserved for them.

Solution:













4. Dynamic advertising without container size

Solution:Use fixed container sizes for ad impressions:





Optimize INP: Accelerate interactivity

Interaction to Next Paint (INP)INP officially replaced FID (First Input Delay) as a Core Web Vital in March 2024. INP measures the response time toallUser interactions (clicks, taps, keystrokes) throughout the entire page visit — not just the initial one. Goal:under 200ms.

Why INP is more demanding than FID

FID only measured the delay in thefirstInteraction. INP considerseveryInteraction is measured and the worst value is used (more precisely: the 98th percentile). This means that even if your page responds quickly to the first click, but takes 500ms to load on the tenth click, INP will be rated poorly.

INP optimization strategies

1. Identify and break up long tasks

JavaScript tasks that last longer than 50ms block the main thread and delay interactions.

Solution using `requestIdleCallback` and task splitting:



















2. Optimize event handlers

Expensive calculations in event handlers (scroll, input, resize) should be debounced or throttled.













3. Code splitting and dynamic imports

Only download the code that is actually needed:









4. Web Workers for intensive computing












Tools for measuring Core Web Vitals

The right tools are crucial for successful optimization. Here are our tool recommendations:

ToolTypeFreeBest for
PageSpeed InsightsLab + FieldYesSingle-page analysis
Google Search ConsoleFieldYesWebsite-wide overview
Chrome DevToolsLabYesDebugging and Analysis
Web Vitals ExtensionLabYesReal-time monitoring in the browser
WebPageTestLabYes (Basic)Detailed Waterfall Analysis
Lighthouse CILabYesAutomated CI/CD checks
SpeedCurveLab + FieldNo (from $12/month)Long-term monitoring
CalibreLab + FieldNo (from $45/month)Team Performance Tracking
GoldenWing Performance CheckerLabYesQuick Analysis

Recommended workflow:

  1. Overview:Google Search Console → Check CWV report
  2. Analysis:PageSpeed Insights for the most important pages
  3. Debugging:Chrome DevTools → Performance tab → Identify bottlenecks
  4. Monitoring:Web Vitals Extension for daily work
  5. Automation:Integrate Lighthouse CI into the build pipeline

Core Web Vitals Checklist

Here is your comprehensive checklist, sorted by priority:

LCP checklist

  • [ ] Hero image compressed in WebP/AVIF (under 200KB)
  • [ ] Hero image with `fetchpriority="high"` and preload hint
  • [ ] TTFB under 800ms (good hosting + CDN)
  • [ ] Critical CSS inline in `<head>`
  • [ ] Render-blocking JavaScript eliminated (`defer`/`async`)
  • [ ] Third-party scripts loaded after LCP
  • [ ] Font preloading for headline fonts
  • [ ] No lazy loading for above-the-fold images

CLS checklist

  • [ ] All images have `width` and `height` attributes
  • [ ] `font-display: swap` for all web fonts
  • [ ] Font metrics override (`size-adjust`, `ascent-override`)
  • [ ] Fixed container sizes for ads and embeds
  • [ ] Cookie banner as overlay (not push element)
  • [ ] No dynamically inserted content without placeholders
  • [ ] CSS `aspect-ratio` for responsive containers
  • [ ] No late DOM manipulations in the visible area

INP checklist

  • [ ] No long tasks longer than 50ms in the main thread
  • [ ] Event handler debounced (search, scroll, resize)
  • [ ] Code splitting for non-critical modules
  • [ ] `requestAnimationFrame` for visual updates
  • [ ] Web workers for intensive computing
  • [ ] Minimum bundle size (tree shaking, dead code elimination)
  • [ ] Third-party scripts asynchronous or deferred
  • [ ] No synchronous XHR requests

WordPress-specific optimizations

WordPress websites have specific performance challenges. Here are the most effective optimizations:

1. Conduct a plugin audit

The biggest performance problem with WordPress: too many plugins. Each plugin adds CSS, JavaScript, and database queries.

Recommended procedure:

  • Deactivate all plugins and measure the baseline performance.
  • Activate plugins individually and measure the impact.
  • Remove anything with a usage rate below 1%.
  • Replace heavy plugins with lightweight alternatives.

Plugin recommendations for performance:

PurposeRecommendedAvoid
CachingWP Rocket, LiteSpeed CacheW3 Total Cache (complex)
Image optimizationShortPixel, ImagifySmush Free (limited)
CSS/JS optimizationPerfmatters, Asset CleanUpAutoptimize (can cause conflicts)
DatabaseWP-Optimize—
Lazy loadingNative (from WP 5.5)jQuery-based plugins

2. Theme optimization

Many WordPress themes load hundreds of kilobytes of unused CSS and JavaScript. Page builders like Elementor or Divi are particularly resource-intensive.

Optimization approaches:

  • Switch to lightweight themes (GeneratePress, Kadence, Astra)
  • Remove unused CSS (Perfmatters or PurgeCSS)
  • Only use page builders if the customer needs to design the pages themselves.
  • Custom Theme Development for Maximum Performance

3. Server-level optimization

# .htaccess — Enable browser caching <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/webp "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" </IfModule> # GZIP compression <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/css AddOutputFilterByType DEFLATE application/javascript application/json </IfModule>

Next.js-specific optimizations

For projects that we use with Next.js andPayload CMSDifferent optimization strategies apply for implementation:

1. Image optimization with next/image












2. Font optimization with next/font







3. Route-based code splitting

Next.js automatically splits the code per route. Additionally:







4. Server Components (App Router)












5. Metadata and Streaming













Case studies from our practice

Case Study 1: Corporate Website (Next.js + Payload CMS)

Initial situation:

  • PageSpeed Mobile: 52/100
  • LCP: 4.1s (unoptimized PNG Hero, 3.2 MB)
  • CLS: 0.22 (Fonts without swap, images without dimensions)
  • INP: 310ms (heavy animation library)

Measures:

  1. Hero image: PNG → WebP, 3.2 MB → 120 KB, `fetchpriority="high"`
  2. All images with `next/image` and fixed dimensions
  3. Font optimization with `next/font` (self-hosted, `swap`)
  4. Framer Motion replaced by CSS transitions (Bundle -180KB)
  5. Third-party scripts delayed after LCP

Result:

  • PageSpeed Mobile:96/100(+44 points)
  • LCP:1.3s(-68%)
  • CLS:0.01(-95%)
  • INP:85ms(-73%)
  • Bounce Rate:-35%, Conversion Rate:+22%

Case Study 2: Ecommerce Store (WordPress + WooCommerce)

Initial situation:

  • PageSpeed Mobile: 38/100
  • LCP: 5.8s (slider with 5 uncompressed JPEGs)
  • CLS: 0.31 (product images without dimensions, reloading reviews)
  • INP: 420ms (jQuery + 15 active plugins)

Measures:

  1. Slider replaced by static hero image
  2. ShortPixel for automatic image compression (WebP)
  3. Plugin audit: 15 → 8 plugins (7 unnecessary ones removed)
  4. WP Rocket installed (caching, CSS/JS minification, lazy loading)
  5. Switching from Shared to Managed VPS hosting
  6. All product images have fixed dimensions.

Result:

  • PageSpeed Mobile:88/100(+50 points)
  • LCP:1.9s(-67%)
  • CLS:0.04(-87%)
  • INP:145ms(-65%)
  • Sales volume: +18%in the first month after optimization

Case Study 3: Local Service Company (WordPress)

Initial situation:

  • PageSpeed Mobile: 44/100
  • LCP: 4.5s (unoptimized Hero JPEG, 2.1 MB)
  • CLS: 0.28 (images without dimensions, dynamic cookie banner)
  • INP: 190ms

Measures:

  1. Hero image: JPEG → WebP, 2.1 MB → 95 KB, fetchpriority="high"
  2. All images have width/height attributes.
  3. Cookie banner position changed to: fixed
  4. WP Rocket + ShortPixel installed
  5. Unused CSS removed (Perfmatters)

Result:

  • PageSpeed Mobile:92/100(+48 points)
  • LCP:1.6s(-64%)
  • CLS:0.03(-89%)
  • INP:95ms(-50%)
  • Google ranking for main keyword:Page 3 → Page 1(Position 7)

Common mistakes in CWV optimization

Based on our experience with over 120 projects, we see the same mistakes time and again:

1. Optimize only lab data, ignore field data

Lab data (Lighthouse) shows the potential, but Google ranks based on field data (CrUX). A website can have a perfect score of 100/100 in Lighthouse and still have poor field data if real users are accessing the site on slow devices or with poor internet connections.

2. Lazy-load all images

Lazy loading is great — but not for above-the-fold images. Adding `loading="lazy"` to the hero image dramatically worsens the LCP score because the browser only loads the image when it's in the viewport.

3. Loading too many fonts

Each font file adds to the loading time and can cause CLS (Close Load Sensing). Limit yourself to 2-3 font variations (Regular, Bold, and possibly Italic) and only load the necessary character sets (Latin instead of Latin-Extended).

4. Stack performance plugins

Using three caching plugins simultaneously doesn't improve the situation; it makes it worse. Conflicts between plugins are the most common cause of unexplained performance problems. One good caching plugin (e.g., WP Rocket) is sufficient.

5. Ignore third-party scripts

Google Analytics, Facebook Pixel, Hotjar, Intercom, Drift — every additional script impacts performance. Ask yourself for each script: Do I really need this? And if so: Can I delay loading it?

6. Optimize only the homepage

Google evaluates each URL individually. Product pages, blog articles, and the contact page must be optimized just as much as the homepage. Check the CWV report for all page groups in the Search Console.

Set up performance monitoring

CWV optimization is not a one-time project. New features, content changes, and third-party updates can degrade performance at any time. Here's how to set up continuous monitoring:

1. Google Search Console (free)

  • Open the "Core Web Vitals" report under "Enhancements"
  • Check the number of URLs with a "poor" or "needs improvement" status monthly.
  • Set alerts for deterioration

2. Real User Monitoring (RUM)



















3. Lighthouse CI in the build pipeline

# .github/workflows/lighthouse.yml name: Lighthouse CI on: [push] jobs: lighthouse: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: treosh/lighthouse-ci-action@v11 with: urls: | https://example.com/ https://example.com/blog/ budgetPath: ./budget.json temporaryPublicStorage: true

4. Define performance budgets












Third-party scripts and their impact on Core Web Vitals

Third-party scripts are one of thebiggest performance killermodern websites. According to the HTTP Archive, websites load an average of21 Third-Party ResourcesFrom analytics and chatbots to advertising pixels, these external scripts can severely degrade your Core Web Vitals.

Which third-party scripts cause the biggest problems

High impact on LCP and INP:

  • Chat widgets(e.g., Intercom, Zendesk Chat): Often load 200-500 KB of JavaScript and block the main thread.
  • Social Media Embeds(Facebook, Instagram, Twitter): A single Facebook embed can1-3 MBLoad additional resources
  • Video embeds(YouTube, Vimeo): A YouTube iframe loads without optimization600 KB - 1.5 MB

Moderate impact:

  • Analytics tools(Google Analytics, Hotjar, Matomo): Typically 50-150 KB, but tracking pixels can add up.
  • Cookie consent banner(Cookiebot, Usercentrics): 30-100 KB, but often render-blocking
  • Font Services(Google Fonts, Adobe Fonts): 50–200 KB per font family

Low impact when properly integrated:

  • Tag Manager(Google Tag Manager): Approximately 80 KB, but container size grows daily.
  • Conversion pixel(Google Ads, Meta Pixel): Small individually, but cumulative effect.

Optimization strategies

1. Lazy loading for third-party scripts

Only load chat widgets, social media embeds, and other non-critical scripts when the user needs them:

  • Chat widget only afterScroll or after 5 seconds load
  • Social media embeds asfacade(Implement static image with click-to-load)
  • YouTube videos with thelite-youtube-embedEmbedding patterns saves up to 500 KB per video.

2. Script Prioritization

Use the correct loading attributes:

  • async:The script is loaded in parallel and executed immediately (for analytics).
  • defer:The script is loaded in parallel, but only executed after HTML parsing (for most scripts).
  • No attribute:Script is blocking rendering -- avoid this at all costs

3. Self-hosting instead of CDN integration

Host frequently used third-party resources yourself:

  • Google Fonts:Download the WOFF2 files and host them on your server. This saves a DNS lookup and an additional connection.
  • Analytics scripts:With self-hosted Matomo, the third-party request is completely eliminated.

4. Regular audit

Introduce quarterlyThird-party auditthrough. Remove scripts that are no longer needed. In practice, we find at70% of all auditsat least one script that no longer offers any added value.

Measuring Third-Party Impact

Use the following tools to measure the impact of individual scripts:

  • Chrome DevTools > Performance Tab:Shows which scripts are blocking the main thread.
  • WebPageTest > "Block" Tab:Test the loading time with and without specific third-party domains.
  • Lighthouse > Treemap:Visualizes JavaScript size by script origin

Server-side optimizations: Hosting, CDN and caching

The best frontend optimization is of little use if the server responds slowly.Time to First Byte (TTFB)should under800 millisecondsIdeally, the TTFB (Time To First By) should be below 200 ms. In Austria, we see many SME websites with TTFB values of over 1.5 seconds.

Hosting optimization

Shared hosting – the most common problem

Above 60% of Austrian SME websitesThey run on shared hosting. This means that hundreds of websites share a single server. During peak times, the TTFB (time to first load) increases dramatically.

Recommendations by website type:

  • Static/JAMstack websites: Edge hosting (Vercel, Netlify, Cloudflare Pages) -- TTFB under 50ms worldwide
  • WordPress websites: Managed WordPress Hosting (Raidboxes, Cloudways) -- TTFB 100--300 ms
  • PHP applications:VPS with OPcache, PHP 8.2+ and FastCGI -- TTFB 150-400 ms
  • Node.js applications: Container hosting (Railway, Fly.io) or VPS with PM2

Configure CDN correctly

A Content Delivery NetworkDistributes static content across servers worldwide. For Austrian websites targeting the DACH region (Germany, Austria, Switzerland), a CDN is recommended.Edge nodes in Frankfurt, Vienna and Zurichoptimal.

CDN configuration best practices:

  • Static AssetsDeliver (CSS, JS, images, fonts) via the CDN.
  • HTML pagesOnly cache if they rarely change (e.g., landing pages).
  • Cache Control HeaderCorrectly set: 'public, max-age=31536000, immutable' for versioned assets
  • Brotli compressionactivate -- 15-25% smaller than Gzip

Server-side caching

Page Caching:

Generate HTML pages once and deliver the cached version. For WordPress, plugins like WP Super Cache or W3 Total Cache are suitable. For Next.js, use...Incremental Static Regeneration (ISR).

Object caching with Redis:

Redis stores frequently queried database results in memory. Improving the TTFB (Time To First By) can50-80%The cost is significant. For WordPress, Redis Object Cache is a game-changer, especially for WooCommerce shops.

OPcache for PHP:

Enable OPcache with sufficient memory (at least 128 MB). OPcache compiles PHP files once and stores the bytecode. The performance improvement is [value missing in original text].200-400%for PHP-based websites.

HTTP/2 and HTTP/3

Make sure your serverHTTP/2or ideallyHTTP/3 (QUIC) supports:

  • HTTP/2:Multiplexing enables the parallel loading of multiple resources over one connection
  • HTTP/3:Based on UDP instead of TCP, it reduces latency under poor network conditions by30-50%
  • Most modern hosting providers and CDNs have supported HTTP/3 since 2024.

Core Web Vitals for E-Commerce Websites

E-commerce websites face particular challenges regarding the Core Web Vitals.Product images, filter systems, dynamic price displays and checkout processesThis makes optimization complex -- but all the more worthwhile.

LCP optimization for product pages

The largest visible element on product pages is typically theMain product imageOptimize it specifically:

  • Preload image with '<link rel="preload" as="image">' in the HTML head
  • Use placeholders: Low-Quality Image Placeholder (LQIP) or blur-up technique
  • Limit image size:The main image should be a maximum size of...150 KBbe large (WebP, quality 80)
  • No lazy loadingFor the main product image -- it must load immediately

CLS problems at shops

The most common causes of CLS in e-commerce:

  • Price displays that reload:Personalized prices or sale labels inserted via JavaScript
  • Product rating stars:If the rating widget loads asynchronously and shifts the content
  • Banners and action instructions:"Free shipping on orders over €50" banners that appear after the page loads.
  • Product recommendations:"Customers also bought" carousels that take up space

Solutions:

  • Reserve fixed placeholders (min-height/aspect-ratio) for all dynamic elements.
  • Download pricing informationserver-side instead of using client-side JavaScript
  • Setwidth and height attributesall product images

Product filters and search functions are interactive -- and this is exactly where the INP value becomes apparent:

  • DebouncingFor search queries: Please wait300 msafter the last keystroke before the search is triggered
  • Virtual scrolling listsfor categories with hundreds of products
  • Web Workerfor complex filter calculations to offload the main thread
  • Optimistic UI:Display filter results instantly and update in the background.

Checkout performance

The checkout process is themost critical momentFor e-commerce -- every second of delay can increase the abandonment rate by7% increase:

  • Payment scripts(Stripe, PayPal, Klarna) only load on the checkout page, not on all pages.
  • FormsUsing minimal JavaScript: Use native HTML validation instead of heavy libraries
  • Address autocompletesaves the user time and reduces the waiting time for the next interaction.

Industry-specific benchmarks for Austria

The following CWV benchmarks are considered excellent for e-commerce websites in the DACH region:

  • LCP:Under 2.0 seconds (industry average: 3.8 seconds)
  • INP:Under 150 ms (industry average: 280 ms)
  • CLS:Below 0.05 (industry average: 0.15)

Shops that have all three values in the green zone report...12-25% higher conversion ratescompared to the industry average.

Page speed optimization in practice: Before-and-after analysis

Theory is important, but nothing is more convincing thanreal resultsHere we present three anonymized case studies from our agency's daily work, featuring concrete measures and measurable improvements.

Case study 1: Craft business from Vienna

Initial situation:

  • WordPress website with 35 pages, shared hosting
  • LCP: 6.2 seconds | CLS: 0.28 | INP: 420ms
  • PageSpeed Score: 28/100 (Mobile)

Measures taken:

  • Switching to Managed WordPress (Raidboxes)
  • Image conversion to WebP, lazy loading implemented
  • 8 unused plugins deactivated and removed
  • Critical CSS generated, JavaScript execution delayed
  • Google Fonts hosted locally, reduced to 2 font weights

Result after 4 weeks:

  • LCP: 1.8 seconds (71% improved) | CLS: 0.02 | INP: 95 ms
  • PageSpeed Score: 92/100 (Mobile)
  • Organic traffic:+34%after 3 months

Case study 2: Online shop for sportswear (Austria)

Initial situation:

  • WooCommerce with 1,200 products, VPS hosting
  • LCP: 4.8 seconds | CLS: 0.22 | INP: 380ms
  • PageSpeed Score: 35/100 (Mobile)

Measures taken:

  • Redis Object Cache installed and configured
  • Product images automatically converted to WebP (short pixels)
  • Slider on the homepage replaced by a static hero image
  • WooCommerce cart fragments disabled on non-shop pages
  • Cloudflare CDN with Brotli compression enabled
  • Checkout on a separate subdomain with minimal CSS/JS load

Result after 6 weeks:

  • LCP: 2.1 seconds (56% improved) | CLS: 0.04 | INP: 140 ms
  • PageSpeed Score: 78/100 (Mobile)
  • Conversion rate:+18%Shopping cart abandonment rate:-12%

Case Study 3: SaaS Landing Page (Next.js)

Initial situation:

  • Next.js 14 on Vercel, 8 Landing Pages
  • LCP: 3.1 seconds | CLS: 0.08 | INP: 250ms
  • PageSpeed Score: 62/100 (Mobile)

Measures taken:

  • Hero image optimized with next/image and priority attributes
  • Intercom chat widget with Intersection Observer lazy loaded
  • Animation library (Framer Motion) replaced by CSS transitions (saving: 120 KB)
  • Bundle analysis using @next/bundle-analyzer, unused code removed
  • Font display: swap and font subsetting for the font used.

Result after 2 weeks:

  • LCP: 1.4 seconds (55% improved) | CLS: 0.01 | INP: 85 ms
  • PageSpeed Score: 97/100 (Mobile)
  • Demo requests:+22%in the following month

Lessons Learned from all three projects

  • The biggest profitsThey almost always come from images and third-party scripts.
  • Hosting upgradesare often the most cost-effective single measure
  • Less is more:Consistently reduce plugins, font styles, and animations.
  • Measure before and after each measure:How to identify which changes will have the greatest impact

Core Web Vitals and SEO Rankings: The Measurable Impact

Since Google introduced Core Web Vitals as an official ranking factor, many website operators in the DACH region have been asking themselves: How much do LCP, CLS, and INP actually influence search engine rankings? The answer is more nuanced than many expect. Based on current studies and data, we analyze the measurable effects and show you how you can use Core Web Vitals as a strategic competitive advantage.

Correlation between Core Web Vitals and Rankings

Several large-scale studies have examined the relationship between Core Web Vitals and organic rankings.Results are consistent, but not as dramatic as some SEO experts claim:

  • One Study by Searchmetrics(2025, 500,000 URLs in the DACH region) shows: Websites that have all three Core Web Vitals in the green rank on average3.2 positions higherthan comparable websites with poor ratings
  • AhrefsIn 2025, over 33 million pages were analyzed and it was found that only33%The pages in position 1 pass all Core Web Vitals tests — this means that Core Web Vitals alone do not determine the ranking.
  • One HTTP Archive AnalysisFor the German market, the result was: The share of websites with good CWV values has increased from 24% (2022) to 48% (2025) — meaning competition is intensifying.

The key message: Core Web Vitals are aTiebreaker factorAssuming otherwise equal relevance and authority, they determine the ranking. They cannot propel weak content to position 1, but they can make the difference between position 3 and position 7.

Industry-specific benchmarks for the DACH region

The requirements for Core Web Vitals vary considerably depending on the industry. For the Austrian market, the following benchmarks are considered competitive:

E-commerce and online shops:

  • LCP: under 2.0 seconds (industry average DACH: 3.1 seconds)
  • CLS: below 0.05 (industry average: 0.14)
  • INP: below 150ms (industry average: 280ms)
  • The challenge lies in product image optimization and the many third-party scripts (tracking, payment providers, chatbots).

B2B services:

  • LCP: under 1.8 seconds (industry average DACH: 2.4 seconds)
  • CLS: below 0.03 (industry average: 0.08)
  • INP: under 100ms (industry average: 180ms)
  • B2B websites typically have fewer third-party scripts and can therefore more easily achieve good scores.

News portals and content websites:

  • LCP: under 2.5 seconds (industry average DACH: 3.8 seconds)
  • CLS: below 0.08 (industry average: 0.22)
  • INP: below 200ms (industry average: 320ms)
  • The biggest challenge here is the high CLS value due to reloading advertising banners and dynamic content.

ROI calculation: What are the benefits of CWV optimization?

For companies in the DACH region, the question arises whether investing in Core Web Vitals optimization pays off. The answer depends on the business model, but in most cases it is clearly positive.

Direct impact on the conversion rate:

  • Vodafonereported about a31% higher conversion rateafter LCP improvement of 31%
  • Netzsieger.derecorded aOrganic traffic increased by 18%within 3 months
  • Zalandofound that every 100ms improvement in loading time increased revenue per session by0.7%increases

Calculation for a typical Austrian SME:

Let's assume your website has 10,000 organic visitors per month with a conversion rate of 2% and an average order value of €500. CWV optimization that increases the conversion rate by 15% (from 2% to 2.3%) will yield:

  • Additional conversions per month: 30
  • Additional revenue per month: 15,000 euros
  • Additional revenue per year: 180,000 euros

In contrast, there is the one-time investment in CWV optimization, which ranges between €2,000 and €15,000 depending on the complexity of the website.Return on InvestmentThis is usually achieved within 1-3 months.

Monitoring and continuous improvement

Core Web Vitals are not a one-off task, but require ongoing maintenance.continuous monitoringChanges to the content, new plugins, updated third-party scripts, or increased traffic can worsen the values at any time.

Rely on this monitoring strategy:

  • WeeklyAutomated Lighthouse CI tests in the CI/CD pipeline
  • MonthlyCheck CrUX data (Chrome User Experience Report) in Google Search Console
  • QuarterlyComprehensive performance audit with comparison to the competition
  • With every deploymentAutomated performance budgets that stop the build if thresholds are exceeded.

The future of Core Web Vitals: What comes after INP?

Google is continuously developing its Core Web Vitals. Following the switch from FID (First Input Delay) to INP (Interaction to Next Paint) in March 2024, many SEO professionals are asking: Which metrics will be introduced next, and how can you prepare for them today?

The Evolution of Core Web Vitals

Looking at past developments helps to assess the future direction:

  • 2020: Introduction of Core Web Vitals with LCP, FID and CLS
  • 2021Core Web Vitals will become an official ranking factor.
  • 2024FID is being replaced by INP — a significantly more sophisticated interactivity metric.
  • 2025Google introduces improved CLS measurement (layout shift is only counted in certain contexts)
  • 2026+Several new metrics are currently in the testing phase.

The clear trend: Google is moving away fromsimplified metricstowardsmore comprehensive measurements of the actual user experience.

Experimental metrics you should know

Google and the Web Performance Community are working on several new metrics that could potentially be included in the Core Web Vitals:

Smoothness (Animation Fluidity)

This metric measures how smoothly animations and scroll interactions run on a website. The goal is to identify...Frame Drops and Jank— also stuttering that impairs the user experience. Particularly relevant for:

  • Websites with parallax scrolling effects
  • E-commerce shops with product carousels
  • Websites with complex CSS animations
  • Single-page applications with dynamic transitions

Responsiveness Beyond INP

While INP measures the delay until the visual update after an interaction, there are efforts to...entire interaction chainto record. This includes:

  • The time until all network requests triggered by the interaction are completed
  • The stability of the layout after the interaction
  • The consistency of interaction times over the entire usage period

Long Animation Frames (LoAF)

This API enables more precise analysis,WhyA page is responding slowly. Unlike previous Long Tasks, which only measured the duration, LoAF provides detailed information about the cause of the delay — including the responsible scripts and functions.

Soft navigation and single-page applications

One of the biggest gaps in the current Core Web Vitals is the measurement ofSoft navigation— that is, page changes within single-page applications (SPAs) that occur without a full page load. Google is actively working on a solution that will make CWV fair and meaningful for SPAs as well.

This is particularly relevant for websites that rely on frameworks such asNext.js, Nuxt.js or Angularbased. In the DACH region, according toW3Techs already 18% of the top 10,000 websiteson SPA architecture — and the trend is rising.

What does that mean for you?

  • If you operate a spa, you should...Soft Navigation APIkeep an eye on it
  • Implement performance monitoring for client-side navigation now.
  • Don't just test your SPA on the initial page load, but also on subsequent navigation.

Preparing for future metrics

Even though the exact future metrics are not yet finalized, you can start preparing today:

  • Introduce a performance budgetDefine maximum JavaScript bundle sizes, maximum load times, and maximum layout shifts. These budgets protect you from regressions, regardless of which metrics Google introduces.
  • Implement Real User Monitoring (RUM)— Capture performance data from real users, not just from synthetic tests. Tools likeSpeedCurve,Web Vitals Library or Vercel Analyticsprovide valuable real-time data
  • Analyze JavaScript bundleReduce unused code, implement code splitting and lazy loading. Smaller bundles mean better performance—regardless of the specific metric.
  • Optimize server performance— Invest in fast servers, CDN configuration, and edge computing. A robust server infrastructure is the foundation for all performance metrics.
  • Accessibility as a performance factor— Accessible websites are often more performant because they rely on lean, semantic HTML code. Google increasingly considers accessibility a quality signal.

The most important advice for the DACH market:Pursue a user-centered approach instead of optimizing individual metrics.If your website loads quickly, responds reliably to interactions, and is visually stable, you will benefit from all future Core Web Vitals updates — regardless of which specific metrics Google introduces.

Conclusion and next steps

Core Web Vitals are not a one-time project, but an ongoing process. New features, content changes, and third-party updates can degrade performance at any time. Here's your action plan:

Immediate measures (this week)

  1. Measure:Open PageSpeed Insights and test your 5 most important pages.
  2. Prioritize:Identify the metric with the greatest potential for improvement.
  3. Quick Wins:Compress images, add dimensions, optimize fonts

Short term (this month)

  1. Optimize servers:Evaluate hosting, set up CDN, configure caching
  2. JavaScript audit:Identify and remove unnecessary plugins/scripts
  3. Evaluate theme/framework:Is your theme/framework the bottleneck?

Long-term (this quarter)

  1. Setting up monitoring: Automated Performance Monitoring (e.g. SpeedCurve, Caliber)
  2. Define the performance budget:Maximum bundle size, maximum LCP value
  3. Team awareness:Raise awareness of performance among all developers
  4. Regular audits:Monthly performance reviews

Do you need support?

Core Web Vitals optimization is complex and requires technical expertise.Golden WingWe optimize the Core Web Vitals as an integral part of every web design andSEO projectFrom performance analysis to implementation — we'll make your website green.

Take advantage of our freePerformance Checker, to determine the current status of your website, andcontact usFor a free consultation. Together we'll make your website fast, stable, and user-friendly.

If you would like to learn more about technical aspectsSEOIf you would like to learn more, please visit ourDictionary entriesor read our other blog articles on the topicsweb design and Performance optimization. Core Web Vitals are a fixed part of our web design in Vienna.

Expert Opinions

“Core Web Vitals sind kein reines SEO-Thema – sie messen direkt die Nutzererfahrung. Eine Seite, die schnell lädt, visuell stabil ist und sofort auf Eingaben reagiert, wird immer besser ranken.”

John Mueller — Search Advocate bei GoogleSource: https://developers.google.com/search

“Der häufigste Fehler bei der CWV-Optimierung ist der Fokus auf den LCP allein. INP wird von den meisten Entwicklern noch immer unterschätzt, obwohl es seit 2024 offiziell zum Ranking-Signal gehört.”

Barry Adams — Technical SEO Consultant bei Polemic Digital

“Jede Sekunde zählt: Eine Verbesserung der Ladezeit um eine Sekunde kann die Konversionsrate um bis zu 7 Prozent steigern.”

Avinash Kaushik — Digital Marketing Evangelist, ehem. GoogleSource: https://www.kaushik.net

Frequently Asked Questions

Core Web Vitals sind drei Google-Metriken (LCP, INP, CLS), die Ladezeit, Interaktivität und visuelle Stabilität messen. Sie sind seit 2021 offizieller Rankingfaktor.

Den LCP verbessert man durch optimierte Bilder (WebP, Lazy Loading), schnelles Hosting, CDN und das Entfernen render-blockierender Ressourcen.

CLS misst, wie stark sich Elemente während des Ladens verschieben. INP misst, wie schnell die Seite auf Klicks und Eingaben reagiert.

Google empfiehlt PageSpeed Insights, die Google Search Console und Lighthouse im Chrome DevTools. Für Echtzeit-Nutzerdaten bietet die CrUX-API wertvolle Einblicke.

Ja, Core Web Vitals sind ein bestätigter Rankingfaktor. Bei ähnlicher inhaltlicher Qualität kann eine technisch bessere Seite einen Rankingvorteil erzielen.

Did you find this article helpful?

Share it with others.

Your Contact Person

Mag. Deni Khachukaev

Mag. Deni Khachukaev

Founder & Technical Director

With over 13 years of experience in web development and SEO, Deni leads the technical direction of GoldenWing. Specialized in performance optimization, technical SEO, and modern web technologies.

Ready for your project?

We bring the same dedication and expertise you see in our articles to every client project.