Upload
michaellabriola
View
954
Download
0
Embed Size (px)
DESCRIPTION
Presentation about browser DOM rendering performance and issues
Citation preview
1
Optimizing Browser DOM Rendering
Michael Labriola - @mlabriolaSenior Consultant w/ Digital Primates
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
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
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
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
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
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>
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>
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>
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
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;}
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
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>
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
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
Understanding the Render Tree
The render tree is about the visual aspects of your display
16
div { font-size: 11pt;}
img { display: none;}
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
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
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
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
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)
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
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
Example 2 – Visibility versus Display None
Performance Statement:
• You should/shouldn’t use visibility/display none when you want to hide something.
Why?
24
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
Example 4 – Off Dom Manipulation
Performance Statement:
• If you have to make DOM changes, you should make them ‘off dom’
Why?
26
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
Example 6 – CSS Serial Loading
Performance Statement:
• Using CSS @import can slow down your page load
Why?
28
Example 7 – CSS Media Queries
Performance Statement:
• CSS Media Queries are good/bad for performance
Why?
29
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
Example 9 – Script Placement
Performance Statement:
• Your scripts need to be at the top/bottom of your page at all times.
Why?
31
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
33
Optimizing Browser DOM Rendering
Michael Labriola - @mlabriolaSenior Consultant w/ Digital Primates