1 / 42

The Render Chain And You

The Render Chain And You. Joseph Morrissey – jmorriss@akamai.com Matt Ringel – ringel@akamai.com. Agenda. Browser Basics Best Practices Review Lessons Learned Questions and Some Answers. Browser Basics: Browser’s Main Components. Browser Basics: Relevant Standards.

nevan
Download Presentation

The Render Chain And You

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Render Chain And You • Joseph Morrissey – jmorriss@akamai.com • Matt Ringel – ringel@akamai.com

  2. Agenda • Browser Basics • Best Practices Review • Lessons Learned • Questions and Some Answers

  3. Browser Basics: Browser’s Main Components

  4. 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. 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. Browser Basics: Main Flow • Rendering Engines • Gecko: Mozilla • WebKit: Safari, Chrome (KindOf) • Trident: IE

  7. Browser Basics: Gecko, WebKit Gecko WebKit

  8. 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. 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. 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. Browser Basics: Render and reflow/layout

  12. Browser Basics: Painting

  13. 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. Best Practices Review

  15. 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. 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. Best Practices Review: HTML • You should consider: • AsynchJavascript 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. 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. 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. 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 • CookielessStatic 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. Lessons Learned

  22. 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. 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. 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. 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. 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. 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. 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. 1. Front-Loading Network Effects First image download: ~1.9 seconds. Nearly all JS for first ~1.6 seconds

  30. 1. Wicked fast Utility sprite downloaded after first CSS First pixel at 0.45 seconds

  31. 1. Okay, maybe not that fast. Most of the page is brought in via AJAX after initial load.

  32. 2. Cargo-cultJS 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. 2. Not so different, after all…. Home Page Product Description Substantially the same JS is being downloaded for every page.

  34. 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. 36% ?? 56% 89%

  35. 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. 3. Aggregators are good, but…. ….beware of adding tags, pre-paint. That’s still ~350ms of tags with a blank page.

  37. 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. 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. 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. 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. 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. 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

More Related