Speed Domains

This organization of Speed into domain areas allows us to:

  • Utilize domain expertise to manage incoming bugs and regression reports
  • Have a clear escalation paths
  • Organize optimization efforts as needed


This domain deals with memory use by Chrome on all platforms. Primary focus is to gracefully deal with situations where user is out of memory (OOM) and to manage memory for idle and backgrounded tabs.


The Power domain is concerned with improving power usage for our users. Collectively, our product has an impact on global greenhouse gas emissions and we would like to mitigate that. Increasing battery life, reducing users power bill, not burning laps/hands, and not making loud fan noises are all important benefits of this.


The Loading domain focuses on the time between click to the time when you can interact with a website.


Responsiveness domain focuses on making sure all websites have smooth transitions by serving 60fps, and that the click to action time is not noticeable.

Binary Size

Chrome has an update for you at least every six weeks. Since we do that for all of our users, we want to be nice to our users where downloading updates costs real money. We also don‘t want to hog all of the disk space on low end phones. So we focus attention on making sure we don’t include bits in our update that are not necessary for users.

Data Usage

Data Usage is a focus on the question: Do the user see or need every byte downloaded? By looking at this, we can save user's cost of data, time to load, memory and power.

Startup, Omnibox, Browser UI, etc.

There are a handful of performance angles that don‘t fit into the domains already mentioned. Historically, we’ve put these into a “Browser” bucket as that‘s descriptive of what’s left over. These are things like making sure the Omnibox experience on Chrome is fast, making sure all of the Chrome UI, e.g. Settings, is fast and that the browser startup and session restore doesn't allow users to make coffee before they use the browser.