Google Cares About How Fast Your Site Feels
In 2020, Google announced that page experience would become a ranking signal. In 2021, Core Web Vitals rolled out as part of the ranking algorithm. In 2024, Google replaced FID (First Input Delay) with INP (Interaction to Next Paint), raising the bar further. The message is clear: if your website is slow, janky, or unresponsive, Google will rank it lower.
This is not about vanity metrics. For businesses in Lugano and across Switzerland competing for local search visibility, Core Web Vitals can be the difference between appearing on page one and being buried on page three. When two pages have similar content relevance, the one with better performance wins.
But Core Web Vitals are also about real users. A site that loads in 1.2 seconds converts better than one that loads in 3.8 seconds. Amazon calculated that every 100ms of additional load time cost them 1% in revenue. For smaller businesses, the relative impact can be even larger because visitors have lower patience for unknown brands.
The Three Core Web Vitals Explained
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible content element to render. This is usually a hero image, a featured video thumbnail, or a large block of text. It answers the user's question: "Has the main content loaded?"
Thresholds:
| Rating | LCP Time |
|---|---|
| Good | Under 2.5 seconds |
| Needs Improvement | 2.5 - 4.0 seconds |
| Poor | Over 4.0 seconds |
What counts as the LCP element:
<img>elements<image>inside SVG<video>poster images- Elements with background images loaded via
url() - Block-level elements containing text nodes
Common causes of poor LCP:
- Slow server response time (TTFB): If your server takes 800ms to respond, you've already burned a third of your LCP budget before the browser even starts rendering. Shared hosting with PHP-based CMS platforms is a frequent culprit here.
- Render-blocking resources: Large CSS and JavaScript files that must be downloaded and parsed before rendering can begin. Every stylesheet in the
<head>blocks rendering until it's loaded. - Unoptimized images: A 2MB hero image served as a full-resolution JPEG when a 150KB WebP would look identical. This is the single most common LCP problem we see on client sites.
- Client-side rendering: Single Page Applications (SPAs) that render everything in JavaScript force the browser to download JS, parse it, execute it, fetch data from APIs, and then render. LCP happens after all of that, often exceeding 4 seconds.
- Lazy loading the LCP element: Adding
loading="lazy"to the hero image delays its loading. The LCP image should always be eagerly loaded.
INP: Interaction to Next Paint
INP replaced FID (First Input Delay) in March 2024. While FID only measured the delay of the first interaction, INP measures the responsiveness of all interactions throughout the page lifecycle. It tracks clicks, taps, and keyboard inputs, measuring the time from when the user interacts to when the browser paints the visual response.
Thresholds:
| Rating | INP Time |
|---|---|
| Good | Under 200 milliseconds |
| Needs Improvement | 200 - 500 milliseconds |
| Poor | Over 500 milliseconds |
Common causes of poor INP:
- Long JavaScript tasks: Any JavaScript task that runs for more than 50ms blocks the main thread. During that time, the browser cannot respond to user input. Third-party scripts (analytics, ads, chat widgets) are often the worst offenders.
- Excessive DOM size: Pages with thousands of DOM nodes take longer to update after interactions. Every state change triggers layout recalculation across the entire tree.
- Unoptimized event handlers: Click handlers that trigger complex calculations, API calls, or heavy DOM manipulations without proper optimization.
- Lack of code splitting: Loading the entire application's JavaScript upfront means the browser has more code to parse and compile, increasing the chance of long tasks.
CLS: Cumulative Layout Shift
CLS measures visual stability. It quantifies how much the page layout shifts during loading. You know the experience: you start reading an article, an ad loads above, and the text jumps down. Or you're about to click a button, an image loads, and you click the wrong element. CLS captures this frustration as a number.
Thresholds:
| Rating | CLS Score |
|---|---|
| Good | Under 0.1 |
| Needs Improvement | 0.1 - 0.25 |
| Poor | Over 0.25 |
Common causes of poor CLS:
- Images without dimensions: If you don't specify
widthandheightattributes on<img>tags, the browser doesn't know how much space to reserve until the image loads. - Ads and embeds without reserved space: Third-party embeds (ads, social media widgets, video players) that inject themselves into the page without predefined dimensions.
- Dynamically injected content: Banners, notifications, or cookie consent popups that push content down after the page has already rendered.
- Web fonts causing FOUT/FOIT: When a web font loads and replaces the fallback font, the text reflows if the fonts have different metrics. Use
font-display: swapcombined with a closely-matched fallback font orfont-display: optionalto eliminate this shift entirely.
How to Measure Core Web Vitals
Lab Tools vs. Field Data
There is an important distinction between lab data (simulated) and field data (real users). Google uses field data for ranking decisions.
- Lab tools (Lighthouse, PageSpeed Insights in lab mode, WebPageTest) simulate a page load on a specific device and network. They are useful for debugging but don't reflect real user experience.
- Field tools (Chrome UX Report / CrUX, PageSpeed Insights field data, Google Search Console) aggregate data from real Chrome users. This is what Google uses for ranking.
Google PageSpeed Insights
The simplest starting point. Enter your URL at pagespeed.web.dev and you get both lab and field data (if available). The field data section shows your actual Core Web Vitals as experienced by real users over the past 28 days. If your site doesn't have enough traffic to appear in CrUX, you'll only see lab data.
Google Search Console
The Core Web Vitals report in Search Console groups your pages into "Good," "Needs Improvement," and "Poor" categories. This is the most actionable view because it shows which URL patterns are failing and which specific metric is the problem.
Lighthouse
Built into Chrome DevTools (F12 > Lighthouse tab). Runs a simulated page load and gives scores for Performance, Accessibility, Best Practices, and SEO. The performance score is heavily influenced by Core Web Vitals. Run it in Incognito mode to avoid extensions skewing results.
A critical caveat: Lighthouse simulates a mid-tier mobile device on a throttled 4G connection. Your actual users may have better or worse conditions. Don't optimize purely for the Lighthouse score; optimize for real user metrics.
Chrome UX Report (CrUX)
CrUX is the dataset Google uses for ranking. You can access it through:
- PageSpeed Insights (field data section)
- Search Console (Core Web Vitals report)
- CrUX API (for programmatic access)
- BigQuery (for the full dataset, updated monthly)
Web Vitals JavaScript Library
For continuous monitoring, add Google's web-vitals library to your site:
import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(metric => sendToAnalytics('LCP', metric));
onINP(metric => sendToAnalytics('INP', metric));
onCLS(metric => sendToAnalytics('CLS', metric));This captures real user data and sends it to your analytics platform. It gives you per-page, per-device-type, and per-connection-speed breakdowns that CrUX alone doesn't provide.
Optimization Strategies
Fixing LCP
1. Optimize the server response:
- Use a CDN to serve content from the nearest edge node
- Enable HTTP/2 or HTTP/3 for multiplexed connections
- Implement effective caching (browser cache, CDN cache)
- If using a CMS, add full-page caching so the server doesn't rebuild the page on every request
2. Optimize images:
- Use modern formats: WebP provides 25-35% smaller files than JPEG at equivalent quality. AVIF is even smaller but has less browser support.
- Implement responsive images with
srcsetandsizesattributes so the browser loads the right size for the viewport. - Set explicit
widthandheightto prevent layout shift. - Preload the LCP image:
<link rel="preload" as="image" href="/hero.webp"> - Don't lazy-load the LCP image. Use
fetchpriority="high"on it instead.
3. Eliminate render-blocking resources:
- Inline critical CSS (the CSS needed for above-the-fold content) and defer the rest.
- Add
deferorasyncto script tags that don't need to execute before rendering. - Avoid large CSS frameworks if you only use a fraction of their styles. Tailwind with PurgeCSS, for example, can reduce CSS from 300KB to under 10KB.
Fixing INP
1. Break up long tasks:
- Use
requestIdleCallback()orsetTimeout()to defer non-critical work. - Move heavy computations to Web Workers.
- Use
scheduler.yield()(available in Chrome) to break long tasks into smaller chunks that let the browser respond to input between them.
2. Reduce JavaScript:
- Audit third-party scripts. Each analytics tool, chat widget, and ad script adds to the main thread workload. Question whether each one is necessary.
- Implement code splitting: load only the JavaScript needed for the current page.
- Use tree shaking to eliminate unused code from bundles.
3. Optimize DOM size:
- Aim for under 1,500 DOM nodes. Pages with 3,000+ nodes will struggle with INP.
- Virtualize long lists (only render the visible items).
- Use
content-visibility: autoto skip rendering of off-screen content.
Fixing CLS
1. Reserve space for dynamic content:
- Always set
widthandheighton images and videos. CSSaspect-ratiois the modern approach:aspect-ratio: 16/9. - Use
min-heighton containers that will receive dynamically loaded content. - Reserve space for ads with fixed-size containers.
2. Avoid inserting content above existing content:
- Load ads and embeds below the fold or in dedicated spaces that don't push content.
- Show cookie banners as overlays (fixed position) rather than pushing content down.
- Use CSS
transformanimations instead oftop/leftanimations, which trigger layout recalculation.
3. Handle font loading:
- Self-host fonts for faster loading (no external DNS lookup, no external connection).
- Use
font-display: swapwith a size-adjusted fallback to minimize reflow. - Preload critical fonts:
<link rel="preload" as="font" type="font/woff2" href="/fonts/main.woff2" crossorigin>
Mobile vs. Desktop: Why Mobile Matters More
Google uses mobile-first indexing. Your mobile Core Web Vitals determine your ranking, even for desktop searches. This means:
- Mobile performance is not optional.
- Test on real devices, not just browser simulation. A mid-range Android phone processes JavaScript 3-5x slower than a MacBook.
- Mobile networks have higher latency and lower bandwidth than broadband. A 5MB page that loads in 1 second on office WiFi might take 6 seconds on a mobile connection.
The gap between desktop and mobile performance is where most businesses lose rankings. Their desktop scores are fine, but mobile scores are poor because they never tested under realistic mobile conditions. For more on why websites are slow and how to fix them, see our article on why your website is slow.
Impact on Conversion Rates
Core Web Vitals are not just about SEO. They directly affect business outcomes:
| Metric Improvement | Business Impact |
|---|---|
| LCP improvement from 4s to 2s | Up to 15% increase in conversions |
| CLS reduction from 0.25 to 0.05 | Up to 18% fewer bounce-backs |
| INP improvement from 500ms to 150ms | Measurable increase in form completions and clicks |
These numbers come from case studies published by Google and from our own work with client sites. The causal chain is straightforward: a faster, more stable, more responsive site reduces frustration, keeps users engaged, and leads to more conversions. For a comprehensive overview of performance optimization strategies, see our article on website performance optimization.
Quick Wins: The 80/20 of Performance Optimization
If you're looking for the highest-impact changes with the least effort:
- Serve images in WebP format with proper sizing. This alone often fixes LCP.
- Add width and height to all images. This alone often fixes CLS.
- Defer non-critical JavaScript. Move analytics and tracking scripts to load after the page is interactive.
- Use a CDN. Moving from a single-server setup to a CDN can cut TTFB by 50-80%.
- Enable text compression (gzip or Brotli). This reduces transfer size for HTML, CSS, and JS by 60-80%.
These five changes can take a site from a Lighthouse score of 40 to 85+ in an afternoon. The remaining optimization is incremental and site-specific.
Conclusion
Core Web Vitals are real ranking signals with measurable impact on both search visibility and conversion rates. They are not going away; Google continues to refine and expand them. The shift from FID to INP in 2024 raised the bar, and future updates will likely continue this trend.
For businesses in Lugano and across Switzerland, investing in website performance is investing in search visibility, user experience, and revenue. The tools to measure are free. The fixes are well-documented. The only question is whether you choose to act on the data.
If you want help assessing and improving your Core Web Vitals, contact our team. We can audit your site, identify the specific bottlenecks affecting your scores, and implement targeted optimizations that deliver measurable results.
Want to know if your site is secure?
Request a free security audit. In 48 hours you get a complete report.
Request Free Audit