Web performance and browser engineering on GitHub

Performance work is unusual among specializations because almost none of its output is visible in a changelog. A successful project in this space usually means a metric got smaller, a script got deferred, or a layout stopped shifting - changes that show up in Lighthouse reports and real-user monitoring dashboards, not in a list of shiny new features.

The developers on this list mostly work at that layer: browser internals, measurement tooling, and the standards that define what “fast” even means.

The metrics had to be invented before they could be optimized

Before Core Web Vitals existed as a concept, “is this site fast” was mostly a matter of opinion. Phil Walton’s web-vitals library and the surrounding Chrome team’s work turned that into a small number of measurable, comparable numbers - which is what made site-speed optimization into an actual discipline rather than a vague aspiration teams argued about.

Standards work moves slower and matters more

Jake Archibald’s service worker contributions and Surma’s WebAssembly writing both sit further upstream than most application code: get the platform primitive right, and the benefit compounds across every site that later builds on it. It’s a slower, less visible kind of impact than shipping a popular library, but the blast radius is arguably larger.

What this means for your own profile

Performance work is genuinely hard to make legible on a profile, because the best outcome is often a graph that goes down and stays down. If this is your area, the signal worth surfacing is the before-and-after: what a page’s metrics looked like before your change and after it.

You can see how that kind of contribution reads on a showcase profile, or generate the same breakdown for your own account.

Related reading

• Open-source infrastructure creators on GitHub
• How the GitHub contribution graph actually works