🚦 Network Analysis and Performance

Why Network Performance Matters

Think of network performance as the highway system for your web application. A beautiful app that arrives slowly feels broken — users bounce, conversions drop, and search rankings slip. The good news is that most slowness is visible and measurable the moment you open your browser's developer tools.

Performance work is a loop, not a one-time chore: you measure what's happening, diagnose the biggest offender, apply a fix, then measure again to confirm the win. Everything in this lesson feeds that loop.

The Request–Response Lifecycle

Before you can analyze network traffic, you need a mental model of how a browser and a server talk. When you type an address and press Enter, a predictable sequence of steps unfolds.

Broken into steps, every interaction follows this pattern:

1. DNS resolution — the domain name is translated into an IP address (cached after the first lookup).
2. Connection setup — a TCP connection is opened, plus a TLS handshake for HTTPS.
3. Request sent — the browser transmits an HTTP request with a method, headers, and possibly a body.
4. Server processing — the server does its work (queries a database, renders a template) and builds a response.
5. Response received — the server streams the response back; the browser parses, renders, and requests any further resources it discovers.

🍽️ A useful analogy: Loading a page is like ordering a multi-course meal. Your first request is the menu (the HTML). Once you read it, you place follow-up orders for each dish (CSS, JS, images). A complex page, like a complex meal, needs many trips to the kitchen — and the slowest dish sets the pace of the whole dinner.

HTTP: Methods, Status Codes & Headers

HTTP (HyperText Transfer Protocol) is the language every web request speaks. Three parts of it show up constantly in the Network panel: the method, the status code, and the headers.

HTTP methods

A social app maps neatly onto these: GET the feed, POST a new post, PATCH an edit, DELETE a post — each method signals a different intent to the server.

Status codes

The first digit of a status code tells you the category at a glance:

• 2xx — Success: 200 OK, 201 Created, 204 No Content
• 3xx — Redirection: 301 Moved Permanently, 302 Found, 304 Not Modified (a cache win — the browser reused what it had)
• 4xx — Client error: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
• 5xx — Server error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

Headers worth knowing

A team once cut load time roughly 30% purely by tuning Cache-Control and ETag so browsers reused files instead of re-downloading them. Headers are where much of your caching strategy lives.

Reading the Network Panel

Open DevTools (F12 or Ctrl+Shift+I), click Network, and reload the page. You'll see every request in a table, with a summary of totals along the bottom.

Filtering to find the signal

• Type filters: the buttons for Fetch/XHR, JS, CSS, Img, Font, Doc narrow the list instantly.
• Property filters: type queries like status-code:404 or method:POST.
• Negation: prefix with a minus sign, e.g. -status-code:200 to see everything that didn't succeed.
• Combine with spaces (logical AND): method:POST larger-than:10k finds large POST requests.

To isolate flaky API calls, a filter like status-code:500 method:POST can surface a pattern in seconds that would take ages to spot by eye.

The waterfall chart

Click any request and open its Timing tab, or read the waterfall column directly. Each bar breaks a request into phases:

Key phases to read:

• Queuing / Stalled: the request is waiting its turn (browser connection limits, prioritization).
• DNS + Connect + TLS: one-time setup cost per origin.
• Waiting (TTFB): Time To First Byte — how long the server took to start responding.
• Content Download: how long the bytes took to arrive — driven by file size and compression.

A long TTFB says "look at the server or your CDN." A long download bar says "this file is too big — compress it, resize it, or split it." One team traced a slow product page to a fat TTFB, added a Redis cache in front of their database, and cut API response times dramatically.

Core Web Vitals

Old metrics like "page load time" measure when the browser technically finished, not when the page felt ready. Google's Core Web Vitals fix that by measuring the user's actual experience across three axes: loading, interactivity, and visual stability.

Largest Contentful Paint (LCP)

LCP marks when the largest element in the viewport — usually a hero image or big headline — becomes visible. Good target: ≤ 2.5 s. Common fixes are compressing and preloading the hero image and removing render-blocking resources ahead of it.

Interaction to Next Paint (INP)

INP replaced First Input Delay as a Core Web Vital in March 2024. Where FID only measured the delay of the first interaction, INP looks at the responsiveness of interactions throughout the page's life, reporting the worst typical case. Good target: ≤ 200 ms. Poor INP usually traces to long JavaScript tasks blocking the main thread — break them up, defer non-critical scripts, and move heavy work to a Web Worker.

Cumulative Layout Shift (CLS)

CLS quantifies unexpected movement — the maddening jump when an image or ad loads late and shoves the button you were about to tap. Good target: ≤ 0.1. The cure is reserving space up front: set width/height (or aspect-ratio) on media, and pre-allocate space for anything injected later. One store cut CLS from 0.42 to 0.08 just by adding image dimensions, and mis-clicks on "Add to Cart" fell sharply.

High-Impact Optimizations

Once you can measure, these are the moves that consistently deliver the biggest wins per hour of effort.

1. Serve images in modern formats and the right size

Images are usually the heaviest thing on a page. Prefer AVIF or WebP over JPEG/PNG, serve responsive sizes, and lazy-load anything below the fold:

<img
  src="hero-800.avif"
  srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1600.avif 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="1600" height="900"
  alt="Product on a wooden table">

<!-- Below the fold: let the browser defer the download -->
<img src="review.avif" loading="lazy" width="600" height="400" alt="Customer review">

Note the explicit width and height — they double as your CLS insurance.

2. Cache aggressively with the right headers

Static, fingerprinted assets can be cached essentially forever; HTML should revalidate. Set this on the server:

# Fingerprinted assets that never change (app.9f2a1c.js)
Cache-Control: public, max-age=31536000, immutable

# HTML that may change — always revalidate
Cache-Control: no-cache

Pair long cache lifetimes with cache busting: a build tool renames app.js to app.9f2a1c.js whenever its contents change, so returning visitors reuse everything except what actually updated.

3. Stop render-blocking resources

A <script> in the <head> without defer blocks parsing. Inline the tiny bit of CSS needed for the first screen, and defer the rest:

<script src="critical.js" defer></script>   <!-- runs after HTML parses, in order -->
<script src="analytics.js" async></script>  <!-- runs whenever it arrives -->

Use defer for app code that depends on the DOM, and async for independent third-party scripts like analytics.

4. Tame third-party scripts

Widgets, chat bubbles, and ad tags are often the single worst offenders because they run on someone else's server. Audit them in the Network panel, load them async, self-host where licensing allows, and lazy-load on interaction. One marketing team removed 2.3 s of load time by replacing heavy social widgets with lightweight buttons that only pulled the real script when clicked.

Resource Hints & Preloading

Resource hints let you tell the browser about work it will need soon, so it can start early. Use them surgically.

<!-- Warm up a connection to your API or CDN -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>

<!-- Preload a critical font to avoid invisible text -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

<!-- Preload the LCP hero image -->
<link rel="preload" href="/hero-800.avif" as="image">

<!-- Prefetch the page the user will probably visit next -->
<link rel="prefetch" href="/product-details.html">

Hands-on Exercise & Quiz

Summary

📚 Further Reading

• web.dev — Web Vitals
• Chrome DevTools — Network features reference
• MDN — HTTP response status codes
• WebPageTest — advanced performance testing

🚀 What's Next?

Now that you can spot where a page is slow or broken over the network, the next lesson — Debugging in the Browser — teaches you to find why your JavaScript misbehaves, using breakpoints, the console, and a systematic debugging process.