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:
| Metric | Measures | Good | Needs Improvement | Bad |
|---|---|---|---|---|
| **LCP** (Largest Contentful Paint) | Loading speed | ≤ 2.5s | 2.5-4.0s | > 4.0s |
| **CLS** (Cumulative Layout Shift) | Visual Stability | ≤ 0.1 | 0.1-0.25 | > 0.25 |
| **INP** (Interaction to Next Paint) | Interactivity | ≤ 200ms | 200-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
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:
| Tool | Type | Free | Best for |
|---|---|---|---|
| **PageSpeed Insights** | Lab + Field | Yes | Single-page analysis |
| **Google Search Console** | Field | Yes | Website-wide overview |
| **Chrome DevTools** | Lab | Yes | Debugging and Analysis |
| **Web Vitals Extension** | Lab | Yes | Real-time monitoring in the browser |
| **WebPageTest** | Lab | Yes (Basic) | Detailed Waterfall Analysis |
| **Lighthouse CI** | Lab | Yes | Automated CI/CD checks |
| **SpeedCurve** | Lab + Field | No (from $12/month) | Long-term monitoring |
| **Calibre** | Lab + Field | No (from $45/month) | Team Performance Tracking |
| **GoldenWing Performance Checker** | Lab | Yes | [Quick Analysis](/tools/performance-checker) |
Recommended workflow:
- Overview:Google Search Console → Check CWV report
- Analysis:PageSpeed Insights for the most important pages
- Debugging:Chrome DevTools → Performance tab → Identify bottlenecks
- Monitoring:Web Vitals Extension for daily work
- 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:
| Purpose | Recommended | Avoid |
|---|---|---|
| Caching | WP Rocket, LiteSpeed Cache | W3 Total Cache (complex) |
| Image optimization | ShortPixel, Imagify | Smush Free (limited) |
| CSS/JS optimization | Perfmatters, Asset CleanUp | Autoptimize (can cause conflicts) |
| Database | WP-Optimize | — |
| Lazy loading | Native (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:
- Hero image: PNG → WebP, 3.2 MB → 120 KB, `fetchpriority="high"`
- All images with `next/image` and fixed dimensions
- Font optimization with `next/font` (self-hosted, `swap`)
- Framer Motion replaced by CSS transitions (Bundle -180KB)
- 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:
- Slider replaced by static hero image
- ShortPixel for automatic image compression (WebP)
- Plugin audit: 15 → 8 plugins (7 unnecessary ones removed)
- WP Rocket installed (caching, CSS/JS minification, lazy loading)
- Switching from Shared to Managed VPS hosting
- 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:
- Hero image: JPEG → WebP, 2.1 MB → 95 KB, fetchpriority="high"
- All images have width/height attributes.
- Cookie banner position changed to: fixed
- WP Rocket + ShortPixel installed
- 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
INP optimization for filters and search
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
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 a single 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
INP optimization for filters and search
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.
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 a single 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
INP optimization for filters and search
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 a [result] after CWV optimizationOrganic 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)
- Measure:Open PageSpeed Insights and test your 5 most important pages.
- Prioritize:Identify the metric with the greatest potential for improvement.
- Quick Wins:Compress images, add dimensions, optimize fonts
Short term (this month)
- Optimize servers:Evaluate hosting, set up CDN, configure caching
- JavaScript audit:Identify and remove unnecessary plugins/scripts
- Evaluate theme/framework:Is your theme/framework the bottleneck?
Long-term (this quarter)
- Setting up monitoring: Automated Performance Monitoring (e.g. SpeedCurve, Caliber)
- Define the performance budget:Maximum bundle size, maximum LCP value
- Team awareness:Raise awareness of performance among all developers
- 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.