Web performance has an unusually large body of folklore — concatenate your scripts, shard your domains, inline the critical CSS, use a sprite sheet. Some of that advice was correct in 2008 and is actively harmful now, and you cannot tell which is which unless you understand what is happening on the wire. That is the argument for reading the network layer first.
The second reason for order: performance work is a measurement discipline. Optimising without a baseline and without knowing which metric maps to which user experience is how teams spend a quarter shaving milliseconds off something nobody waits for.
Understand the transport
High Performance Browser Networking by Ilya Grigorik is the foundational book on this path and the one most worth reading properly. It covers TCP behaviour and slow start, TLS handshakes, the specific costs of mobile radio networks, and then how HTTP/1.1 and HTTP/2 sit on top of all that. Once you have internalised round trips and congestion windows, most performance advice becomes derivable rather than memorised.
Pair it with David Gourley's HTTP, the definitive reference on the protocol itself — methods, headers, caching semantics, proxies, connection management. Caching in particular is where a working knowledge of the headers pays for itself immediately, because a correct cache policy beats almost any front-end optimisation.
The classics, read with a date in mind
Steve Souders's High Performance Web Sites is the book that created this field as a practice, and its rules — reduce requests, use a CDN, defer scripts — shaped a decade of front-end work. Even faster web sites is the follow-up, going deeper on JavaScript loading, parsing and execution.
Read both, but read them historically. They predate HTTP/2, so the advice built around minimising the number of requests, sharding across hostnames and combining files is either obsolete or counterproductive on a modern connection. What survives is the analytical method: measure where the time goes, attack the biggest term, and remember that most of the wall-clock time is on the front end rather than in the server response.
Modern practice and measurement
Jeremy Wagner's Web Performance in Action is the practical, current-era companion — image optimisation, critical rendering path, fonts, build tooling, and the workflow of actually landing improvements. His Responsible JavaScript narrows in on the single biggest problem in contemporary front ends: shipping too much JavaScript, then parsing and executing it on a mid-range phone. It is as much about restraint and framework choice as about micro-optimisation.
Tammy Everts's Time Is Money is the book to read before you ask for budget. It assembles the research connecting latency to abandonment, conversion and revenue, and gives you the framing to make performance a business argument rather than an engineering preference. Short, and unusually useful in a meeting.
Finally, Jeremy Keith's Going Offline covers service workers: caching strategies, offline fallbacks, and how to make a site usable on a flaky connection instead of merely fast on a good one. It is a small, clear book and a natural end point, because it shifts the question from how quickly a page loads to whether it loads at all.
One practical note that no book can supply: get real-user monitoring in place early. Lab tests on your own laptop will mislead you about what your actual visitors experience on their actual devices.
Performance and accessibility fail together more often than teams expect — a page that is slow to become interactive is unusable for reasons that have nothing to do with taste. Follow the full path to build the model before the tricks.
Follow the full ordered path here: Best Books on Web Performance, in Reading Order.
