Web Performance Optimization: Best Practices for 2024

Performance is a feature. A site that loads in one second converts measurably better than one that takes five, and Google now uses page experience as a ranking signal. The good news is that most performance problems come from a short list of causes, and each has a well-understood fix. This guide walks through the metrics that matter and the practical steps that move them.

Core Web Vitals: The Numbers You're Graded On

Google's Core Web Vitals are the three metrics that summarize real-world user experience. They're what Search Console reports and what you should optimize first.

Largest Contentful Paint (LCP)

LCP measures how long the largest visible element — usually a hero image or headline — takes to render.

• Target: under 2.5 seconds.
• Common causes: slow server response, render-blocking CSS/JS, unoptimized hero images.
• Fixes: serve from a CDN, preload the hero image, and inline critical CSS so the browser can paint without waiting on a stylesheet.

Interaction to Next Paint (INP)

INP replaced First Input Delay in 2024. It measures how quickly the page responds to all interactions, not just the first — a much more honest measure of "does this page feel sluggish."

• Target: under 200 milliseconds.
• Fixes: break up long JavaScript tasks, defer non-essential work, and avoid doing heavy computation on the main thread. Moving expensive work into a web worker keeps the UI responsive.

Cumulative Layout Shift (CLS)

CLS measures how much the page jumps around as it loads — the frustrating experience of tapping a button that moves at the last moment.

• Target: under 0.1.
• Fixes: always set width and height (or aspect-ratio) on images and video, reserve space for ads and embeds, and avoid inserting content above existing content.

Image Optimization

Images are almost always the largest thing on a page, which makes them the highest-leverage place to optimize.

Modern Image Formats

Switching formats is a free win — same picture, far fewer bytes:

• WebP: roughly 25–35% smaller than JPEG.
• AVIF: up to 50% smaller than JPEG at similar quality.

Use the <picture> element so the browser picks the best format it supports and falls back gracefully:

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="Description" width="1200" height="675" />
</picture>

Note the explicit width and height — that's your CLS insurance.

Lazy Loading

Load below-the-fold images only when the user scrolls toward them. It's one attribute:

<img src="image.jpg" loading="lazy" alt="Description" />

Do not lazy-load your LCP image, though — that delays the very thing you're trying to render fast.

Responsive Images

Serve appropriately sized images per device with srcset so a phone never downloads a 2000px desktop image:

<img
  src="medium.jpg"
  srcset="small.jpg 640w, medium.jpg 1024w, large.jpg 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Description"
/>

Ship Less JavaScript

JavaScript is the most expensive resource on the web because the browser has to download, parse, and execute it. Reducing it improves both load and INP.

Code Splitting and Tree Shaking

• Code splitting: load only the code a route needs, rather than one giant bundle. Modern frameworks do this at the route level automatically.
• Tree shaking: your bundler drops unused exports — but only if you import specifically (import { debounce } from 'lodash-es') rather than importing the whole library.
• Minification: strips whitespace and shortens names, typically cutting bundle size significantly.

Defer Non-Critical Scripts

Analytics, chat widgets, and third-party embeds should never block rendering:

<script src="analytics.js" defer></script>

CSS Optimization

• Critical CSS: inline the styles needed for above-the-fold content so the first paint doesn't wait on a stylesheet request.
• Purge unused CSS: tools like Tailwind's compiler or PurgeCSS remove classes you never use.
• Compression: enable Brotli (or Gzip) on your server — it typically shrinks text assets by 70% or more.

Caching Strategies

Caching is how you avoid doing the same work twice.

Browser Caching

Set long cache lifetimes for versioned static assets so returning visitors download nothing:

Cache-Control: public, max-age=31536000, immutable

The immutable directive tells the browser it never needs to revalidate — safe when your build tool adds content hashes to filenames.

CDN

A Content Delivery Network serves your assets from an edge location physically close to the user, cutting round-trip time. For a global audience this is one of the biggest single improvements available.

Monitoring and Measurement

You can't improve what you don't measure, and lab tools alone can lie — they run on fast hardware and fast networks.

Tools

• Google PageSpeed Insights — combines lab and real-world (field) data.
• Lighthouse — built into Chrome DevTools for quick local audits.
• WebPageTest — deep waterfall analysis and filmstrip views.
• Real User Monitoring (RUM) — captures performance from your actual visitors, which is what Google ultimately grades you on.

Always validate improvements with field data, not just a one-off Lighthouse score.

Conclusion

Web performance optimization is an ongoing discipline, not a one-time task. Start where the leverage is highest: optimize your images, ship less JavaScript, and get your Core Web Vitals into the green. Then set up real-user monitoring so regressions surface before your users complain.

Pick a single page, run it through PageSpeed Insights today, and fix the top recommendation. Measurable wins compound — and every millisecond counts.