Core Web Vitals Quick-Fix Guide: Pass All Three in One Weekend

The Weekend Plan

Google's Core Web Vitals measure three things: how fast the largest element appears (LCP), how stable the layout is (CLS), and how responsive the page is to interaction (INP). Passing all three means: LCP under 2.5 seconds, CLS under 0.1, INP under 200ms.

Most sites fail one or two of these on mobile. The fixes are usually straightforward but require focused attention. This guide gives you a weekend plan: Friday evening for diagnosis, Saturday for LCP and CLS fixes, Sunday for INP and verification.

You will need: access to your site files or CMS, PageSpeed Insights, and Chrome DevTools. Read our Core Web Vitals explainer if you need background on what each metric measures.

Friday Evening: Audit and Baseline

Step 1: Record your baselines. Run your top 5 pages through PageSpeed Insights on mobile. Record LCP, CLS, TBT (proxy for INP), and the overall Performance score. Run each page 3 times and average the results.

Step 2: Identify the LCP element. In PageSpeed Insights, expand the "Largest Contentful Paint element" diagnostic. It tells you exactly which element is your LCP: usually a hero image, a large heading, or a background image.

Step 3: Identify CLS sources. Expand "Avoid large layout shifts." It shows which elements shifted and by how much. Common culprits: images without dimensions, late-loading fonts, dynamically injected content.

Step 4: Identify TBT/INP sources. Expand "Avoid long main-thread tasks." It shows which scripts block the main thread and for how long. Long tasks over 50ms are the ones to fix.

Step 5: Prioritize. Which metric is furthest from passing? That is your Saturday focus.

Saturday Morning: Fix LCP

LCP failures are caused by slow-loading hero images, render-blocking CSS/JS, or slow server response. Fix them in this order:

Optimize the LCP image. If your LCP element is an image:

<!-- Before: 800KB JPEG, no sizing -->
<img src="hero.jpg" alt="...">

<!-- After: WebP, sized, prioritized -->
<img src="hero.webp" alt="..."
     width="1200" height="600"
     fetchpriority="high"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="100vw">

Convert to WebP (25-35% smaller). Add explicit dimensions. Add fetchpriority="high". Add srcset for responsive sizes. Target: hero image under 100KB.

Eliminate render-blocking CSS. If your LCP is a text element blocked by CSS:

<!-- Inline critical CSS in head -->
<style>
  /* Only the CSS needed for above-the-fold content */
  body { font-family: system-ui; color: #333; }
  .hero { padding: 4rem 0; }
  .hero h1 { font-size: 2.5rem; }
</style>

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

Reduce TTFB. If your server response is over 600ms, enable server-side caching or switch to a CDN. For WordPress: install WP Rocket. For any platform: put Cloudflare in front (free).

Saturday Afternoon: Fix CLS

CLS fixes are usually quick. The goal is to prevent elements from moving after they start rendering.

Add dimensions to all images and videos:

<!-- Before: browser does not know size -->
<img src="photo.webp" alt="...">

<!-- After: browser reserves exact space -->
<img src="photo.webp" alt="..." width="600" height="400"
     style="max-width: 100%; height: auto;">

Fix font loading flash:

@font-face {
  font-family: 'YourFont';
  src: url('font.woff2') format('woff2');
  font-display: swap; /* Shows fallback instantly */
}

Reserve space for dynamic content. If ads, cookie banners, or embeds inject content after load, give them a fixed-height container:

.ad-slot { min-height: 250px; }
.cookie-banner { position: fixed; /* does not shift layout */ }

Do not inject content above existing content. If a notification bar appears at the top of the page, it pushes everything down. Use position: fixed or position: sticky instead so it overlays without shifting.

Sunday Morning: Fix INP/TBT

INP (Interaction to Next Paint) measures how fast the page responds to clicks and taps. TBT (Total Blocking Time) in lab tests correlates with INP in the field. Both are caused by JavaScript blocking the main thread.

Defer non-critical JavaScript:

<!-- Before: blocks parsing -->
<script src="analytics.js"></script>

<!-- After: executes after HTML parsed -->
<script src="analytics.js" defer></script>

Load third-party scripts on interaction:

// Load chat widget only when user scrolls
let chatLoaded = false;
window.addEventListener('scroll', function() {
  if (!chatLoaded) {
    chatLoaded = true;
    const s = document.createElement('script');
    s.src = 'https://chat-widget.example.com/widget.js';
    document.body.appendChild(s);
  }
}, { once: true });

Break up long tasks. If a script takes 200ms to execute, split it into smaller chunks using requestIdleCallback or setTimeout(fn, 0) to yield the main thread between chunks.

Remove heavy plugins. On WordPress, install the Query Monitor plugin and check which plugins add the most JavaScript. Remove or replace the heaviest ones.

Sunday Afternoon: Verify and Monitor

Re-test all 5 pages. Run each through PageSpeed Insights 3 times and average the results. Compare against your Friday baselines.

Check field data. Lab data (PageSpeed Insights) updates immediately. Field data (Chrome User Experience Report) takes 28 days to reflect changes. Check Google Search Console's Core Web Vitals report weekly for the next month.

Expected improvements:

• Image optimization alone: 10-20 point improvement
• CSS/JS deferral: 5-15 point improvement
• CLS fixes: 0.05-0.15 CLS reduction
• Third-party script management: 5-10 point improvement

If you are still below 85 after all fixes: The platform is the ceiling. WordPress, Webflow, and Squarespace have architectural limits that weekend optimization cannot overcome. A rebuild to static HTML costs $2,500-6,000 and delivers 90-98 permanently. Run a free audit to see the gap.

For the full technical reference, read our complete page speed optimization guide or the 47-item speed checklist.