Google's Core Web Vitals remain a ranking factor, and hosting clients keep asking the same question: how do I fix my scores without rebuilding the entire site? Most optimization guides throw thirty techniques at you. I'm showing you five that move the needle fast—changes you can deploy in one working day and measure the next morning in Search Console.
These aren't theory. They're the interventions that consistently improved LCP, FID, and CLS in support tickets I handled over the past year, from WordPress blogs on shared cPanel to Rails apps behind CloudFront.
What Core Web Vitals actually measure
Largest Contentful Paint (LCP) tracks how long the main content block takes to render. Google wants under 2.5 seconds. Anything above 4 seconds is a fail. The usual suspect is an unoptimized hero image or web fonts blocking render.
First Input Delay (FID) measures how quickly the browser responds to the first user interaction—a click, a tap, a keypress. Target is under 100 milliseconds. Heavy JavaScript execution on the main thread kills this metric.
Cumulative Layout Shift (CLS) quantifies unexpected layout jumps while the page loads. Score below 0.1 is good; above 0.25 is poor. Missing width and height attributes on images, render-blocking fonts, and dynamically injected ads are the common causes.
You can check your scores in Google Search Console under the Experience section, or run a live test with PageSpeed Insights and Lighthouse. Real-world field data from Chrome User Experience Report (CrUX) is what matters for rankings, but lab data helps you debug.
1. Lazy load images and iframes below the fold
Native lazy loading shipped in Chrome 77 and is now supported across all modern browsers. Add loading="lazy" to any <img> or <iframe> tag that isn't immediately visible on page load.
<img src="/uploads/hero-image.jpg" alt="Hero" loading="eager">
<img src="/uploads/gallery-1.jpg" alt="Gallery" loading="lazy" width="800" height="600">
<iframe src="https://www.youtube.com/embed/xyz" loading="lazy" width="560" height="315"></iframe>
The eager value forces immediate load for above-the-fold images; lazy defers everything else until the user scrolls near it. This cuts initial page weight by 40-60% on image-heavy pages and directly improves LCP because the browser prioritizes the hero image.
Always include explicit width and height attributes. Browsers pre-allocate the space even before the image loads, which prevents layout shift (CLS). If you're retrofitting an existing site, a search-and-replace in your database or templates takes ten minutes.
For WordPress, the Jetpack Boost plugin and core WordPress (since 5.5) add lazy loading automatically. Just verify it's not double-loading with a theme or page builder that already adds the attribute.
2. Tune your CDN cache rules and compression
A misconfigured CDN can hurt performance. I've seen CloudFront distributions that cached HTML for 24 hours and bypassed cache for static assets—exactly backwards.
Set aggressive cache TTLs for immutable assets: CSS, JS, fonts, images with cache-busting filenames. Use Cache-Control: public, max-age=31536000, immutable in your origin response headers for files like style.a3f9b2.css. The CDN will hold them for a year, and the browser won't revalidate even on refresh.
For HTML and API responses, use Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400. The CDN keeps a copy for an hour; the browser for five minutes. If the origin is slow, the CDN serves stale content while fetching fresh in the background.
Enable Brotli compression at the CDN edge. Cloudflare turns it on by default; AWS CloudFront requires you to select a managed cache policy that includes Brotli. Brotli compresses text assets 15-20% smaller than Gzip, which shaves 200-400 KB off a typical page and improves LCP.
Check your cache hit ratio in the CDN dashboard. Anything below 85% means you're sending too many requests back to the origin. Common fixes: longer TTLs, wildcard cache rules for /wp-content/uploads/*, and stripping query strings from static assets.
So what if images are lazy-loaded but still too large?
3. Serve WebP and AVIF with automatic fallback
JPEG and PNG are legacy formats. WebP cuts file size by 25-35% at the same visual quality; AVIF does 50% in many cases. Both are supported in all evergreen browsers now.
Use the <picture> element to serve modern formats with a fallback:
<picture>
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img src="/images/hero.jpg" alt="Hero" width="1200" height="800" loading="eager">
</picture>
The browser picks the first format it understands. Older clients get the JPEG; modern ones get AVIF.
On the server side, automate conversion with ImageMagick or libvips. For WordPress, ShortPixel and Imagify do on-the-fly conversion and serve via <picture> tags. For static sites, add a build step with sharp in Node or image_processing in Ruby.
If you're on cPanel shared hosting, install the ImageMagick module via EasyApache or ask support to enable it. Then use a plugin or a simple PHP script to batch-convert your Media Library. I've watched LCP drop from 4.2s to 2.1s on an image-heavy WooCommerce store after switching to WebP alone.
Don't forget responsive srcset attributes to serve different sizes based on viewport width. A 2400px image on a phone is waste.
4. Inline critical CSS and defer the rest
Render-blocking CSS in the <head> is the second-biggest LCP killer after images. The browser can't paint anything until every stylesheet downloads and parses.
Extract the CSS needed for above-the-fold content and inline it in a <style> block in the <head>. Load the full stylesheet asynchronously:
<head>
<style>
/* Critical CSS: header, hero, above-fold layout */
body { margin: 0; font-family: sans-serif; }
.header { background: #333; color: #fff; padding: 1rem; }
.hero { height: 400px; background: url(/hero.jpg); }
</style>
<link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>
The preload + onload trick loads the stylesheet without blocking render. The <noscript> fallback ensures it works when JavaScript is off.
Generating critical CSS used to require tools like Critical or Critters. Now you can use Cloudflare's Auto Minify with "Rocket Loader" or a WordPress plugin like WP Rocket or Autoptimize. They parse your page, extract above-fold styles, and inline them automatically.
Keep the inlined CSS under 14 KB—ideally under 10 KB—so it fits in the first TCP round-trip. Anything larger and you're just moving the bottleneck.
5. Optimize font loading and display
Web fonts block text rendering by default. The browser hides text until the font file downloads (FOIT: flash of invisible text) or shows a fallback then swaps (FOUT: flash of unstyled text). Both hurt LCP and CLS.
Use font-display: swap in your @font-face declarations:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-weight: 100 900;
font-display: swap;
}
The browser shows fallback text immediately, then swaps in the web font when ready. It's a visible flash, but it's better than invisible text that tanks your LCP score.
If you're using Google Fonts, add &display=swap to the URL:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap" rel="stylesheet">
The preconnect hints tell the browser to open a connection to the font CDN early, shaving 100-300 ms off the request.
For even better performance, self-host your fonts and use <link rel="preload"> for the two or three weights you actually need:
<link rel="preload" href="/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/fonts/inter-bold.woff2" as="font" type="font/woff2" crossorigin>
I've seen FID drop by 200 ms just by preloading fonts, because the browser starts fetching them before it parses the CSS.
One last trick: use size-adjust, ascent-override, and descent-override in your @font-face to match the fallback font's metrics to the web font's. This minimizes layout shift when the swap happens. The Fallback Font Generator tool automates the math.
Measure, deploy, wait 24 hours
Run a Lighthouse test before you start. Note your LCP, FID, and CLS scores. Make the five changes above. Clear your CDN cache. Wait 24 hours for CrUX data to refresh in Search Console.
You won't hit perfect scores on every page—third-party scripts, ads, and embedded content will still cause shifts—but you should see LCP under 2.5s and CLS under 0.1 on most templates. If you're still above that, profile with Chrome DevTools Performance tab to find the next bottleneck: usually long tasks from JavaScript or slow server response times (TTFB).
Core Web Vitals are a floor, not a ceiling. They won't rescue a site with bad content or broken navigation. But when clients ask why their rankings dropped after a Google update, fixing these five things is where I start.
What to check first
If you only have 30 minutes, do this: add lazy loading with explicit dimensions, enable Brotli at your CDN, and convert your hero image to WebP. Those three changes alone will improve LCP on most sites. Then schedule an afternoon to inline critical CSS and fix font loading. Run Lighthouse again the next day and compare. When the scores are green, move on to fixing your server response time and minifying JavaScript—that's the next bottleneck.