A
AgiCAD
Menu
AgiCAD Home
Performance April 22, 2026 · 13 min read

Web Performance Optimization: A Practical Guide for 2026

Slow websites cost revenue, hurt SEO rankings, and drive users away. This guide covers the techniques that produce the biggest real-world improvements — Core Web Vitals, image optimization, caching, and modern JavaScript loading strategies.

A 100ms improvement in page load time correlates with a 1% increase in revenue — that's the Amazon figure from 2006 that kick-started the web performance industry. Twenty years later, the relationship between speed and business outcomes is even better documented. Google's data shows that a 1-second delay in mobile page load increases bounce rates by 32%. For e-commerce, every second of load time can translate to a 7% reduction in conversions.

Performance optimisation is no longer optional for serious web applications. It affects user experience, search engine rankings (Google's Core Web Vitals are a ranking factor), and directly measurable business metrics. This guide covers the highest-impact techniques — the changes that produce real, measurable improvements rather than micro-optimisations that look good in benchmarks but don't move the needle in production.

Understanding Core Web Vitals

Google's Core Web Vitals are a set of metrics that measure real-world user experience. Since 2021, they have been a ranking factor in Google Search. As of 2026, the three primary metrics are:

  • Largest Contentful Paint (LCP): Measures loading performance. LCP marks the point when the largest visible content element (typically a hero image or large text block) finishes rendering. Target: under 2.5 seconds.
  • Interaction to Next Paint (INP): Replaced First Input Delay in 2024. Measures responsiveness — the time from any user interaction (click, tap, key press) to the next visual update. Target: under 200ms.
  • Cumulative Layout Shift (CLS): Measures visual stability — how much the page layout shifts unexpectedly during loading. Target: under 0.1.

Measure your current Core Web Vitals using PageSpeed Insights, Chrome DevTools Performance panel, or the Search Console Core Web Vitals report. Always use real user data (field data) rather than lab data alone — real-world network conditions differ dramatically from localhost.

Image Optimization: The Highest-Impact Change

Images typically account for 50–80% of a web page's total byte size. Optimising images is almost always the highest-impact performance improvement available, with the lowest implementation risk.

Use modern image formats

WebP provides 25–35% smaller file sizes than JPEG at equivalent quality. AVIF (supported in all modern browsers since 2023) provides 40–60% smaller files than JPEG. Serve AVIF with WebP as fallback using the <picture> element:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600"
       loading="lazy" decoding="async">
</picture>

Specify image dimensions and use lazy loading

Always include width and height attributes on images. This allows the browser to reserve space before the image loads, preventing layout shifts (fixing CLS). Add loading="lazy" for images below the fold — the browser will defer loading them until the user scrolls near them.

Exception: the LCP image should have loading="eager" (the default) and ideally a <link rel="preload"> in the document head to ensure it starts loading as early as possible.

<!-- In <head>: preload the LCP image -->
<link rel="preload" as="image" href="hero.avif" type="image/avif">

<!-- Below-fold images: lazy load -->
<img src="feature.webp" alt="Feature" width="800" height="450"
     loading="lazy" decoding="async">

Responsive images with srcset

Serving a 2400px wide image to a mobile user who needs a 400px wide image wastes 97% of the bandwidth. Use srcset and sizes attributes to let the browser select the appropriate size:

<img
  srcset="image-400.webp 400w,
          image-800.webp 800w,
          image-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  src="image-800.webp"
  alt="Description"
  width="800" height="450">

JavaScript: Load Less, Load Smarter

JavaScript is the heaviest performance cost in modern web applications — not just its byte size, but the parsing, compilation, and execution time required before the browser can interact with it. Reducing JavaScript is the most impactful thing you can do for INP and Time to Interactive.

Code splitting and dynamic imports

Modern bundlers (Vite, webpack, Rollup) support code splitting: dividing your JavaScript bundle into smaller chunks that load on demand. Instead of loading your entire application upfront, load only the code needed for the current page:

// Instead of a static import at the top of the file:
// import { HeavyChart } from './charts';

// Use a dynamic import when the component is needed:
const loadChart = async () => {
  const { HeavyChart } = await import('./charts');
  new HeavyChart('#chart-container');
};

document.querySelector('#show-chart').addEventListener('click', loadChart);

defer and async script loading

Scripts with defer download in parallel with HTML parsing and execute after parsing completes — in order. Scripts with async also download in parallel but execute as soon as downloaded, potentially out of order. Use defer for most scripts, async for fully independent scripts like analytics.

<!-- defer: downloads in parallel, executes after HTML parsed, in order -->
<script src="app.js" defer></script>

<!-- async: downloads in parallel, executes immediately when ready -->
<script src="analytics.js" async></script>

Caching: Serve from Cache When Possible

Effective caching is one of the highest-leverage performance improvements because cached resources have a transfer cost of zero. Getting your caching strategy right can reduce repeat-visit load times by 80–90%.

HTTP Cache-Control headers

Different asset types require different caching strategies:

# Nginx configuration example

# Fingerprinted static assets (CSS, JS with content hash in filename)
# Cache aggressively — the URL changes when content changes
location ~* \.(js|css)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

# Images with fingerprinting
location ~* \.(webp|avif|jpg|png|svg|gif)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

# HTML files — don't cache (or cache briefly with revalidation)
location ~* \.html$ {
  add_header Cache-Control "no-cache";
}

# API responses — typically no cache or short cache
location /api/ {
  add_header Cache-Control "no-store";
}

The key pattern: use content hashing in your asset filenames (most build tools do this automatically: app.3f4a1b.js). This lets you cache assets for a full year (max-age=31536000) safely — when content changes, the filename changes, and browsers fetch the new version.

Service Worker caching

Service Workers allow sophisticated caching strategies impossible with HTTP headers alone — including offline support and background sync. For content-heavy sites, a Cache-First strategy for static assets combined with a Network-First strategy for HTML/API responses can dramatically improve repeat visit performance.

Libraries like Workbox (from Google) provide pre-built caching strategies that integrate with common build tools and remove most of the complexity of writing Service Worker code manually.

CDN Configuration and Edge Delivery

A Content Delivery Network delivers your static assets from servers geographically close to each user, reducing latency. For a user in Tokyo accessing a server in Frankfurt, DNS lookup + TCP + TLS alone can consume 200ms before a single byte is transferred. A CDN node in Tokyo brings this to under 10ms.

Key CDN configuration principles:

  • Serve all static assets (images, CSS, JS, fonts) through the CDN
  • Enable Brotli compression at the CDN level (typically 15–25% smaller than gzip)
  • Configure the CDN to serve AVIF/WebP based on the Accept header, enabling format negotiation without changing HTML
  • Use CDN edge caching for HTML pages where possible — many CDNs (Cloudflare, Fastly, Vercel Edge) can cache and serve entire pages from the edge
  • Preconnect to your CDN domain in your HTML head: <link rel="preconnect" href="https://cdn.example.com">

Database and Server-Side Performance

Front-end optimisations improve perceived performance but don't help if the server takes 2 seconds to generate a page. Common server-side performance issues:

  • N+1 query problem: Loading a list of 100 items and then making a separate database query for each one. Fix with eager loading (Django's select_related() / prefetch_related(), Laravel's with()).
  • Missing database indexes: Queries filtering on unindexed columns perform sequential table scans. Use EXPLAIN ANALYZE to identify them.
  • Absence of HTTP caching for rendered pages: If your database-driven pages change infrequently, server-side caching (Redis, Memcached, or a full-page cache) can serve them in under 5ms regardless of database complexity.

Measuring and Monitoring Performance in Production

Lab testing with tools like PageSpeed Insights gives you a snapshot, but production performance is what matters. Real User Monitoring (RUM) captures actual user experience across all network conditions, devices, and geographies.

The Web Vitals JavaScript library (available from Google) can be installed in any web application to collect LCP, INP, and CLS data from real users and send it to your analytics platform:

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

function sendToAnalytics({ name, value, id }) {
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify({ name, value, id }),
    keepalive: true,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Tracking these metrics continuously — and correlating them with business outcomes like conversion rate — closes the loop between performance work and business impact. Set up alerts for regressions: a performance regression discovered within hours of a deployment is far cheaper to fix than one discovered after a week in production.

Web performance optimisation is a continuous process rather than a one-time project. The web platform evolves, user expectations rise, and new features introduce new performance costs. Building performance awareness into your development culture — through automated testing, regular audits, and clear ownership of performance metrics — is what sustains fast applications over time.