optimizing browser rendering

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>


</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>


<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


• 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


• 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


• Using CSS @import can slow down your page load

Why?

28

Example 7 – CSS Media Queries


• CSS Media Queries are good/bad for performance

Why?

29

Example 8 – Forced Synchronous Loading


• The order between external CSS and external Scripts in the browser can have major performance implications

Why?

30

Example 9 – Script Placement


• 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

https://www.webkit.org/blog/114/webcore-rendering-i-the-basics/

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

http://grosskurth.ca/papers/browser-refarch.pdf

http://www.phpied.com/the-new-game-show-will-it-reflow/

33

Optimizing Browser DOM Rendering

Michael Labriola - @mlabriolaSenior Consultant w/ Digital Primates

optimizing browser rendering

Technology