Website Performance Optimization: A Complete Checklist

Website performance is one of the few areas where "feels slow" and "measurably slow" point at the exact same, fixable technical causes. This checklist covers the concrete changes that move real performance numbers, not just theory.

Images: Usually the Biggest Win Available

<img src="/hero.webp" width="1200" height="600" loading="lazy" alt="...">

• Serve modern formats (WebP/AVIF) instead of raw JPEG/PNG — typically 25-50% smaller at equal visual quality
• loading="lazy" on any image below the fold — the browser skips downloading it until the user scrolls near it
• Explicit width/height attributes prevent layout shift as images load (covered fully in the Core Web Vitals guide)

JavaScript: Ship Less of It

// Code split anything not needed for the initial view
const AdminPanel = lazy(() => import('./AdminPanel'));

Run a bundle analyzer (webpack-bundle-analyzer, or Vite's built-in equivalent) at least once — it's routinely surprising how much unused code (an entire charting library imported for one small feature, a moment library imported for a single date format) is shipping to every single visitor.

Fonts: A Common, Overlooked Cost

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="...&display=swap">

display=swap shows fallback text immediately and swaps in the web font once it loads, rather than leaving text invisible while the font downloads ("Flash of Invisible Text") — a small change with an outsized effect on perceived load speed.

Caching Headers

Cache-Control: public, max-age=31536000, immutable   # for a hashed asset filename like app.a1b2c3.js
Cache-Control: no-cache                              # for the HTML document itself

Static assets with a content hash in the filename (which changes automatically whenever the content changes) can be cached essentially forever — the browser never needs to re-check, and a genuinely new version gets a genuinely new URL automatically.

Database and Server-Side Response Time

No amount of frontend optimization compensates for a backend that takes 2 seconds to respond. Add indexes on columns used in WHERE/ORDER BY clauses, eager-load relationships to avoid N+1 queries, and cache expensive, rarely-changing queries (product catalogs, navigation menus) with Redis.

Measure, Don't Guess

Run Lighthouse (built into Chrome DevTools) before and after any change — it's the only reliable way to confirm an optimization actually helped, rather than assuming it did based on how the page subjectively feels on a fast development machine and connection.