Skip to main content
Core Web Vitals affect SEO rankings and conversion rates directly. Slow sites lose users — and Google ranks them lower. This guide walks through measuring, identifying bottlenecks, and fixing the most common issues.

​
The Three Metrics

LCP

Largest Contentful Paint. Target < 2.5s.

INP

Interaction to Next Paint. Target < 200ms.

CLS

Cumulative Layout Shift. Target < 0.1.
  • LCP — how fast the main content renders
  • INP — how responsive the page feels to taps and clicks
  • CLS — whether content jumps around as the page loads

​
Step 1: Measure First

Never guess. Before touching anything, get a baseline.
Use the built-in AI SEO Site Audit. It runs Lighthouse against your live site and returns Core Web Vitals scores with prioritized fixes.
Always test on mobile first. Real mobile devices are much slower than your laptop, and mobile scores are what Google uses for rankings. Desktop scores inflate your confidence.

​
LCP Improvements

The hero section usually drives LCP. Focus there first.
  • Optimize images — convert to WebP or AVIF, serve at correct dimensions, always set width and height attributes
  • Preload the hero image — <link rel="preload" as="image" href="/hero.webp"> in <head>
  • Remove render-blocking JS — defer third-party scripts with async or defer
  • Use a CDN — Hiveku deploys to CloudFront automatically, but custom domains need proper cache headers
  • Reduce server response time — slow APIs mean slow pages. Check server timing in DevTools Network tab
<!-- Good: explicit dimensions, modern format, eager loading for hero -->
<img 
  src="/hero.webp" 
  width="1200" 
  height="600" 
  alt="Hero" 
  loading="eager" 
  fetchpriority="high" 
/>

​
INP Improvements

INP measures how fast the page responds to user input. Slow JavaScript is almost always the culprit.
  • Break up long tasks — split 200ms+ operations into smaller chunks with setTimeout or requestIdleCallback
  • Debounce expensive handlers — especially onScroll, onInput, onResize
  • Move work off the main thread — Web Workers for heavy computation, server for data crunching
  • Defer non-critical third-party scripts — chat widgets, analytics, A/B test tools
The “Performance” tab in Chrome DevTools shows you exactly which handlers are blocking the main thread. Record an interaction, find the long task, optimize the handler.

​
CLS Improvements

CLS penalizes layout shifts that happen after initial render. Most fixes are structural.
  • Always set width and height on images, videos, iframes, and embeds
  • Reserve space for ads and lazy-loaded content — empty <div style="min-height: 250px"> placeholders
  • Avoid injecting content above the fold after initial render (cookie banners, notification bars)
  • Use font-display: optional for custom fonts to prevent FOUT-based layout shift
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2');
  font-display: optional;
}

​
Hiveku-Specific Tips

1

Enable Site Enhancements

Go to Publishing > Enhancements and enable the performance bundle — optimized cache headers, preload hints, compression. See Site Enhancements.
2

Use Next.js Image component

If your site is Next.js, switch <img> to <Image> for automatic optimization (WebP conversion, responsive srcset, lazy loading).
import Image from 'next/image';

<Image src="/hero.webp" width={1200} height={600} alt="Hero" priority />
3

Dynamic import heavy components

const Chart = dynamic(() => import('./Chart'), { ssr: false });
Keeps the initial bundle small and defers loading until the component is actually needed.
4

Keep Lambda bundles lean

Under 1MB is ideal for cold start performance. Audit dependencies — a moment or lodash full import can single-handedly double bundle size. Use date-fns and lodash submodules instead.

​
Image Optimization Walkthrough

1

Audit existing images

In DevTools Network tab, filter by image type, sort by size. Anything over 500KB is a candidate.
2

Convert to WebP or AVIF

Use sharp, ImageMagick, or an online tool. WebP is universally supported; AVIF is smaller but slightly less compatible.
3

Use responsive srcset

<img 
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  width="800" height="400"
/>
4

Lazy-load below the fold

<img src="/later.webp" loading="lazy" width="400" height="300" />
Don’t lazy-load the hero — that hurts LCP.

​
Third-Party Script Audit

Run Lighthouse. Look at the “Third-party usage” section. Anything taking over 500ms of main thread time is a candidate for:
  • Defer — load after the page is interactive (chat widgets, analytics)
  • Replace — swap heavy tools for lighter ones (Plausible instead of Google Analytics if privacy + perf matter more than integrations)
  • Remove — if nobody uses it, it shouldn’t be loading
Chat widgets, cookie consent banners, and A/B testing tools are the top three CLS offenders. Audit them specifically — they often inject content above the fold after the page renders, which tanks both LCP and CLS.

​
Cache Strategy

Hiveku’s CDN caches static assets by default. For maximum effect:
  • Versioned assets — set Cache-Control: max-age=31536000, immutable. Asset URLs change with each deploy, so the browser caches forever with no staleness risk.
  • HTML — shorter cache (e.g., 60s) or no-cache with ETag validation so updates appear fast
  • API responses — cache carefully. Use Cache-Control: private, max-age=60 for user-specific data, public cache for non-personalized

​
Verify It Worked

  1. Run Lighthouse before making changes — note your baseline scores
  2. Deploy optimizations
  3. Run Lighthouse again on the same page
  4. Target 90+ on Performance for mobile
  5. Confirm LCP < 2.5s, INP < 200ms, CLS < 0.1
Don’t stop at Lighthouse — real-user data lives in Google Search Console’s Core Web Vitals report (or PageSpeed Insights with the CrUX field data panel). That’s what affects rankings.

​
Troubleshooting

A render-blocking script is the usual culprit. In DevTools Network, filter by “JS” and look at what’s loading before the hero image — anything with high priority that isn’t essential is blocking paint. Defer it or remove it. Alternatively, server response time is too high — check Time to First Byte in the waterfall.
Profile the interaction in DevTools Performance tab. Record, click the slow element, stop recording. The flame chart shows exactly which function is eating the main thread. Common offenders: large state updates, synchronous DOM queries inside loops, analytics firing on every click.
Something you added is inserting content dynamically above the fold. Most common causes: a new chat widget, a cookie consent banner, a notification bar, or a late-loading hero image without fixed dimensions. Compare the “Before” and “After” diagnostic screenshots in Lighthouse.
Lighthouse is synthetic (simulated). CrUX is real users with their real networks and devices. Improvements take 28 days to fully reflect in CrUX because it’s a rolling window. If the gap is large, your synthetic test conditions don’t match your real users — try throttling harder (3G, slow CPU) to match actual field conditions.
Lighthouse may be complaining about dimensions (served larger than displayed), not file size. Check the Lighthouse report details — it tells you the exact mismatch. Serve the right size for each breakpoint with srcset.

​
What’s Next?

SEO Audit

Run a full SEO + performance audit with the AI

Site Enhancements

Enable optimized headers, caching, and compression