5 Critical WPO Techniques

Guy Podjarny, CTO

Agenda

• Introduction– Waterfalls charts– WPO & Front-End Optimization

• 5 Critical Optimizations– Domain Sharding– Consolidation– Inlining– Predict Head– Async JavaScript Execution

• Summary

Intro to Waterfall Charts – High Level

3

IndividualResourceRequests

Timeline (Seconds)

WebPageTest Waterfall - Legend

4

• Detailed Breakdown of resource retrieval– Helps identify bottlenecks and problems

• Page Load milestones– “Standardized” points in time to measure against

Front-End vs. Back-End Performance

• Back-End: Time to get the HTML• Front-End: Time after the HTML

– WPO= Back-End + Front-End Performance

5

Back-end Front-End

5 Critical Optimizations

• Front-End Optimization is complicated– Many bottlenecks– Many browsers– Many techniques– Moving Target

• We’ll discuss 5 key optimizations– Explain the optimization– Demonstrate its impact– Share Tips & Tricks

6

Domain Sharding

• Problem: Too Few Hosts – Browsers limit connections per host– Less requests are done in Parallel

• Solution: “Shard” a domain into sub-domains– E.g. 1.blaze.io, 2.blaze.io, 3.blaze.io…– All domains will get to the same place– Browser sees different domains, opens more

connections

7

Single Domain, IE7

• 2 connections per domain• Total time ~8.5 seconds

8

Sharded Domain, IE7

• 2 connections per domain, 8 total• Total time ~2.5 seconds

9

Single Domain, IE8

• Problem mitigated by newer browsers– Open more connections per domain

• Not fully resolved

10

Single Domain, iPhone 4.3

• Problem repeats on iPhone/iPad– 4 Connections per domain, 30 connections max

11

Single Domain, Android 2.3

• But on Android, Domain Sharding is moot– 4 connections per host, 4 connections max

12

Domain Sharding – Tips & Tricks

• Too many domains = long DNS– Older axiom states 2 is best– Our measurements show 3-5 works best

• Depends on number of resources on the site

• Always serve resources from the same shard– Inconsistency will harm caching

• Use different number of domains by browser– Older browsers would benefit from more– Android would benefit from no sharding

13

Consolidation

• Problem: Too many requests during page load– Each request is a costly round-trip to the server– Browsers limit number of concurrent requests– Even more expensive on Mobile (asymmetric

communication)

• Solution: Consolidate multiple files into one– Single round-trip for multiple files

• Less round-trips, faster delivery

– Improved compression ratios

14

What can be consolidated?

• Textual Resources– Stylesheets (CSS)– JavaScript

• CSS Images– Spriting– Details: http://www.alistapart.com/articles/sprites

• Images and… anything else– Data URIs

15

Google Sprite

Data URIs

• Textual Representation of data– data:image/gif;base64,AAAA

• Supported in all latest browsers– Includes IE8+, Chrome, Safari, Opera, Firefox– Not supported in IE7– Supported in WebKit-based Mobile Browsers

• iPhone, Android, Blackberry 6, WinPho 7

16

prefix Content-type Encoding Data

JS & CSS Consolidation - Waterfall

17

Before:160 Requests

www.cnn.com

After:89 Requests

Consolidation – Tips & Tricks

• Ensure browsers support the technology– Data URIs not supported on IE6 & IE7

• Beware large blocking files– On some browsers, CSS & JS files may block– Making them larger may slow down the page

• JavaScript Complications– Inline and external scripts may be co-dependent– Document.write() makes scripts hard to move– Some scripts are more “sensitive” than others…

18

Inlining

• Problems – Too many requests during page load

• Same problem Consolidation relates to

– Consolidated file take longer to fetch• Increases page speed, but can slow down specific script

• Solution: Embed data into the parent – Embed scripts & images into web page– Embed images into CSS files

19

Inlining & Consolidation - Comparison

20

Before:160 Requests

www.cnn.com

Consolidation:89 Requests

Both:57 Requests

Inlining & Consolidation - Waterfall

21

• Larger HTML• Large CSS• Dynamic Resources

– Generated in the browser

– Ads, Analytics, …

Inlining – Tips & Tricks

• Inlined resources are not cached– Inlining best suited for landing pages– Small resources can be inlined always

• Inlining overhead minor for small scripts– Especially when compression is in use

• Don’t inline client-sensitive requests– Analytics, beacons, ads…

22

Flushing the Buffer Early

• Problem– It takes time to generate a full HTML page– Inlining makes pages big and slow to download

• Solution– Send back the document start earlier

• Document “Head” is often static and easy to generate

– Ensure CSS, JS and more are included in head

• Note: Dubbed “Predict Head” in Blaze– After the feature that delivers it

23

Predict Head - Waterfall

24

Before:TTFB is 1.4 seconds,Doc Complete at 3.8 Seconds

After:TTFB is 0.3 seconds,Doc Complete at 2.8 Seconds

Async JS

• Problem– 3rd Party resources still load slowly

• Ads, Analytics, “Like” button, etc.

– Dynamically generated content slows page down• Solution

– De-couple script execution from page load• Most 3rd party tools are included as scripts• Many 3rd party tools are secondary in page functionality

25

Async JS – Comparison

26

Before:Doc Complete at 2.8 Seconds

After:Doc Complete at 1.5 Seconds

Async JS – Waterfall

• Similar Waterfall• Earlier Doc Complete

– Ads loaded late– Metrics loaded late

• Page functional faster– 3rd party tools follow

up quickly after

27

Async JS - Implementation

• Requires HTML & JavaScript Changes• HTML:

– Modify script tags’ type to “text/myscript”– Will make the browser skip them

• JavaScript:– Add script to bottom of page to invoke the scripts– Can use a 3rd party package, such as controljs (

http://stevesouders.com/controljs/)

28

Async JS – Tips & Tricks

• Many pitfalls due to JavaScript flexibility– Event registration, document.write(), etc.

• External scripts will be invoked serially– Will slow down total time to execute scripts– Can be improved with preloading scripts

• Requires cacheable scripts & browser-specific code

• Optionally only “Async” specific script– Whitelist: Leave key scripts “in sync” with page– Blacklist: Only “async” specific scripts

29

Summary

30

160 Requests4.6 Seconds

• FEO Can do A Lot• These 5 optimizations matter

– But many others exist

• Beware the pitfalls– Don’t try it all at once..– Focus on select browsers– Tackle key pages/sites

• Stay up-to-date– Performance is a moving target

59 Requests(9 by Onload)1.5 Seconds

Measured using:4Mbps/500KbpsDownload/Upload

Blaze Automated Front-End Optimization• Blaze automates Front-End Optimization

– No Software, Hardware or Code Changes needed– All the pitfalls and complexities taken care of

• Blaze applied the optimizations in these slides– And can apply many other optimizations

• Submit your URL onblaze.io for your ownoptimization report

31

32

Questions?

Contact us atcontact@blaze.io

Thank You!