Web performance and browser engineering on GitHub
Engineers working on the browser internals, DevTools, and metrics that decide how fast a website actually feels.
Über diese Seite
Die Benutzeroberfläche erscheint in deiner Sprache. Der lange Fließtext auf dieser Seite wurde auf Englisch verfasst und ist noch nicht übersetzt.
| Nr. | Entwickler:in | Bekannt für |
|---|---|---|
| 1 |
Addy Osmani
@addyosmani
|
Works on Chrome, where his focus has been Lighthouse, Core Web Vitals guidance, and JavaScript performance patterns. |
| 2 |
Paul Irish
@paulirish
|
Helped build Chrome DevTools and has spent years pushing performance tooling into every major browser, not just Chrome. |
| 3 |
Jake Archibald
@jakearchibald
|
Helped design the service worker spec and wrote much of the early guidance on offline-first web apps. |
| 4 |
Surma
@surma
|
Writes and speaks about WebAssembly and browser internals for Google’s web platform team. |
| 5 |
Phil Walton
@philwalton
|
Maintains web-vitals, the small library most Core Web Vitals monitoring tools are quietly built on top of. |
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.