Web Performance Calendar

The speed geek's favorite time of year
2022 Edition
Amiya Gupta

Amiya Gupta (@amiyagupta) is a Web Performance Engineer at Microsoft. He has worked on making sites such as Microsoft.com and MSN.com load faster.


A Swiss Army knife is not merely a knife but rather an entire toolbox packaged in a light and compact container. Each tool is carefully selected to maximize utility while simultaneously minimizing size and redundancy. Mastery of the toolbox means knowing when and how to use each available tool, like choosing a corkscrew instead of a screwdriver.

An advanced Swiss Army Knife with more than a dozen tools

The Web Performance Swiss Army Knife

As web performance engineers we also need to learn and master an ever-growing toolbox. The Web Performance Swiss Army Knife consists of a well-known and documented set of tools and best practices. There are no big secrets when it comes to achieving fast web performance; this is an open and collaborative field. Experienced engineers use the same tools as those who are just starting out.

What differentiates an experienced engineer is the ability to quickly diagnose performance issues and identify effective solutions to those problems. Conversely (and just as importantly), they know when a particular optimization technique does not apply to their situation and will not move the needle. This knowledge helps save wasted time and effort.

So, how do they do it?

We know web performance isn’t simply a matter of checking off a list of best practices. If it was that simple this wouldn’t be a thriving field well into its third decade. You can implement dozens of best practices and still end up with a slow site.

The key is to incorporate a handful of mental models into your thinking. Once these mental models are in place you begin to master the Swiss Army Knife.

Mental Models for Mastering the Swiss Army Knife

In no particular order, here’s a list of mental models that web performance engineers develop and incorporate into their thinking over time.

1. Browser internals

Knowing the characteristics of the runtime is crucial when it comes to optimizing any code and the web is no exception. Because of abstraction most web developers unfortunately aren’t aware of the algorithms and data structures used by the browser, or the event loop. Simply querying the dimensions of an element at an inopportune moment can trigger an O(N^2) algorithm under the hood. Observing and learning how the browser goes through the process of loading, parsing and executing each line of code your site delivers to it can be an incredible source of insight.

2. Identifying critical bottlenecks from a trace

The two most prevalent bottlenecks in web performance are network and CPU. Every page load and interaction will cycle through phases of being maxed out or starved in one or both of these resources. Each of these phases represents a discrete opportunity for optimization.

An experienced web performance engineer is able to analyze a waterfall to identify these phases. They may even open up a CPU trace to look at particularly egregious long tasks on the main thread. They can also extrapolate which of these sections are likely to become exponentially slower at high percentiles on slow networks and devices.

Finally they’re able to map appropriate solutions to address the most severe problems identified in their analysis. A nail file isn’t the most effective tool if you need to cut a rope. Similarly they know that using a more efficient text minifier will not move the needle if the main bottleneck on their site is oversized images.

3. Browser networking

An experienced web performance engineer has a grasp of browser networking protocols such as HTTP, DNS, TCP, UDP and TLS. They understand how bandwidth and round-trip latency influence the time it takes to establish connections and load resources. They are aware that network-related bottlenecks tend to become more acute at the higher percentiles (even more so than CPU).

After several relatively stable years with HTTP/2 things are changing again with the rollout of HTTP/3. Robin Marx’s post earlier in this year’s calendar covered some of the nuances of prioritization in HTTP/3.

4. User and session characteristics

An experienced web performance engineer knows what types of devices their site’s visitors use, how often they return and how long they stick around. These characteristics when aggregated will influence the choice of the most optimal performance optimizations. For example, deciding whether or not to inline critical resources such as CSS and images will depend heavily on how often users return and how often the content changes.

5. Interpreting performance data

An experienced web performance engineer is keenly aware of the differences between RUM and lab data and knows they aren’t interchangeable.

When looking at lab data they pay close attention to the test configuration settings and automation sequence in order to understand what the lab is modeling. They are aware of blind spots in important scenarios that their lab tests do not model.

When looking at RUM data they are aware of its seasonal nature and understand percentiles. When slicing RUM data by dimensions they are wary of encountering Simpson’s Paradox. At high percentiles they are aware that Survivorship Bias may counterintuitively make an improvement look like a regression.

If you are just starting out and/or don’t have access to a large dataset of your own, exploring the RUM Archive can be a great way to study the nature of RUM data.


Incorporating the mental models listed above into your thinking will go a long way towards mastering the Web Performance Swiss Army Knife. As new tools and technologies emerge it will be easier to incorporate them into your thought process and workflow.

I’d love to hear from other folks in the community if there are additional mental models that I might have missed.


Many of these concepts emerged from several long discussions at work in early 2022 with Alex Russell and Joe Liccini.

Swiss Army Knife image by user pennuja on Flickr, licensed under CC BY 2.0.