Google Core Web Vitals and Performance Checklist

1 Optimize Largest Contentful Paint (LCP)

Target: under 2.5 seconds. Identify the LCP element using Lighthouse or Chrome DevTools. It is usually a hero image, large heading, or video poster. Preload the LCP resource and eliminate any render-blocking scripts or stylesheets above the fold.

<!-- Preload the LCP image with high priority -->
<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

<!-- Preload critical CSS -->
<link rel="preload" as="style" href="/css/critical.css" onload="this.onload=null;this.rel='stylesheet'">

<!-- Defer non-critical JavaScript -->
<script defer src="/js/main.js"></script>

Monitor LCP in the field using the CrUX report in Google Search Console. Lab tools (Lighthouse) show potential issues; field data shows real user impact.

2 Eliminate Render-Blocking Resources

Render-blocking resources delay the browser from painting anything on screen. Inline critical CSS in the head and defer all non-critical CSS and JS. This is the single highest-impact fix for LCP on most sites.

<!-- Inline critical CSS directly in the HTML head -->
<style>
  /* Critical above-the-fold styles */
  body { font-family: sans-serif; margin: 0; }
  .hero { display: flex; ... }
</style>

<!-- Load non-critical CSS asynchronously -->
<link rel="preload" as="style" href="/css/full.css"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/full.css"></noscript>

3 Optimize Images

Images account for 50-70% of page weight on most sites. Use next-gen formats (WebP, AVIF), serve responsive sizes with srcset, lazy load below-the-fold images, and compress aggressively without visible quality loss.

<picture>
  <source srcset="/image.avif" type="image/avif">
  <source srcset="/image.webp" type="image/webp">
  <img src="/image.jpg"
       srcset="/image-400.jpg 400w,
               /image-800.jpg 800w,
               /image-1200.jpg 1200w"
       sizes="(max-width: 600px) 100vw, 800px"
       width="800" height="450"
       loading="lazy"
       decoding="async"
       alt="Description">
</picture>

# Bulk convert to WebP with cwebp
for img in *.jpg; do
  cwebp -q 80 "$img" -o "${img%.jpg}.webp"
done

# Convert to AVIF with avifenc
for img in *.jpg; do
  avifenc --speed 6 --min 20 --max 40 "$img" "${img%.jpg}.avif"
done

4 Reduce Server Response Time (TTFB)

Target: under 200ms. Slow TTFB indicates server-side bottlenecks. Upgrade hosting, enable PHP OPcache, optimize database queries, implement server-side page caching, and use a reverse proxy like Nginx or Varnish.

# Test TTFB from multiple locations
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" \
  https://www.yourdomain.com

# PHP OPcache configuration
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60

# Nginx fastcgi cache
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=mycache:10m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout updating;

5 Break Up Long JavaScript Tasks

Target INP: under 200ms. Long tasks (over 50ms) block the main thread and make the page feel unresponsive. Break them up by yielding to the main thread, using async/await, and splitting work into smaller chunks.

New in 2025-2026: The scheduler.yield() API provides a dedicated mechanism for yielding control back to the browser without the overhead of setTimeout(0). Unlike setTimeout, scheduler.yield() integrates with the browser's task prioritization system and does not require a minimum delay. It is supported in Chrome 115+ and is the preferred way to break up long tasks.

// Modern approach: scheduler.yield() (Chrome 115+)
async function processItems(items) {
  for (const item of items) {
    heavyProcess(item);
    await scheduler.yield();  // yield without timeout overhead
  }
}

// Fallback: yield via setTimeout
async function processItemsWithFallback(items) {
  for (const item of items) {
    heavyProcess(item);
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

// Use requestIdleCallback for non-critical work
function scheduleWork(task) {
  if ('requestIdleCallback' in window) {
    requestIdleCallback(task, { timeout: 2000 });
  } else {
    setTimeout(task, 1);
  }
}

// Avoid forced reflows
// Bad: Reading layout after writing
element.style.width = '100px';
const width = element.offsetWidth;  // triggers forced reflow

// Good: Batch reads separately from writes
const reads = [];
// ... all writes first, then reads

6 Defer and Audit Third-Party Scripts

Third-party scripts (analytics, ads, social widgets, chatbots) are the #1 cause of poor INP. Each script competes for the main thread. Audit every third-party script, load them async, and remove any that are not essential.

<!-- Load third-party scripts with async or defer -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>

<!-- Use IntersectionObserver to lazy load non-critical widgets -->
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const script = document.createElement('script');
      script.src = entry.target.dataset.src;
      document.body.appendChild(script);
      observer.unobserve(entry.target);
    }
  });
});
document.querySelectorAll('[data-lazy-script]').forEach(el => observer.observe(el));

Use Chrome DevTools Performance tab to record page load and identify which scripts take the most main thread time. Remove any tag that does not provide clear business value.

7 Debounce and Throttle Event Handlers

Event handlers attached to scroll, resize, mousemove, or keydown fire hundreds of times per second. Without debouncing, each invocation runs on the main thread and degrades INP. Debounce delays execution until after a pause; throttle limits execution to once per interval.

// Debounce: waits for a pause before executing
function debounce(fn, delay = 150) {
  let timer;
  return function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

window.addEventListener('resize', debounce(() => {
  // handle resize
}, 150));

// Throttle: limits execution rate
function throttle(fn, limit = 100) {
  let inThrottle;
  return function(...args) {
    if (!inThrottle) {
      fn.apply(this, args);
      inThrottle = true;
      setTimeout(() => { inThrottle = false; }, limit);
    }
  };
}

window.addEventListener('scroll', throttle(() => {
  // handle scroll
}, 100));

8 Set Explicit Dimensions on All Media

CLS is caused primarily by images, videos, iframes, and ads that load without reserved space. Always set explicit width and height attributes on all media elements. This allows the browser to reserve the correct space before the resource loads.

<!-- Always set explicit width and height -->
<img src="/image.webp" width="800" height="450" alt="" loading="lazy">

<!-- For responsive images with unknown aspect ratios, use aspect-ratio CSS -->
img, video, iframe {
  max-width: 100%;
  height: auto;
  aspect-ratio: attr(width) / attr(height);
}

<!-- Reserve space for embeds with a wrapper -->
<div style="position: relative; padding-bottom: 56.25%; height: 0;">
  <iframe src="https://www.youtube.com/embed/..."
          style="position: absolute; top: 0; left: 0;
                 width: 100%; height: 100%;"></iframe>
</div>

9 Reserve Space for Ads and Embeds

Dynamic content like ads and embeds cause the most disruptive layout shifts because they load after the initial paint. Reserve the exact space they will occupy using min-height placeholders.

<!-- Reserve ad space with a placeholder -->
<div style="min-height: 250px; width: 100%; background: #f0f0f0;"
     id="ad-slot-desktop">
  <!-- Ad loads here -->
</div>

<!-- For multi-size ads, reserve the maximum possible space -->
<div class="ad-container" style="min-height: 90px;">
  <div id="ad-slot-responsive"></div>
</div>

10 Use font-display: swap for Web Fonts

Custom web fonts cause CLS in two ways: FOIT (Flash of Invisible Text) where text is hidden until the font loads, and FOUT (Flash of Unstyled Text) where text swaps from fallback to custom font. Use font-display: swap to show text immediately with a fallback font.

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom-font.woff2') format('woff2');
  font-display: swap;
  font-weight: 400;
}

/* Preload the font for earlier discovery */
<link rel="preload" as="font" href="/fonts/custom-font.woff2"
      type="font/woff2" crossorigin>

/* Use font-size-adjust to minimize layout shift during swap */
body {
  font-family: 'CustomFont', Arial, sans-serif;
  font-size-adjust: 0.5;
}

11 Enable CDN and Caching Strategy

A CDN serves content from servers closest to the user, reducing latency by 30-60%. Cloudflare, BunnyCDN, and AWS CloudFront offer generous free or low-cost tiers. Combine with proper Cache-Control headers and Brotli compression.

# Cache-Control headers for different asset types
# Images and fonts: cache for 1 year
location ~* \.(webp|avif|jpg|png|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

# CSS and JS: cache for 1 month
location ~* \.(css|js)$ {
  expires 1M;
  add_header Cache-Control "public";
}

# HTML: short cache or no cache
location ~* \.html$ {
  expires 0;
  add_header Cache-Control "no-cache";
}

# Enable Brotli compression on CDN
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript
             image/svg+xml application/json;

12 Set a Performance Budget and Monitor CrUX

A performance budget defines the maximum allowed size or time for each page. Track it in CI/CD to prevent regressions. Monitor Chrome User Experience Report (CrUX) data for real-user performance trends.

Understanding CrUX: The 75th Percentile

Google uses the 75th percentile of real-user measurements to determine whether a page passes Core Web Vitals. This means at least 75% of visits must meet the good threshold. If your LCP is 2.0s median but 30% of users experience 4.0s, you fail the LCP assessment. This is why lab tools (Lighthouse) alone are insufficient. Always validate against CrUX field data because real-user conditions vary widely by device, network, and geography.

Monitor CrUX in Google Search Console under the Core Web Vitals report. It shows the percentage of URLs rated Good, Need Improvement, and Poor for each metric. A sudden shift from Good to Poor often correlates with a recent deployment.

// Performance budget example (budget.json)
{
  "resources": {
    "total": { "maxSize": "500kB" },
    "javascript": { "maxSize": "200kB" },
    "css": { "maxSize": "50kB" },
    "images": { "maxSize": "300kB" },
    "fonts": { "maxSize": "50kB" }
  },
  "timings": {
    "lcp": { "maxTime": 2500 },
    "inp": { "maxTime": 200 },
    "cls": { "maxScore": 0.1 },
    "ttfb": { "maxTime": 200 }
  }
}

# Use Lighthouse CI to enforce budgets
# npx lhci collect --no-lr
# npx lhci assert --budget-file budget.json
# npx lhci upload

Lab vs Field Data: Lighthouse runs on a simulated device with a throttled connection. It catches obvious issues but cannot represent real-user conditions. CrUX aggregates data from millions of real Chrome users. Always prioritize field data for ranking decisions because Google uses field data (CrUX) for the CWV ranking signal. Use lab data for debugging specific issues, and field data for understanding real-world impact.