I gave a quick chalk-talk today that is maybe of general interest. I was talking about the few categories of Browser Performance Problems. These are fairly simple cost and consequence categories (say that three times fast) that often drive bad experiences.
The Cost Sources
The main pipeline is in some sense what the browser does “passively”; you make some DOM edits (either by downloading a new page or running script) and it responds with parse/format/layout/render/compose.
- Parse: convert the text to internal data structures of the appropriate type
- Format: convert declared styles to computed styles
- Layout: consume computed styles to get position and size of every box
- Rendering: draw the stuff that’s on the screen into a suitable buffer (maybe a bitmap, maybe a display list), breaking into 1 or more layers in the process
- Compose: blend various layers to create the final display
Any given change to the DOM is going to require these processes to run and generally you’d like surgical changes as a consequence. How well the browser can consume your change and minimally recompute what’s necessary will tend to drive the responsiveness of your page (and its battery cost). Note different browsers respond differently, some changes that theoretically can be very economical are poorly implemented and so a large cost is incurred. You can often change your code to avoid these costs. Or request browser improvements.
There are two anti-patterns that are responsible for most of the horribleness you see on the web. Well, at least in my experience these are the two whoppers:
- Too much use of GetOffsetWidth and friends
2. Too many timers.
The biggest drain on battery comes from the abundance of high frequency (60Hz) timers in web pages. Any kind of high frequency timer is going to prevent the CPU from going into a sleep state, that’s bad enough, but if you do expensive operations in your callbacks you will also materially affect render times. Ads on a web page tend to be the worst offenders “I think my ad should load its own copy of JQuery archived from 1847 and do some nice hefty computations with it.” Naturally the other ads are using JQuery from different centuries. * I know there was no JQuery in 1847, it only seems like there must have been when you have to decode the minified code…
The biggest power savings from browsers tend to come from advanced timer management. Which approximately consists of “You want a 60hz timer for your low priority stuff? Screw you, you’re getting 1Hz and you’ll like it.”
As indicated there is an achievement for doing (1) and (2) at the same time.
Naturally this isn’t everything; but this stuff comes up an awful lot.
The “F12” tools in the browsers can be invaluable for identifying all of these categories. Likewise Windows’ “WPA” toolkit can be invaluable for finding consumption and correlating it to markup.