The Speed Infrastructure team empowers Chromium developers to prevent, detect, diagnose, and fix performance issues.
- Maintain a platform of tooling that empowers Chromium developers to prevent, detect, diagnose, and fix performance issues.
- Educate chromium developers about using our platform for improving performance through documentation and tech talks.
- Collaborate with and support teams working on Chrome performance to ensure our tooling and tests are world-class.
- Report and triage performance regressions found through both real user monitoring and performance tests in the lab, preventing them from reaching stable.
Out of scope:
- Correctness testing. Our testing tools are for performance testing.
- Web standards / APIs.
- Making metrics in a silo. We partner with teams involved in performance of a given area in order to produce high-quality, actionable metrics.
- Implement performance optimizations.
Speed Infra team is working hard to bring our tools from hacked-together, one-off solutions to a stable platform and waterfall that provides world-class tooling for all stages of the performance lifecycle. Since that is our main focus, our bandwidth to support new clients and one-off projects is currently low.
Speed infra team pairs with these clients, and they help drive our long-term vision. These clients fall into two groups:
- Projects that are critical to high-level Chrome objectives.
- Our supported waterfalls.
Speed infra team mostly supports tier 1 clients with design help, design reviews, and code reviews. Sometimes the team also does engineering work on P0 problems for Tier 1 clients, such as waterfall breakages and high priority requests.
Most clients are tier 2. Speed infra team commits to design reviews, code reviews, and adequate documentation for tier 2 clients. We support the basic functionality of our tools, but if clients want to add a one-off feature or customize the tools for their specific use case, they will need to manage the engineering on that themselves, noting that it needs to fit into our architecture. We answer questions on our mailing list, but we ask that users do due diligence in looking into problems themselves, instead of “tossing them over the fence”.
Clients that don’t fit into our architecture, aren’t able to make reasonable best-effort at debugging problems, or are out of our scope (for example, correctness testing is out of scope). We aren’t able to help these clients.