Web Performance Optimization Techniques

The page feels fine on your laptop over office Wi-Fi. Then someone opens it on a mid-range Android phone over 4G, stares at a blank screen while a 3 MB hero image and a pile of JavaScript download, and leaves. Search Console starts flagging "Poor URLs" for LCP, and nobody on the team is quite sure where to start.

This post is the order I'd work through it in: what Core Web Vitals actually measure, then images, JavaScript, CSS, caching, network tweaks, and the tools to check whether any of it helped.

Understanding Core Web Vitals

Before changing anything, you need to know which number you're trying to move. Google boils page experience down to three metrics: how fast the main content shows up, how quickly the page reacts to input, and how much the layout jumps around. They've been a ranking signal since 2021, though in practice they matter more for your users than for your position in search results.

Image Optimization

On most content sites, images are the heaviest thing on the page, often by a wide margin. That makes them the first place I look, because fixing them rarely requires touching application code.

Choose the Right Format

Implement Responsive Images

A phone that displays an image at 400px wide has no use for the 2000px original. Give the browser a few sizes and let it pick:

<!-- Using srcset for responsive images -->
<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w,
          hero-800.jpg 800w,
          hero-1200.jpg 1200w,
          hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  alt="Hero image"
  loading="lazy"
  decoding="async"
/>

<!-- Modern formats with fallback -->
<picture>
  <source srcset="image.avif" type="image/avif"/>
  <source srcset="image.webp" type="image/webp"/>
  <img src="image.jpg" alt="Description" loading="lazy"/>
</picture>

JavaScript Performance

A kilobyte of JavaScript costs more than a kilobyte of image. The image only has to be downloaded and decoded; the script has to be downloaded, parsed, compiled and executed, usually on the main thread, which is also where clicks get handled. That's why heavy bundles hurt INP as much as load time.

Loading Strategies

<script src="app.js"></script>

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

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

<script type="module" src="app.js"></script>

Code Splitting with Dynamic Imports

// Instead of importing everything upfront
// import { heavyModule } from './heavy-module';

// Load only when needed (dynamic import)
async function loadFeature() {
  const { heavyModule } = await import('./heavy-module');
  heavyModule.init();
}

// React lazy loading example
const Dashboard = React.lazy(() => import('./Dashboard'));

// Route-based splitting (React Router)
const routes = [
  {
    path: '/dashboard',
    element: (
      <Suspense fallback={<Loading />}>
        <Dashboard />
      </Suspense>
    )
  }
];

CSS Performance

The browser won't paint anything until it has downloaded and parsed every stylesheet in the <head>. So the goal is simple: make the CSS needed for the first screen tiny, and get everything else out of the way.

<head>
  <!-- Critical CSS inlined -->
  <style>
    /* Above-the-fold styles only */
    body{margin:0;font-family:system-ui}
    .header{background:#000;color:#fff;padding:20px}
    .hero{min-height:60vh;display:grid;place-items:center}
  </style>

  <!-- Non-critical CSS loaded async -->
  <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>

Caching Strategies

The fastest request is the one that never leaves the browser. Each layer below catches what the previous one missed, and each miss costs more time.

Cache-Control Headers

# Static assets - cache for 1 year (immutable with hash)
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary Accept-Encoding;
}

# HTML pages - revalidate each request
location ~* \.html$ {
    add_header Cache-Control "no-cache, must-revalidate";
    etag on;
}

# API responses - short cache with stale-while-revalidate
location /api/ {
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=300";
}

const CACHE_NAME = 'app-v1';
const STATIC_ASSETS = [
  '/',
  '/css/main.css',
  '/js/app.js',
  '/images/logo.svg'
];

// Cache-First Strategy
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then(cached => cached || fetch(event.request))
  );
});

// Stale-While-Revalidate Strategy
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open(CACHE_NAME).then(async (cache) => {
      const cached = await cache.match(event.request);
      const fetched = fetch(event.request).then((response) => {
        cache.put(event.request, response.clone());
        return response;
      });
      return cached || fetched;
    })
  );
});

Network Optimizations

Most of these are server or hosting settings rather than code changes, so they're cheap to try:

<head>
  <!-- Preconnect to critical third-party origins -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link rel="preconnect" href="https://cdn.example.com">
  
  <!-- DNS prefetch for less critical origins -->
  <link rel="dns-prefetch" href="https://analytics.example.com">
  
  <!-- Preload critical resources -->
  <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
  
  <!-- Prefetch next page for likely navigation -->
  <link rel="prefetch" href="/next-page.html">
</head>

Go easy on preload. Everything you preload competes with everything else for bandwidth, and if a preloaded file isn't used soon after load, Chrome logs "The resource ... was preloaded using link preload but not used within a few seconds". Fonts are the classic trap: leave off crossorigin and the browser downloads the font twice.

Performance Measurement Tools

Lab tools like Lighthouse run on one simulated device and are good for debugging. Field data comes from real visitors and is what Google actually uses. You want both, and when they disagree, trust the field data:

import { onCLS, onINP, onLCP, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics({ name, delta, id }) {
  // Send to your analytics endpoint
  navigator.sendBeacon('/analytics', JSON.stringify({
    metric: name,
    value: delta,
    id: id,
    page: window.location.pathname
  }));
}

// Measure all Core Web Vitals
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

Performance Checklist

I go through this list when auditing a site. Most of it can be checked in an afternoon:

Where I'd Start

If you only have a day, these give the most back for the least effort:

Mistakes I See Most Often (and When Not to Bother)

Chasing a Lighthouse score of 100. Lighthouse runs one throttled load on one simulated device. If your field data in Search Console or CrUX is already "good" for all three metrics, squeezing out the last few lab points is rarely worth a week of work.

Optimizing before measuring. It's easy to spend days on a service worker when the real problem is an uncompressed 2 MB hero image or a chat widget blocking the main thread. Open the Network and Performance panels first and fix the biggest bar in the waterfall.

Adding a service worker you don't need. For a marketing site or blog, good Cache-Control headers and a CDN get you most of the benefit. A service worker adds a cache you have to version and invalidate, and a buggy one can keep serving stale pages until users clear site data. I'd only reach for one if you need offline support or have an app shell that really benefits.

Code splitting everything. Splitting a small app into dozens of tiny chunks can make things slower, since each chunk is another request and another waterfall step. Split by route and by heavy, rarely used features (editors, charts, maps), not by every component.

Fixing it once and never checking again. Performance regresses quietly: a new tracking script here, an unoptimized upload there. Send the web-vitals data to your analytics and look at it after big releases, or add a Lighthouse CI budget so a pull request fails when the bundle grows past a limit.

Written by Mayur Dabhi

Full Stack Developer passionate about building fast, accessible, and user-friendly web applications with modern technologies.