Your SlideShare is downloading. ×
0
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Optimizing Browser Rendering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Optimizing Browser Rendering

1,301

Published on

Presentation about browser DOM rendering performance and issues

Presentation about browser DOM rendering performance and issues

Published in: Technology, Design
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,301
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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/
  • Transcript

    • 1. 1 Optimizing Browser DOM Rendering Michael Labriola - @mlabriola Senior Consultant w/ Digital Primates
    • 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
    • 33. 33 Optimizing Browser DOM Rendering Michael Labriola - @mlabriola Senior Consultant w/ Digital Primates

    ×