This presentation discusses optimizing browser DOM rendering. It begins by explaining that performance has both subjective and objective aspects. The goal is to understand the browser internals in order to know why certain optimizations work. The presentation then covers how a browser loads and parses a page, builds the DOM tree and render tree, applies CSS styles, and performs layout and painting. It provides examples of optimizations like using element sizes, visibility over display none, batching DOM changes, and loading CSS asynchronously. The overall message is to do less work such as avoiding unnecessary reflows and repaints.
2. Session Expectations - Performance
This session is about performance optimization but it‟s not
an absolute thing.
Performance has both subjective and absolute aspects
• Perceived performance can be the difference between a
user‟s willingness to use an application or abandon it
• Raw computational work may decide which devices can use
your work effectively and for how long
2
3. Session Expectations - Optimization
Performance Optimization is similarly difficult.
• An optimization in one situation can unintentionally degrade
performance in another
• Optimization is more about understanding a range of
possibilities and trying to find the sweet spot for your purpose
Performance advice is usually about what to do, but it‟s
contextual.
• Context is just often lost in the explanation.
• Performance related advice can often appear conflicting
• There are exceptions
• Much of the advice you can find online is out of date
3
4. Session Expectations - Goal
This presentation is about understanding the browser
• Understanding internals helps you build a mental model
• The real goal is to know why to do something
This is a big topic that we could talk about for days.
Alas, we have an hour, so:
• I won‟t get to cover everything I want
• I won‟t get to dive into the depth that I desire
• This is my best to balance at a lot of theory and practical ways
to apply
4
5. Disclaimer
Unfortunately, with this type of technical content I need a
disclaimer.
Applicability
• This advice is generally for Webkit-based rendering
• Most of it is identical for Gecko (Firefox), although some of the
terminology is different
• Internet Explorer
• Most of the general advice is still valid for IE
• There are major differences in the way IE7, IE8 and IE9 handle
some of these things
• I am not saying to ignore IE. The general advice is good and
then its worth while to experiment and test on IE.
5
6. Jumping In
When you navigate to a URL, a web page is loaded by a
Loader. Let‟s call the result of that load operation „tag soup‟
for now.
Tag soup needs to get parsed
6
7. The goal of the parsing step is to create something we call
the DOM tree. In a perfect world it might look like this:
Parsing
7
<html>
<head>
<title>Yo!</title>
</head>
<body>
<div>
<img src="ncdev.jpg">
</div>
<div><p>Dev Con</p></div>
</body>
</html>
8. Parsing – Best Guess
Unfortunately HTML isn‟t always perfect, so the parser has
to make some best guesses and try to bring something
together:
8
<html>
<head>
<title>Yo!</title>
</head>
<body>
<div>
<img src="ncdev.jpg">
</div>
<div><p>Dev Con
</body>
</html>
9. Parsing – Best Guess Gone Wrong
..and those guesses may not be what you expected. So,
validate your HTML, save the parser some effort and you
some sanity.
9
<html>
<head>
<title>Yo!</title>
</head>
<body>
<div>
<img src="ncdev.jpg">
<div><p>Dev Con
</body>
</html>
10. Waterfall
Modern browsers do some optimistic look-aheads, if the
parser is ever blocked/waiting, the browser begins
downloading other external content it will also need
10
11. CSS
The combination of default style sheets, inline styles, inline
CSS and CSS Loaded from external files provides
information we use for layout and styling. So, we build a tree
(actually a few and some more data structures)
11
p,div{
margin-top:3px;
}
.error {
color:red;
}
12. DOM and CSS sitting in a Tree
Information from the DOM tree and the Style Structures are
used to form the Render Tree. The Render Tree holds the
information about what gets painted on the screen.
12
13. CSS Style Matching
CSS styles are stored into various maps so that they can be
easily retrieved later.
13
div {
font-size: 11pt;
}
table div {
font-size: 12pt;
}
#theId {
display: none;
}
.myClass {
color: #ff0000;
}
Tag
ID
Class
<div>
<img src="foo.jpg">
</div>
<div>
<p>NCDev</p>
</div>
<p id="theId"></p>
<p class="myClass"></p>
14. Quick Advice on CSS
Specificity is important, but the rule be as specific as
possible is confusing. From a pure performance standpoint
• ID Selectors followed by Class Selectors are very fast
• Further clarifying these is NOT helpful, its slower
p.myClass table#thingy
• Descendant Selectors and Child Selectors should be avoided
whenever humanly possible
.myul_in_a_div {}
versus
ul div {}
14
15. CSS Caveats
Caveats - How specific a selector is determines its weight
when styles cascade
• It‟s from is a 'style' attribute rather than a rule with a selector
• The number of ID attributes in the selector
• The number of other attributes and pseudo-classes in the
selector
• The number of element names and pseudo-elements in the
selector
15
16. Understanding the Render Tree
The render tree is about the visual aspects of your display
16
div {
font-size: 11pt;
}
img {
display: none;
}
17. Putting it all together
Manipulating the DOM is the slowest thing we can do in the
web environment. Depending on what we do, the browser
needs to mark things as invalid. The process of making
them valid again means executing parts of this diagram.
17
18. Repaint Only
If we are careful and just make changes to things like color,
visibility or other changes that don‟t require new
measurement and layout, we can often just execute this part
of the chart:
18
19. Re-layout/Flow
If we make any change that requires that causes a size or
positioning difference we need to minimally executed these
parts of the chart.
19
20. Do Less Work
The simple truth behind making DOM interactions faster is
to do less of it…
A few ways to do less
• Execute the smallest amount of that flow chart that you can at
any time
• Actively worry if your choices make the browser execute any
part of it multiple times in a row
• Pay attention to how much of the trees your impacting
• Do your best to let the browser do this work when it is ready
20
21. Tooling
There are many excellent tools you can use to debug and
look into the information we are about to discuss. We are
just going to use Chrome‟s built in tooling for the moment,
but here are some resources:
21
YSlow
Chrome Plugin
Firefox
Speed Tracer
Chrome Plugin
FireBug
Firefox
dynaTrace (5 day
trial)
IE Extension
Firefox
jsPerf
Webpagetest.org
(More every 5
minutes)
22. Chrome‟s Tools
Chrome has a great set of tools that will get us started and
they are all built in
Tools
• Network View
• Timeline
• CSS Profiler
22
Render Information
• Paint Rectangles
• Composited Layer Borders
• FPS Meter
• Continuous Page Repainting
23. Example 1 – Sized versus Non-Sized
Regions/Images
Really old statement everyone knows:
• Whenever possible, you should provide a width and
height for your images
Why?
23
24. Example 2 – Visibility versus Display None
Performance Statement:
• You should/shouldn‟t use visibility/display none when you
want to hide something.
Why?
24
25. Example 3 – Synchronous Layout
Performance Statement:
• You need to batch your changes to the DOM. Always try
to make a single class change versus multiple changes.
Why?
25
26. Example 4 – Off Dom Manipulation
Performance Statement:
• If you have to make DOM changes, you should make
them „off dom‟
Why?
26
27. Do Less Work Sooner
The perceived responsiveness of your page/application also
depends on how quickly it starts up.
This ultimately comes down to a few factors
• How much do we need to load on startup?
• How quickly can we load it?
• How much work must we do when everything arrives?
27
28. Example 6 – CSS Serial Loading
Performance Statement:
• Using CSS @import can slow down your page load
Why?
28
29. Example 7 – CSS Media Queries
Performance Statement:
• CSS Media Queries are good/bad for performance
Why?
29
30. Example 8 – Forced Synchronous Loading
Performance Statement:
• The order between external CSS and external Scripts in
the browser can have major performance implications
Why?
30
31. Example 9 – Script Placement
Performance Statement:
• Your scripts need to be at the top/bottom of your page at
all times.
Why?
31
32. Selected Resources
WebCore Rendering – Parts I through IV
https://www.webkit.org/blog/114/webcore-rendering-i-the-basics/
How Browsers Work: Behind the scenes of modern web browsers
http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
Grosskurth, Alan. A Reference Architecture for Web Browsers
http://grosskurth.ca/papers/browser-refarch.pdf
The new game show: “Will it reflow?”
http://www.phpied.com/the-new-game-show-will-it-reflow/
…more to be posted…
32
Image licensed under creative commons attribution license. Found at http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
To combine these trees, the correct style needs to be computed for each element in the DOM tree. CSS styles are stored into various maps (buckets) so that they can be easily retrieved later. The mappings reduce the scope of the search, using the right most key of the selector.
Image licensed under creative commons attribution license. Found at http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/This all matters for a simple reason. Manipulating the DOM is the slowest thing we can do in the web environment. Depending on what we do, the browser needs to mark things as invalid. The process of making them valid again means executing parts of this diagram.
Image licensed under creative commons attribution license. Found at http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
Image licensed under creative commons attribution license. Found at http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/