Loading performance

Ship less, start sooner

Loading performance is the discipline of making the browser do less work before the page is useful. The fastest JavaScript is often the code you do not send, followed by code you send later, then code the browser can reuse on the next visit.

This lesson builds directly on bundlers, dynamic import, page lifecycle, Cache API and file storage, service workers, and engines and runtimes. It also links forward to measuring performance and keeping the main thread responsive.

JavaScript has a longer bill than many resources. A compressed file must download, decompress into source text, parse, compile, and execute. Images can be huge, but byte-for-byte a script usually asks more from the CPU and the main thread before the page responds.

The 2024 Web Almanac JavaScript chapter, published on March 3, 2025 from the June 2024 HTTP Archive crawl, reports median JavaScript payloads of 558 KB on mobile and 613 KB on desktop. The same chapter says mobile JavaScript grew 14% year over year. web.dev's JavaScript startup guidance reminds us that average mobile phones can have slow CPUs, limited cache, and memory pressure, so a fast office laptop is not representative.

Bundle analysis turns this into a team habit: list every entry and lazy chunk, label whether it is needed for the current route, set a budget, and fail pull requests when the budget grows without a conscious trade-off.

The next function is intentionally small, but it is real. It accepts a list of chunks and a budget, totals initial bytes, lazy bytes, total bytes, and estimated parse/compile time, then reports exactly which limit failed.

1function checkJavaScriptBudget(chunks, budget) {2  const initialCompressedKb = chunks3    .filter((chunk) => chunk.initial)4    .reduce((total, chunk) => total + chunk.compressedKb, 0);5  const asyncCompressedKb = chunks6    .filter((chunk) => !chunk.initial)7    .reduce((total, chunk) => total + chunk.compressedKb, 0);8  const totalCompressedKb = chunks9    .reduce((total, chunk) => total + chunk.compressedKb, 0);10  const totalUncompressedKb = chunks11    .reduce((total, chunk) => total + chunk.uncompressedKb, 0);12  const overBudget = [];13 14  if (initialCompressedKb > budget.maxInitialCompressedKb) {15    overBudget.push({16      name: "initial total",17      overByKb: initialCompressedKb - budget.maxInitialCompressedKb,18    });19  }20 21  for (const chunk of chunks) {22    if (!chunk.initial && chunk.compressedKb > budget.maxAsyncChunkCompressedKb) {23      overBudget.push({24        name: chunk.name,25        overByKb: chunk.compressedKb - budget.maxAsyncChunkCompressedKb,26      });27    }28  }29 30  if (totalCompressedKb > budget.maxTotalCompressedKb) {31    overBudget.push({32      name: "total JavaScript",33      overByKb: totalCompressedKb - budget.maxTotalCompressedKb,34    });35  }36 37  return {38    initialCompressedKb,39    asyncCompressedKb,40    totalCompressedKb,41    estimatedParseCompileMs: Math.round(42      totalUncompressedKb * budget.mobileParseCompileMsPerKb,43    ),44    overBudget,45  };46}47 48const chunks = [Run49  { name: "app-shell", compressedKb: 82, uncompressedKb: 250, initial: true },50  { name: "product-route", compressedKb: 63, uncompressedKb: 210, initial: true },51  { name: "charting-library", compressedKb: 118, uncompressedKb: 410, initial: false },52];53 54const budget = {55  maxInitialCompressedKb: 140,56  maxAsyncChunkCompressedKb: 90,57  maxTotalCompressedKb: 260,58  mobileParseCompileMsPerKb: 0.2,59};60 61const report = checkJavaScriptBudget(chunks, budget);62console.log(63  "initial " + report.initialCompressedKb + " KB, async " + report.asyncCompressedKb + " KB",64);65console.log(66  "over budget: " + report.overBudget67    .map((item) => item.name + " +" + item.overByKb + " KB")68    .join("; "),69);70console.log("estimated parse/compile " + report.estimatedParseCompileMs + " ms");

1function checkJavaScriptBudget(chunks, budget) {2  const initialCompressedKb = chunks3    .filter((chunk) => chunk.initial)4    .reduce((total, chunk) => total + chunk.compressedKb, 0);5  const asyncCompressedKb = chunks6    .filter((chunk) => !chunk.initial)7    .reduce((total, chunk) => total + chunk.compressedKb, 0);8  const totalCompressedKb = chunks9    .reduce((total, chunk) => total + chunk.compressedKb, 0);10  const totalUncompressedKb = chunks11    .reduce((total, chunk) => total + chunk.uncompressedKb, 0);12  const overBudget = [];13 14  if (initialCompressedKb > budget.maxInitialCompressedKb) {15    overBudget.push({16      name: "initial total",17      overByKb: initialCompressedKb - budget.maxInitialCompressedKb,18    });19  }20 21  for (const chunk of chunks) {22    if (!chunk.initial && chunk.compressedKb > budget.maxAsyncChunkCompressedKb) {23      overBudget.push({24        name: chunk.name,25        overByKb: chunk.compressedKb - budget.maxAsyncChunkCompressedKb,26      });27    }28  }29 30  if (totalCompressedKb > budget.maxTotalCompressedKb) {31    overBudget.push({32      name: "total JavaScript",33      overByKb: totalCompressedKb - budget.maxTotalCompressedKb,34    });35  }36 37  return {38    initialCompressedKb,39    asyncCompressedKb,40    totalCompressedKb,41    estimatedParseCompileMs: Math.round(42      totalUncompressedKb * budget.mobileParseCompileMsPerKb,43    ),44    overBudget,45  };46}47 48const chunks = [49  { name: "app-shell", compressedKb: 82, uncompressedKb: 250, initial: true },50  { name: "product-route", compressedKb: 63, uncompressedKb: 210, initial: true },51  { name: "charting-library", compressedKb: 118, uncompressedKb: 410, initial: false },52];53 54const budget = {55  maxInitialCompressedKb: 140,56  maxAsyncChunkCompressedKb: 90,57  maxTotalCompressedKb: 260,58  mobileParseCompileMsPerKb: 0.2,59};60 61const report = checkJavaScriptBudget(chunks, budget);62console.log(63  "initial " + report.initialCompressedKb + " KB, async " + report.asyncCompressedKb + " KB",64);65console.log(66  "over budget: " + report.overBudget67    .map((item) => item.name + " +" + item.overByKb + " KB")68    .join("; "),69);70console.log("estimated parse/compile " + report.estimatedParseCompileMs + " ms");

In production you would feed this kind of function from a bundler manifest, a stats file, or a CI artifact. This site is a Next.js static export, so each route has its own chunks, but this lesson does not quote local build numbers because a fresh production build was intentionally not run while the shared dev server is active.

Route-level splitting keeps the first page from downloading code for every other page. App frameworks such as Next.js make route chunks by default, and bundlers create more split points when they see import(). The key question is whether the user needs the code for the first useful task.

1const button = document.querySelector("#load-chart");2const output = document.querySelector("#chart-output");3 4button.addEventListener("click", async () => {5  button.disabled = true;6  output.textContent = "Loading chart code...";7  const chart = await import("./chart.js");8  chart.renderChart(output);9});

This is different from hiding work behind a timeout. The network request for chart.js does not start until the click handler reaches import(). The dynamic import lesson covers the promise and module namespace behavior in detail.

1<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>2<link rel="modulepreload" href="/assets/product-route.js">3<link rel="prefetch" href="/assets/settings-route.js" as="script">

Lazy loading is not only for JavaScript. Native loading="lazy" keeps below-the-fold images and iframes off the initial path. fetchpriority lets you tell the browser when a discovered resource is unusually important or unimportant, such as a likely LCP hero image versus a far-down product thumbnail.

1<img2  src="/products/chair.webp"3  alt="Oak chair"4  width="640"5  height="480"6  loading="lazy"7  decoding="async"8  fetchpriority="low"9>10 11<img12  src="/hero.webp"13  alt="New dashboard preview"14  width="1280"15  height="720"16  fetchpriority="high"17>

Script attributes decide whether HTML parsing stops, whether document order is preserved, and whether DOMContentLoaded waits. MDN summarizes the rules: async classic scripts fetch during parsing and evaluate as soon as available; defer scripts run after parsing and before DOMContentLoaded; module scripts defer by default; async modules are allowed.

The HTML specification is the source for those script-processing queues; MDN is the readable reference used here for the day-to-day rules. The simulator below encodes only those loading rules, not every network-priority or engine detail inside a browser.

1<script src="legacy.js"></script>2<script src="analytics.js" async></script>3<script src="app.js" defer></script>4<script type="module" src="routes.js"></script>5<script type="module" async src="independent-widget.js"></script>

CSS can be render-blocking too. A stylesheet in the document head can delay first paint until it arrives and is parsed. Splitting critical CSS, avoiding unused CSS, and not hiding the hero behind late styles matter alongside JavaScript loading.

1function simulateScriptTimeline(scripts, parserDuration = 100) {2  let parserDelay = 0;3  const events = [];4  const deferred = [];5 6  for (const script of scripts) {7    const discoveredAt = script.at + parserDelay;8    const readyAt = discoveredAt + script.downloadMs;9 10    if (script.kind !== "module" && !script.async && !script.defer) {11      events.push({ time: readyAt, label: "execute " + script.name });12      parserDelay += script.downloadMs + 1;13      continue;14    }15 16    if (script.async) {17      events.push({ time: readyAt, label: "execute " + script.name });18    } else {19      deferred.push({ ...script, discoveredAt });20    }21  }22 23  const parserDoneAt = parserDuration + parserDelay;24  let clock = parserDoneAt;25 26  for (const script of deferred) {27    const readyAt = script.discoveredAt + script.downloadMs;28    const startAt = Math.max(clock, readyAt);29    events.push({ time: startAt, label: "execute " + script.name });30    clock = startAt + 1;31  }32 33  events.sort((a, b) => a.time - b.time || a.label.localeCompare(b.label));34  return {35    executionOrder: events.map((event) => event.label.replace("execute ", "")),36    domContentLoadedAt: clock,37  };38}39 40const scripts = [Run41  { name: "analytics.js", at: 10, downloadMs: 70, async: true },42  { name: "vendor.js", at: 20, downloadMs: 40, defer: true },43  { name: "app.js", at: 30, downloadMs: 10, kind: "module" },44  { name: "legacy.js", at: 40, downloadMs: 20 },45];46 47const timeline = simulateScriptTimeline(scripts, 100);48console.log(timeline.executionOrder.join(" -> "));49console.log("DOMContentLoaded @" + timeline.domContentLoadedAt + "ms");

1<script src="dom-ready.js" defer></script>2<script src="feature.js" defer></script>

A good first load still matters, but repeat visits should not pay the same network bill. HTTP caching, content-hashed filenames, CDN edge caching, service worker strategies, bfcache, and V8 code caching all reduce different kinds of repeated work.

1Cache-Control: public, max-age=31536000, immutable2ETag: "app-shell.8f3a1c"3 4/assets/app-shell.8f3a1c.js  -> cache for a year5/assets/app-shell.91bd22.js  -> new URL after content changes

Cache-Control: max-age=31536000, immutable is safe only when a changed file gets a new URL. Without a content hash, users can stay stuck on old JavaScript. ETag and 304 Not Modified save response bytes after revalidation, but they still require a request. A CDN edge cache moves reusable responses closer to users, while browser caching removes many repeat requests completely.

1self.addEventListener("fetch", (event) => {2  const request = event.request;3 4  if (request.destination === "script") {5    event.respondWith(6      caches.open("static-v4").then(async (cache) => {7        const cached = await cache.match(request);8        if (cached) return cached;9        const response = await fetch(request);10        cache.put(request, response.clone());11        return response;12      }),13    );14  }15});

Service workers can make an app resilient and fast, but they are a programmable cache layer. The service workers lesson covers lifecycle, scope, cleanup, and offline fallbacks. The Cache API lesson explains why a named Cache stores Request to Response pairs and does not obey HTTP expiration automatically.

1// Avoid this pattern for analytics or cleanup.2window.addEventListener("unload", () => {3  navigator.sendBeacon("/analytics", "left page");4});5 6// Prefer signals that keep the back/forward cache available.7document.addEventListener("visibilitychange", () => {8  if (document.visibilityState === "hidden") {9    navigator.sendBeacon("/analytics", "hidden");10  }11});

The back/forward cache stores a whole page snapshot for instant history navigation. Global unload handlers are a classic bfcache breaker; prefer pagehide or visibilitychange for analytics and quick saves. Review page lifecycle before adding leave handlers.

Core Web Vitals are field metrics, not just lab scores. As of web.dev's Web Vitals guidance last updated October 31, 2024, a good page experience means LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile of page loads separately for mobile and desktop.

JavaScript can delay LCP by client-rendering the hero, by discovering the hero image only after hydration, or by loading critical CSS late. It can delay INP with long hydration tasks, big event handlers, and startup work. It can cause CLS by injecting banners, ads, or client content after layout without reserving space.

1const supported = "PerformanceObserver" in globalThis2  ? PerformanceObserver.supportedEntryTypes || []3  : [];4const watched = ["largest-contentful-paint", "layout-shift", "event"]5  .filter((type) => supported.includes(type));6 7console.log("Can watch: " + (watched.join(", ") || "none in this browser"));8 9if (watched.length > 0) {10  const observer = new PerformanceObserver((list) => {11    for (const entry of list.getEntries()) {12      console.log(entry.entryType + " @" + Math.round(entry.startTime));13    }14  });15  observer.observe({ type: watched[0], buffered: true });16  observer.disconnect();17}

In production, many teams use the web-vitals library because it handles browser differences and reports final metric values. It is not installed in this lesson, so the next block is a non-runnable usage shape.

1import { onCLS, onINP, onLCP } from "web-vitals";2 3onLCP((metric) => sendToAnalytics("LCP", metric.value));4onINP((metric) => sendToAnalytics("INP", metric.value));5onCLS((metric) => sendToAnalytics("CLS", metric.value));

Start every performance change by measuring. The measuring performance lesson shows marks, measures, DevTools traces, and RUM. The main thread lesson shows how long tasks hurt interaction. Loading performance uses those signals to decide what to remove, split, preload, or cache.

1. Open a bundle analyzer and list initial, async, and shared chunks for the slow route.
2. Record a Performance panel trace on a throttled mobile profile and inspect parse, compile, execute, and hydration time.
3. Set budgets for initial compressed JS, largest async chunk, total route JS, and long tasks.
4. Move optional work behind route boundaries or interaction-time import().
5. Use HTTP caching and content hashes for immutable assets; use service workers only when you can own cleanup.
6. Check LCP, INP, and CLS in field data after the change ships.

Common misconceptions

• “Gzip size is the only size that matters.” Transfer size matters, but parse, compile, memory, and execution follow the uncompressed source.
• “Lazy loading is automatically faster.” It is faster only when the delayed resource is not needed for the current view or task.
• “async is better than defer.” Async is for independent scripts. App code that depends on DOM order usually wants defer or modules.
• “A green Lighthouse run means real users are fine.” Lab scores are useful, but field data captures slow devices, background tabs, and real network conditions.
• “Caching fixes too much JavaScript.” Caching helps repeat visits; first visits, code changes, memory, and execution still pay.

Key takeaways

• JavaScript costs download, decompression, parse, compile, and execution.
• Budgets should track initial chunks, lazy chunks, total transfer, and CPU risk.
• Use route splitting and interaction-time import() only when the code is not needed for the first task.
• defer and module scripts preserve ordered startup; async is for independent work.
• HTTP caching, service workers, V8 code caching, and bfcache solve different repeat-visit problems.
• LCP, INP, and CLS must be confirmed with field data at the 75th percentile.

Next in the Performance module: Finding memory leaks, where you will use heap snapshots to find what keeps objects alive.