Network performance end to end

HTTP & the web · Expert · 16 min

At scale, round trips rather than bandwidth dominate load time, and protocol-level fixes beat code micro-optimisations.

For most web requests latency, not bandwidth, dominates. Every round trip costs the RTT (tens of ms on a good connection, hundreds on mobile or across continents), and a cold request pays for DNS, TCP, TLS and then the request itself. Work on reducing round trips first.

Reuse and pre-warm connections. Keep-alive and HTTP/2 or 3 reuse one connection. Avoid needless extra origins: each costs a new handshake. For third parties you need, <link rel="preconnect"> performs DNS, TCP and TLS early.

Send less, sooner:

  • Compress text with Brotli or zstd (Content-Encoding: br/zstd).
  • Use modern image formats and responsive sizes.
  • TCP slow start means a new connection can only send about 14 KB in the first round trip, so a small critical HTML head and inlined critical CSS paint faster.

Server think time. 103 Early Hints lets a server send Link: </app.css>; rel=preload headers while it is still generating the page, so the browser starts fetching critical assets during the wait. Streaming HTML (flushing the head early) has a similar effect.

Prioritisation. HTTP/2 and 3 browsers prioritise CSS and fonts over images; the Priority header and fetchpriority attribute adjust it.

Avoid the request entirely. Long-lived caching, service workers, prefetching likely next pages with speculation rules, and CDNs close to users.

Measure with real-user monitoring (Core Web Vitals such as TTFB and LCP) and the Network panel's timing breakdown: queueing, DNS, connect, TLS, waiting (TTFB) and content download.

Example

# Where does the time go? (cumulative timings)
$ curl -so /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
dns:0.004 connect:0.031 tls:0.068 ttfb:0.152 total:0.153

# Compression: compare transferred sizes
$ curl -so /dev/null -w "%{size_download}\n" https://example.com/app.js
$ curl -so /dev/null -w "%{size_download}\n" -H "Accept-Encoding: br" https://example.com/app.js

# 103 Early Hints sent before the final response
HTTP/1.1 103 Early Hints
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Remember

  • Latency and round trips usually dominate, not bandwidth
  • Reuse connections; preconnect to required third parties
  • 103 Early Hints uses server think time to start fetching assets
  • Measure TTFB and LCP from real users

Watch out for

  • Optimising bytes while the page still waits on several sequential round trips to different origins.

Check yourself

  1. A page fetches a script from a new third-party origin discovered late. Which hint removes the most setup latency?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: developer.mozilla.org/en-US/docs/Web/Performance

Builds on

Unlocks

Nothing builds on this yet.