Skip to main content
jones

Performance · SEO · Web Development

Core Web Vitals Are a Business Problem, Not a Technical One

Poor Core Web Vitals cost you search rankings, conversion rates, and user trust. Here's how to think about them, and what actually moves the numbers.

5 min read

Every week, we review a new client site and find the same story: beautiful design, reasonable content, and Core Web Vitals scores that quietly undermine all of it. The site looks fine on the designer's MacBook Pro. It loads slowly for the majority of actual users on real-world connections and devices.

This matters more than most people realize.

What Core Web Vitals actually measure

Google's Core Web Vitals are three specific performance metrics that measure real-world user experience:

Largest Contentful Paint (LCP) measures load performance: specifically, how quickly the largest visible element (usually a hero image or headline) appears on screen. Google's threshold for "good" is under 2.5 seconds.

Interaction to Next Paint (INP) measures responsiveness: how quickly your page reacts after a user interaction like clicking a button. The "good" threshold is under 200 milliseconds. (INP replaced First Input Delay in 2024.)

Cumulative Layout Shift (CLS) measures visual stability: how much the page content unexpectedly shifts as it loads. A score under 0.1 is considered good.

These are measured using real user data from the Chrome User Experience Report (CrUX), not synthetic lab tests. That distinction matters.

Why they're a business problem

The relationship between performance and business outcomes is well-documented:

  • A 1-second delay in mobile load time reduces conversions by up to 20% (Google/Deloitte)
  • 53% of mobile users abandon a site that takes longer than 3 seconds to load
  • Core Web Vitals are a confirmed ranking signal; Google uses them as a tiebreaker when other signals are equal

But beyond the statistics: slow sites feel broken. Users attribute a slow experience to low quality. A site that loads in 4 seconds says something about your brand, whether you intend it to or not.

The most common culprits

Large, unoptimized images (LCP)

The single most common cause of poor LCP is an unoptimized hero image. A 3MB JPEG in a hero section will guarantee a slow LCP on any non-fiber connection.

The fix: use modern image formats (AVIF, WebP), compress aggressively, implement responsive images with srcset, and use loading="eager" with fetchpriority="high" on above-the-fold images. If you're on Next.js, the Image component handles most of this automatically.

Render-blocking resources (LCP)

Large CSS files, synchronously loaded JavaScript, and third-party scripts loaded in <head> block the browser from rendering the page.

The fix: defer non-critical scripts, load third-party tools asynchronously, split your CSS to deliver only what's needed for the initial render, and move scripts to the bottom of the page where possible.

Slow server response times (LCP)

If your Time to First Byte (TTFB) is poor, everything downstream suffers. A slow backend, no CDN, or server-side rendering without caching all contribute.

The fix: implement edge caching, use a CDN, optimize database queries, and consider static generation for content that doesn't change per-request. Edge runtime environments like Vercel's can dramatically improve global TTFB.

JavaScript execution overhead (INP)

Long JavaScript tasks block the main thread and make interactions feel sluggish. Heavy frameworks, large third-party scripts, and poorly written event handlers are common causes.

The fix: audit your JavaScript bundle size, defer non-essential third-party scripts (analytics, chat widgets, etc.), and avoid running expensive synchronous operations on user interaction.

Missing image dimensions (CLS)

When images load without explicit width and height attributes, the browser doesn't know how much space to reserve. The layout shifts when the image arrives.

The fix: always specify dimensions on images. In CSS, use aspect-ratio to preserve space for dynamically sized containers.

Web fonts (CLS and LCP)

Fonts that load late cause text to reflow (a jarring CLS contributor) and can delay the LCP if text is the largest element. The "flash of invisible text" (FOIT) and "flash of unstyled text" (FOUT) are both UX problems.

The fix: preload critical font files, use font-display: swap to show system fonts while custom fonts load, and use next/font in Next.js which handles font optimization automatically (including hosting fonts with zero external requests).

How to audit your site

Start with field data, not just lab data:

  1. Google Search Console → Core Web Vitals report shows real-user data segmented by URL
  2. PageSpeed Insights (pagespeed.web.dev): shows both field and lab data with specific recommendations
  3. Chrome DevTools Performance tab: for deep-dive analysis of specific interactions
  4. Web Vitals Chrome Extension: shows live metrics as you browse

A common mistake is using only Lighthouse (lab data) and calling it done. Lighthouse runs under controlled conditions. Real users have slower connections, older devices, and third-party scripts your tests might not fully simulate.

What actually moves the numbers

Based on our performance and growth work across dozens of sites, here's where the highest-leverage fixes consistently live:

  1. Image optimization: usually the single biggest LCP gain
  2. Font optimization: eliminates CLS and often improves LCP
  3. Third-party script deferral: analytics, chat, and marketing tools loaded synchronously are often the biggest INP killers
  4. Server-side caching and CDN implementation: dramatically improves TTFB globally
  5. JavaScript bundle analysis: identify and eliminate unused code

The technical fixes are relatively straightforward. The organizational challenge is getting agreement to deprioritize a new feature for a performance sprint, or to remove a marketing script that someone "needs." That's the real work.

Build performance in, don't bolt it on

The most expensive performance improvements are the ones you have to retrofit into an already-built site. We approach every web project with performance as a first-order constraint: architecture decisions, image handling, third-party script policies, and caching strategies are all established before the first page is designed.

The result is sites that don't just score well on synthetic tests. They feel fast for real users on real devices. That's the goal.

If your site has performance issues that keep getting deprioritized, we can help you figure out where to start.

Put these ideas into practice.

Tell us what you're working on. We'll give you an honest read on scope, approach, and fit.

Start a Conversation