Boston Web Performance Meetup: The Render Chain and You

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

©2013 AKAMAI | FASTER FORWARDTM
Agenda
•  Browser Basics
•  Best Practices Review
•  Lessons Learned
•  Questions and Some Answers

Browser Basics: Browser’s Main Components

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

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

Browser Basics: Main Flow
Rendering Engines
•  Gecko: Mozilla
•  WebKit: Safari, Chrome (KindOf)
•  Trident: IE

Browser Basics: Gecko, WebKit
Gecko
WebKit

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);
}

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 }

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

Browser Basics: Render and reflow/layout

Browser Basics: Painting

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

Best Practices Review

Best Practices Review: General
You should consider:
•  Use a CDN
•  File Compression
•  Expires or Cache-Control Header
•  No Vary Header
•  Domain Sharding
•  Cookieless Domains

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

Best Practices Review: HTML
•  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

Best Practices Review: CSS
•  Minify
•  Consolidation – “Average Web Page has 100 objects per page“*
•  Specific selector
*http://www.websiteoptimization.com/speed/tweak/average-web-page/

Best Practices Review: JavaScript
•  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

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

Lessons Learned

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

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

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.

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.

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.

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.

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.

1. Front-Loading Network Effects
First image download: ~1.9
seconds.
Nearly all JS for first ~1.6 seconds

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

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

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.

2. Not so different, after all….
Home Page Product Description
Substantially the same
JS is being downloaded
for every page.

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%

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.

3. Aggregators are good, but….
….beware of adding tags, pre-paint. That’s still ~350ms of tags with a blank page.

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.

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.

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>

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.

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.

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

Boston Web Performance Meetup: The Render Chain and You

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (14)

Similar a Boston Web Performance Meetup: The Render Chain and You

Similar a Boston Web Performance Meetup: The Render Chain and You (20)

Último

Último (20)

Boston Web Performance Meetup: The Render Chain and You