Velocity 2010 Workshop - The 90-Minute Optimization Life Cycle (Strangeloop)

8/9/2019 Velocity 2010 Workshop - The 90-Minute Optimization Life Cycle (Strangeloop)

1/123

Author of presentation

90 Minute Optimization Life CycleFast by Defaultbefore our eyes


2/123

2010 Strangeloop Networks . . .Strangeloop Faster Websites Automatically 2

Todays Hosts

Hooman BeheshtiVP ProductsStrangeloop

Joshua BixbyPresident

Strangeloop


3/123


Agenda

Why is faster betterMaking a site faster

Measurement

Diagnosis

Demos

What did we miss

Q&A-


4/123


Methodology


5/123


Why is faster better?

:// . . / / / / - - - - -http www webperformancetoday com 2010 06 15 everything you wanted to know abou/

(http:// . /bit ly 8YB3ET )
http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/http://bit.ly/8YB3EThttp://bit.ly/8YB3EThttp://bit.ly/8YB3EThttp://bit.ly/8YB3EThttp://bit.ly/8YB3EThttp://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/


6/123



7/123 2010 Strangeloop Networks . . .Strangeloop Faster Websites Automatically 7


11/123


mpact of page load time onmpact of page load time onverage daily searches per userverage daily searches per user


12/123



13/123


mpact of additional delay onmpact of additional delay onusiness metricsusiness metrics


14/123



15/123


hopzilla had another anglehopzilla had another angle , -Big high trafficsite

100M impressions aday

,8 000 searches a

second -20 29M unique

visitors a month 100M products

-16 month reengineering Page load from 6

.seconds to 1 2 . %Uptime from 99 65

. %to 99 97 %10 of previous

hardware needs

:// . . / / / / /http en oreilly com velocity2009 public schedule detail 7709


16/123


5-12% increase in revenue


17/123



18/123



19/123



20/123



21/123



22/123



23/123



24/123



25/123



26/123


Measurement:


27/123


Where should we start?

lsow from

age Speedfrom


28/123



29/123


Example: Gomez


30/123


HTTP Watch


31/123


Webpagetest.org


32/123


Visualizing the problem


33/123

www.strangeloopnetworks.com 33 2010 Strangeloop Networks . . .Strangeloop Faster Websites Automatically 33

Web Performance Problem

Definitions

Backend:Time from when the user makes therequest to when the last byte of theHTML document arrives. Includes thetime for the initial request to go up,

the Web server to stitch together theHTML, and for the response to comeback.

Frontend:Shorthand for everything after theHTML document arrives. In reality,includes backend time (primarilyreading static files) and network time,as well as true frontend activities suchas parsing HTML, CSS, and JS, and

Front end Problem is getting


34/123

Front-end Problem is gettingworse

14.1

93.7

312.05

498

0

100

200

300

400

500

600

Total

Bytes(K)

Av

erageNumbe

rofObjects

6050

3040

20100

.9 92

.5 7.3

Average Page Size (K)Average Number of Objects

.5 2570


35/123

35 2010 Strangeloop Networks . . .Strangeloop Faster Websites Automatically 35

Waterfall chart


36/123


Waterfall chartHTML


37/123


Waterfall chart

Resources

HTML


38/123


Waterfall chartStart

RenderDocument

CompleteFullyLoaded


39/123


Waterfall component breakdown

DNSlookup

DNS Lookup

Takes one packet in each

directionTime is limited to the

latency of the connection( / / )DSL Cable etc for the

single round trip


40/123



TCPConnectio

nTCP Connection

3 packets

- ( )Client Server SYN- Server Client

( / )SYN ACK- ( )Client Server ACK

Time is limited to the latency ofthe connection

(DSL/Cable/etc) for thesingle round trip


41/123


Time ToFirst

ByteTime to First Byte

Time from the request packet

( )usually 1 to the firstpacket of the response Includes the latency of the

connect ion( / / )DSL Cable etc for a

single round trip Also includes whatever

server think time wasinvolved in generatingthe response



42/123


ContentDownload

Download

Time it takes for the entire

content of the responseto get to the browser Mostly limited by the

bandwidth limit of the( / / )connection DSL Cable etc



43/123


Lets Accelerate

The unsuspecting victim


44/123



45/123


A Few Points of Clarification

Were using this page because itsmore fun!

Well use it to describe whereperformance pain points are, butthat doesnt mean the pageactually has these problems

What were going to do: ot sogood( )low

Awesome( )ast

Improve performance incrementally

* he real Velocity site is somewhere in the!iddle


46/123


Performance Summary

http://bit.ly/au01VY/
http://bit.ly/au01VYhttp://www.webpagetest.org/result/100614_aacdab746259dd7c89dfe994c1997d3b/http://www.webpagetest.org/result/100614_aacdab746259dd7c89dfe994c1997d3b/http://bit.ly/au01VY


47/123


WaterfallFirst View Repeat View

bj


48/123


Per Object

C A l i b T


49/123


Content Analysis by Type

C A l i b D i


50/123


Content Analysis by Domain


51/123


Show Me Where It Hurts

Problem Analysis

P f P bl


52/123


Performance Problems

Too many connections (too muchorange)

T M C ti


53/123


Too Many Connections

97 Connections( )almost one per request

T M C ti


54/123


Too Many Connections

P f P bl


55/123




Too many bytes (too much blue)

T M B t


56/123


Too Many Bytes

By Type By Domain

P f P bl


57/123





Concurrency

C


58/123


Concurrency

Browsers can only open and use somany connections at once

www.browserscope.org

http://www.browserscope.org/http://www.browserscope.org/


59/123





Concurrency Bad Caching for repeat views

Bad Repeat View


60/123


Bad Repeat View

Full Fetches

Validation

Bad Repeat View


61/123


Bad Repeat ViewConnections Bytes



62/123






No CDN (the greens are too big)

The Green Problem #1: No


63/123


CDN TTFB

Time To First Byte


64/123


Time To First Byte

HTTP overhead

Subjected to latency every time

The more objects, the bigger the

problem Concurrency helps, but not a lot

GET /javascripts/application.js?1276735447 HTTP/1.1Accept: */*Referer: http://en.oreilly.com/velocity2010/Accept-Language: en-usUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2;

Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR3.0.4506.2152; .NET CLR 3.5.30729)Accept-Encoding: gzip, deflateHost: en.oreilly.comCookie: _session_id=6e76e8d4a4eccc63b4be7937e719ca9e



65/123






No CDN (the greens are too big)

Too Many Roundtrips (too manygreens)

The Green Problem #2:


66/123


Roundtrips

First View Repeat View

80 Requests

27 Requests

78 Requests

14 Requests

The Green Problem #2:


67/123


Roundtrips Every fetch still pays the HTTP

overhead penalty TTFB is still aproblem

Exacerbated by concurrency issues

Getting worse as number of objectsper page grows

Generally, the hardest problem tosolve



68/123



Too many connections


Concurrency

Bad Caching for repeat views No CDN (the greens are too big)

Too Many Roundtrips (too many

greens) Others

Examples of Other Problems


69/123


Examples of Other Problems

Blocking Javascript

3rd party calls (http://stevesouders.com/p3pc/)

What does it look like
http://stevesouders.com/p3pc/http://stevesouders.com/p3pc/


70/123


What does it look like

Summary


71/123


Summary


72/123


Lets Fix It!!


73/123


-Set Up


74/123

Possible Deployments


75/123


Possible Deployments

( )ERVICE CLOUD VIRTUALPPLIANCE


76/123


Acceleration Methodology

Stepwise Acceleration


77/123


Stepwise Acceleration

Start from the beginning and fix theeasy stuff

Step by step acceleration of the page

Apply techniques/methods/etc andsee the result

Try to make it as fast as possible

Kind of Like a Video Game


78/123



Level

Easy Hard



79/123



Level

ot Good Enough


80/123


81/123


:Step 1Low Hanging Fruit

Keep-Alive


82/123


Keep Alive

Solves the too-many connectionproblem (Less Orange!)

Will help alleviate the TCP connectionsetup overhead

7Connections

Compression


83/123


Compression

Addresses the too-many-bytesproblem (Less Blue!)

Well compress textual content(html/css/etc)

Not the only solution to less blue, butthe easiest

WebPageTest


84/123


WebPageTest

http://bit.ly/cKkjGz

Before and After
http://bit.ly/cKkjGzhttp://bit.ly/cKkjGzhttp://bit.ly/cKkjGz


85/123


Before and After

~ .7 8sec ~ .0 5sec

What We Helped: Keep-Alive


86/123


What We Helped: Keep Alive

7 Connections 19Connections

What We Helped: Compression


87/123


What We Helped: Compression

How Did We Do?


88/123


How Did We Do?

Original

+A Comp

First View

Repeat View

52%

71%

34%

94%

31%

51%

23%

75%

40%

62%

Improvement

How Does It Look


89/123


How Does It Look


90/123


91/123


:Step 2Repeat View Problem

Poor Client Side Caching


92/123


oo C e S de Cac g

Original

+A Comp

Problem Still Exists


93/123


~ .2sec

How Do We Get Better Caching


94/123


g

RFC 2616, Section 13

Caching headers should be used onstatic (non-changing) objects, sothey can be cached browser-side

And by intermediate caching proxies

Validators are not enough

WebPageTest


95/123


g

http://bit.ly/aCP3iX

Before and After
http://bit.ly/aCP3iXhttp://bit.ly/aCP3iX


96/123


~ .2sec

~ .0sec

How Did We Do?


97/123


+A Comp

ith GoodCaching

Repeat View 70% 42%67%Improvement

Pros and Cons


98/123


Pros

Good caching can have a majorperformance impact on repeat visitsto a page

Sometimes its easy to do Browsers generally pay attention

(although interpretation may varyslightly)

Cons

The spec appears scary

Invalidation and stale content


99/123


:Step 3CDN

What Does a CDN do?


100/123


Global network of

proxy caches

Get cacheable

content close tousers

Reduce TTFB

(smaller greens)

TTFB Problem


101/123


WebPageTest


102/123


g

http://bit.ly/a9ZJcF

Before and After
http://bit.ly/a9ZJcFhttp://bit.ly/a9ZJcF


103/123


~ .0 5sec ~ .3sec

TTFB Savings


104/123


Per object TTFB savings of~ %50

How Did We Do?


105/123


+A Comp

+CDN

First View 21% 17%22%Improvement

.7sec .3sec .7sececonds Gained

How Does It Look


106/123


Pros and Cons


107/123


Pro

Good mitigation of the TTFB problem

Established industry: lots of vendorsto choose from

Cons Sometimes costly

May require code change (CDNed

objects should be written to the CDNdomain)


108/123


:Step 4-Steroids the Hard Stuff

We Can Get Better!


109/123


till too manyroundtrips

till too many bytes

ot Fast!!nough

What to do Next?


110/123


Reduce Roundtrips

Combine images

Combine JavaScript

Combine CSS

Reduce Payload even more Minify CSS and JavaScript

Add Image Compression

Increase Concurrency Add a couple of domains to the mix

WebPageTest


111/123


http://bit.ly/bbT3v4
http://bit.ly/bbT3v4http://bit.ly/bbT3v4


112/123

How Did We Do?


113/123


+CDN

+Strangeloop

First View 19% 30%54%Improvement

.5sec .6sec .1sec45% 31%

econdsGained

81 107

11 37


114/123

Pros and Cons


115/123


Pros

Most significant benefit for thehardest part of the accelerationlifecycle

Address multiple performance points(somtimes multiple ones with thesame technique)

Cons

Its not easy

Regression


116/123


Congratulations - we are doneright?

3rd Party Content


117/123



118/123

Browsers?


119/123


Ch

rome 4 Ch

rome 5 Fi

reFox2 Fi

reFox

3 IE6

IE7

IE8

Sa

fari

4

Saf

ari

Mobile

Mobile Web


120/123


fast by

default

Flow


121/123


.3 8 Seconds

11 Roundtrips

Conversion

? ? ?


122/123


123/123

Velocity 2010 Workshop - The 90-Minute Optimization Life Cycle (Strangeloop)

Documents

Transcript of Velocity 2010 Workshop - The 90-Minute Optimization Life Cycle (Strangeloop)