Boston Web Performance Meetup: The Render Chain and You
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Boston Web Performance Meetup: The Render Chain and You

on

  • 776 views

Joseph Morrissey and Matt Ringel from Akamai Technologies go a level deeper into web browser internals to show how a browser turns HTML into pixels, and what you can do with your web pages to make ...

Joseph Morrissey and Matt Ringel from Akamai Technologies go a level deeper into web browser internals to show how a browser turns HTML into pixels, and what you can do with your web pages to make them easier to digest by the browser.

We include the top 5 things we've found that make web site rendering slower, and what you can do to fix them.

Statistics

Views

Total Views
776
Views on SlideShare
776
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Boston Web Performance Meetup: The Render Chain and You Presentation Transcript

  • 1. The Render Chain And You Joseph Morrissey – jmorriss@akamai.com Matt Ringel – ringel@akamai.com
  • 2. ©2013 AKAMAI | FASTER FORWARDTM Agenda •  Browser Basics •  Best Practices Review •  Lessons Learned •  Questions and Some Answers
  • 3. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Browser’s Main Components
  • 4. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Relevant Standards •  HTML 4.01, XHTML 1.1, HTML 5 •  Cascading Style Sheets •  CSS 2.1 •  Media Queries Level 3 •  Selectors Level 3 •  CSS Color Level 3 •  ECMAScript Ed 5 •  DOM Level 3 http://www.webdevout.net/browser-support
  • 5. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Browser Modes •  Standards Mode •  Strict Adherence to CSS and HTML Specifications. •  Quirk Mode •  Less adherence to the specifications to maintain the correct display of older pages. A common example is the way older versions of IE calculated an elements Height and Width differently from the CSS specification. Therefore pages created for correct display on that version of IE, displayed badly on newer versions that were compliant with the CSS specification. Switching Modes is controlled via the presence/correctness of the DOCTYPE declaration. Or through Version Targeting Header X-UA-Compatible Using Standards gives your pages the best chance of correctly displaying across User Agents
  • 6. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Main Flow Rendering Engines •  Gecko: Mozilla •  WebKit: Safari, Chrome (KindOf) •  Trident: IE
  • 7. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Gecko, WebKit Gecko WebKit
  • 8. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: HTML Parsing package org.w3c.dom.html2; public interface HTMLBodyElement extends HTMLElement { public String getALink(); public void setALink(String aLink); public String getBackground(); public void setBackground(String background); public String getBgColor(); public void setBgColor(String bgColor); public String getLink(); public void setLink(String link); public String getText(); public void setText(String text); public String getVLink(); public void setVLink(String vLink); }
  • 9. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: CSS Parser CSS Rule selector { style property : style ; } Type Selector h1, h2 {color: green } Universal Selector * { font-family : Verdana, Helvetica, sans-serif ; } ID Selector h1#chapter1 { text-align: center }
  • 10. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Order of Parsing •  CSS Files are retrieved in parallel •  SCRIPT elements may block the HTML parser and delay the completion of the DOM •  Location of style sheet links and javascript can combine to introduce even bigger delays
  • 11. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Render and reflow/layout
  • 12. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: Painting
  • 13. ©2013 AKAMAI | FASTER FORWARDTM Browser Basics: OK So What? To improve rendering: •  Get the bits to the engine faster •  Construct the HTML to minimize parsing effort and not block the DOM build and subsequently the render tree •  Construct the CSS to minimize the effort expended in selecting the style for each CSS Box •  Minimize reflow/layout or repainting
  • 14. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review
  • 15. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: General You should consider: •  Use a CDN •  File Compression •  Expires or Cache-Control Header •  No Vary Header •  Domain Sharding •  Cookieless Domains
  • 16. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: Over Akamai When working with our customers we have more options and we often employ: •  SR4P for non-cacheable HTML delivery •  TCP/Opts •  Last Mile Accelerator – gzip on Akamai •  Embedded Object Prefetching – Edge Side prefetch •  Akamai Instant – Edge Side Page prefetch
  • 17. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: HTML You should consider: •  Asynch Javascript or put it at the bottom of the <BODY> •  CSS in <HEAD>, Link don’t import CSS files •  Provide width and height values in <TABLE>, <TD> and <IMG> •  Inline small images/javascript •  Lazy Load Below the fold images •  Progressive JPGs
  • 18. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: CSS You should consider: •  Minify •  Consolidation – “Average Web Page has 100 objects per page“* •  Specific selector *http://www.websiteoptimization.com/speed/tweak/average-web-page/
  • 19. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: JavaScript You should consider: •  Minify – “In Ten Top US Websites minification achieved 21% size reduction”* •  Consolidation •  Avoid coding that causes reflow/layout •  If the Javascript must block is it efficiently coded? * http://developer.yahoo.com/performance/rules.html#minify
  • 20. ©2013 AKAMAI | FASTER FORWARDTM Best Practices Review: Akamai Front End Opt Reduction in Round trips •  HTML 5 Adaptive Cache •  Just-In-Time Image Loading •  Small Image Embedding •  Small JavaScript File Embedding •  File Versioning •  HTML 5 Persistent Cache Reduction in Object Size •  Responsive Images: •  Resizes Images to HTML Dimensions •  Lossless Image Compression •  Adaptive Image Sizing •  Cookieless Static Assets •  GZIP Compression •  Minification Accelerated Rendering •  JavaScript Pre-Execution •  Asynchronous JavaScript Execution •  Asynchronous CSS •  Optimize JS and CSS Load Order •  Response Prediction •  Page Prefetching •  Domain Sharding
  • 21. ©2013 AKAMAI | FASTER FORWARDTM Lessons Learned
  • 22. ©2013 AKAMAI | FASTER FORWARDTM Recap: The Rules of Rendering The One Rule: Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved. Javascript CSS Long load times
  • 23. ©2013 AKAMAI | FASTER FORWARDTM Rule #1: Scripts Block Parsing Posit: JavaScript is a single-threaded environment, and change the DOM Consequence: The render chain blocks. Result: The browser will sit there parsing it all. Conclusion: Don’t do that. Use async/defer where you can. * HTML5 JavaScript Workers change this a bit
  • 24. ©2013 AKAMAI | FASTER FORWARDTM Rule #2: Style Sheets Block Rendering Posit: Anything that can force a re-flow will introduce uncertainty. Consequence: CSS blocks rendering Result: Inline or interspersed CSS will block rendering. Conclusion: Pare it down, put it first. * CSS “print” styles or non-matching media selectors will not block because they’re not immediately applicable.
  • 25. ©2013 AKAMAI | FASTER FORWARDTM Rule #3: Less Caching, More Problems. Posit: The fastest load time is when the browser already has the data. Consequence: Origin hits cost time and are distance-based. Result: Non-cacheable content creates high variability in page load time. Conclusion: Cache browser-side if possible, consider using a CDN. * Really, any CDN will be better than none, although the author might have certain biases.
  • 26. ©2013 AKAMAI | FASTER FORWARDTM E-Commerce sites: The Top Five Rendering Issues E-Commerce sites rest on two separate, but equally important metrics: Abandonment representing who leaves, and Conversion representing who buys. These are their stories.
  • 27. ©2013 AKAMAI | FASTER FORWARDTM 1. Front-Loading all of the JavaScript Problem: Load too much synchronous JS up-front, and the browser sits and spins, without painting a single pixel. Result: A lot of “blank page” time. Solution: Defer/async all of the JS you can. “CSS at top, JS at bottom” is a very good metric for keeping the render chain happy.
  • 28. ©2013 AKAMAI | FASTER FORWARDTM 1. What does front-loading look like? 91 pre-render requests 35 out of the first 91 calls are JS First pixel is at 2.7 seconds.
  • 29. ©2013 AKAMAI | FASTER FORWARDTM 1. Front-Loading Network Effects First image download: ~1.9 seconds. Nearly all JS for first ~1.6 seconds
  • 30. ©2013 AKAMAI | FASTER FORWARDTM 1. Wicked fast Utility sprite downloaded after first CSS First pixel at 0.45 seconds
  • 31. ©2013 AKAMAI | FASTER FORWARDTM 1. Okay, maybe not that fast. Most of the page is brought in via AJAX after initial load.
  • 32. ©2013 AKAMAI | FASTER FORWARDTM 2. Cargo-cult JS and CSS Operationally, loading the same JS/CSS for every page makes sense, but there’s a cost. The vast majority of CSS rules may never get used, but the render chain has to evaluate them just the same.* Tools: YUICombine, YUICompress, using versioned files when combining. Use CSS and JS coverage tools to figure out what you’re not using. *In that way, the render chain is much like a honey badger.
  • 33. ©2013 AKAMAI | FASTER FORWARDTM 2. Not so different, after all…. Home Page Product Description Substantially the same JS is being downloaded for every page.
  • 34. ©2013 AKAMAI | FASTER FORWARDTM 2. The repeat view is better… kind of. Load time is down 56% Requests are down 89% But start of render is only down 36%. Cached JS is still parsed JS. 56% 36% ?? 89%
  • 35. ©2013 AKAMAI | FASTER FORWARDTM 3. Third-party tags and widgets Beacons, Widgets, Tags, CustomerMonetizationSynergisticThingies™, etc. Page performance is now controlled by a third party, they block everything below them on the page, and there’s a network penalty for DNS resolution. Harm reduction: Put them as low on the base page as possible. Consider a tag aggregation service in order to reduce the amount of requests.
  • 36. ©2013 AKAMAI | FASTER FORWARDTM 3. Aggregators are good, but…. ….beware of adding tags, pre-paint. That’s still ~350ms of tags with a blank page.
  • 37. ©2013 AKAMAI | FASTER FORWARDTM 3. Later on, during the rest of the page load….. Redirects are a tax on every page. Don’t neglect SSL negotiation time. Everything lower on the page can’t be painted due to these tags.
  • 38. ©2013 AKAMAI | FASTER FORWARDTM 4: Actively hindering cacheability: “Hello, Bob” Many sites allow a user to log in. Many sites then put the user’s name at the top of the page. Many sites then bake the user’s name into the HTML sent from the origin, rendering the page non-cacheable. Don’t do that. Look at doing an asynchronous load.
  • 39. ©2013 AKAMAI | FASTER FORWARDTM 4. QED xx_1.Page_Name = ""; xx_2.Login_Status = "Logged in"; xx_3.User_ID = "846000486"; (and later on that page…) <script charset='utf-8' type='text/javascript'> var userID =''; userID ='akamai@example.com'; </script>
  • 40. ©2013 AKAMAI | FASTER FORWARDTM 5. The Cookie Tax Cookies are a fact of life, but avoid sending them for static objects. The browser could send hundreds of KB just to ask for the page.* For small graphics, total load time (up + down) could double. * I’ve seen one site require 12KB of cookies on each request. No, I’m not telling you who.
  • 41. ©2013 AKAMAI | FASTER FORWARDTM 5. This is for every embedded object 79 requests * 1,376 bytes / request = 108,704 bytes Moreover, this will not fit into a single IP datagram on a desktop or laptop.
  • 42. ©2013 AKAMAI | FASTER FORWARDTM 5. Why this is important (an anecdote) 2 ½ hours after the 9/11 attacks, CNN redid their website to fit inside a single IP Datagram, in order to stay online. Fitting a request inside a datagram is much easier. Source: http://www.interactivepublishing.net/september/browse.php?co=CNN