Website Speed Optimization: Core Web Vitals Guide

The Three Metrics

LCP, INP, CLS — what Google actually measures.

Google's Core Web Vitals are three specific metrics that determine whether your site passes their page experience evaluation. These directly affect rankings. Here's what each measures:

LCP (Largest Contentful Paint): How long until the biggest visible element loads. Target: under 2.5 seconds. This is usually your hero image, heading, or main content block. LCP above 4 seconds is rated "poor" and actively hurts your rankings.
INP (Interaction to Next Paint): How fast your site responds when someone clicks, taps, or types. Target: under 200 milliseconds. INP replaced FID in March 2024 and is stricter — it measures the worst interaction during the entire visit, not just the first one.
CLS (Cumulative Layout Shift): How much the page jumps around while loading. Target: under 0.1. Every time an ad loads, an image renders without dimensions, or a font swaps and changes text size — that's layout shift. Users hate it. Google penalizes it.

As of 2026, 57% of websites fail at least one Core Web Vital on mobile. The most common failure is LCP — sites simply take too long to show meaningful content. The root cause is almost always the same: too much code loading before the content.

The Root Cause

Why custom code eliminates 90% of speed issues.

Most website speed problems aren't caused by your content. They're caused by the software between your content and the browser. A typical WordPress or Webflow site loads:

150–400 KB of CSS (your page uses maybe 15 KB of it)
500 KB–2 MB of JavaScript (jQuery, slider libraries, analytics, chat widgets, font loaders)
A PHP framework or Node.js runtime processing templates before serving HTML
15–40 HTTP requests before the page is interactive

A custom-coded website serves exactly what the page needs. No framework overhead, no unused CSS from a theme that supports 200 layout options you don't use, no JavaScript libraries loaded "just in case."

The before/after numbers from real client projects:

WordPress site (before): LCP 4.8s, INP 380ms, CLS 0.24, Lighthouse 38
Custom rebuild (after): LCP 1.1s, INP 45ms, CLS 0.01, Lighthouse 97

That's not optimization — it's elimination. You don't speed up a bloated stack. You remove it.

Image Optimization

Images are the heaviest thing on your page. Treat them that way.

Images account for 40–60% of total page weight on most sites. Getting them right has outsized impact on LCP:

Format: Use WebP or AVIF. A 500 KB JPEG becomes 120 KB in WebP and 80 KB in AVIF with identical visual quality. Serve with <picture> element for fallback support.
Sizing: Never serve a 2000px image in a 400px container. Use srcset and sizes attributes to let the browser pick the right resolution for the device.
Loading: Add loading="lazy" to every image below the fold. For the LCP image (hero, main product), do the opposite — add fetchpriority="high" and preload it in the <head>.
Dimensions: Always set explicit width and height attributes. This reserves space during load and eliminates CLS from images. CSS can still make them responsive with max-width: 100%; height: auto;.

These four changes alone can cut page weight by 60% and improve LCP by 1–3 seconds. They cost nothing to implement on a custom site. On WordPress, you need a plugin — and then you need to hope it doesn't conflict with your other plugins.

Render-Blocking Resources

Every script in your <head> is a wall between the user and your content.

When a browser encounters a CSS or JavaScript file in the <head>, it stops rendering the page until that file downloads and executes. This is render-blocking, and it's the primary cause of slow LCP on technically functional sites.

The fixes, in order of impact:

Inline critical CSS: Extract the CSS needed for above-the-fold content and inline it directly in the HTML. Load the rest asynchronously. This eliminates the CSS round-trip for initial render.
Defer all JavaScript: Add defer or async to every script tag. If a script doesn't need to run before the page is visible, it shouldn't block rendering. Move analytics, chat widgets, and tracking scripts to load after DOMContentLoaded.
Eliminate unused code: Audit with Chrome DevTools Coverage tab. Most sites ship 60–80% unused CSS and 50–70% unused JavaScript. On custom sites, this waste doesn't exist because you only write what you use.
Font loading strategy: Use font-display: swap to show text immediately with a system font, then swap when the custom font loads. Preload your primary font file with <link rel="preload">.

Server response time matters too. If your server takes 800ms to respond (common with shared hosting running WordPress), your LCP can't possibly be under 2.5 seconds on a 3G connection. Aim for TTFB under 200ms — achievable with static hosting or a properly configured VPS.

Advanced Techniques

Code splitting, prefetching, and the performance ceiling.

Once the basics are handled, these techniques push scores from good to near-perfect:

Code splitting: Load JavaScript only for the features on the current page. A contact page doesn't need the gallery script. Route-based splitting with dynamic imports keeps each page lean.
Resource hints: Use dns-prefetch for third-party domains, preconnect for critical origins (fonts, CDN), and prefetch for likely next-page resources. Each shaves 50–200ms off future requests.
Service workers: Cache static assets for instant repeat visits. A properly configured service worker makes second visits load in under 500ms regardless of connection speed.
Edge caching: Serve pages from CDN nodes closest to the user. With Cloudflare or similar, your LA-hosted site loads in 100ms for an LA visitor instead of 400ms for a New York visitor hitting your origin server.

The performance ceiling for a well-built custom site is a Lighthouse score of 98–100 on both mobile and desktop. For a WordPress site with aggressive optimization, it's 75–85. The architectural overhead can't be fully optimized away — only removed by starting without it.

If your site is underperforming, start with a technical SEO audit that includes Core Web Vitals analysis. The bottleneck is usually obvious once you measure it.

Measuring Impact

Speed isn't a checkbox. It's a revenue lever.

The business case for speed optimization is well-documented:

Vodafone improved LCP by 31% and saw a 15% increase in lead-to-visit rate and an 11% increase in cart-to-visit rate
Pinterest reduced perceived wait time by 40% and saw a 15% increase in SEO traffic and signups
The BBC found they lost 10% of users for every additional second of page load time

For a local business in Los Angeles generating $50K/month from their website, a 15% improvement in conversion rate from speed optimization is $7,500/month in additional revenue. That dwarfs the one-time cost of building a fast site. The impact is especially dramatic for ecommerce websites, where every second of load time directly correlates to cart abandonment and lost sales.

The tools to measure your current state are free. Run Google PageSpeed Insights on your homepage and your top landing pages. Check the field data (real user metrics from CrUX), not just the lab data (simulated). Field data is what Google uses for ranking decisions.

If your field LCP is above 2.5 seconds or your INP is above 200ms, you're leaving both rankings and revenue on the table. The fix is either optimizing your current stack — which has diminishing returns if the architecture is the bottleneck — or rebuilding on a foundation that's fast by default.

Website speed optimization: the Core Web Vitals guide.