It’s rare that technology companies explain their secret sauce so I’m always psyched when they do. It’s really hard for technology companies to learn best practices from industry leaders so kudos to Google in explaining how they make Chrome so fast. Peter Kasting, an engineer on the Chrome team gives a good talk on how Google has optimized its Chrome browser. Here’s my bullet summary.
- The core mission is fast and pleasant web browsing.
- Chrome should start quickly.
- Always be reactive to anything users do in UI.
- Never hang.
- Actions should seem effortless.
- Do as little as possible at startup. Easy to do lots of things at startup, so it’s easy to make startup slow. Called lazy initialization. Profiling and picking addresses of DLLs where Windows won’t need to relocate is another way to make startup faster.
- Save the user steps. Address bar auto-complete for example. Chrome keeps several data structures in memory.
- A busy tab shouldn’t lock up app. Chrome is multiprocess and multi-threaded. If something hangs, a user can still click on another tab.
- Key threads in multi-threading are UI thread (input and output), IO thread (internal processes, messaging, etc), file thread (write to disk). IO thread is not allowed to do something that takes a long time. If IO is blocked whole app is blocked.
- Multithreading renderers early on were problematic because OS would swap renderers out of memory if they weren’t used for a while. Google created what they call a Backing Store Cache to solve the problem by caching the window paint. A static image is shown while the real-image is loading in background. Not a cure-all, as sometimes it doesn’t work if you’ve resized window for example.
- Resizes on complex pages was solved using trick in backing store. Rate-limiting tactic. They drop unnecessary rendering slimming down the queue.
- Chrome team uses metrics to always make sure browser is faster not slower with each version. They do not allow startup time to regress. Measure whiteout duration to make sure backing store and renderers are working properly as another example of speed metrics.
- In addition to quantitative metrics they use subjective testing by QA for speed.
- Keeping things simple isn’t just a design goal, it drives the overall product mission. Cognitive friction – amount of mental energy required to use UI – is minimized. Reduce amount of time and effort to perform action. Omnibox is an example where there is one box for search or URL. Also short menus and options.
- They also whitelist keystrokes that renderers are unlikely to override and users don’t want to wait on. Ctrl-w is example that doesn’t go to renderer.
- Milliseconds matter.
