London Meetup - Performance for Mortal Companies - JOSH-FINAL


2/134

2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2

Agenda

IntroductionWhat is performance automation

Basic terminology and concepts

Automation at work

Performance stats and Case Studies

Market overview

Q&A-


3/134



4/134



5/134

Web Performance


6/134

Making sites faster

without changing code


7/134


8/134


9/134

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


10/134

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


11/134



12/134

12 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 12

Waterfall chart


13/134


Waterfall chartHTML


14/134


Waterfall chart

Resources

HTML


15/134


Waterfall chartStart

RenderDocument

CompleteFullyLoaded


16/134


Waterfall component breakdown

DNSlookup

DNS Lookup

Takes one packet in eachdirection

Time is limited to the latency ofthe connection(DSL/Cable/etc) for thesingle round trip


17/134



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


18/134


Time ToFirst

ByteTime to First Byte

Time from the request packet(usually 1) to the first packetof the response

Includes the latency of theconnect ion(DSL/Cable/etc) for a singleround trip

Also includes whatever serverthink time was involved ingenerating the response



19/134


ContentDownload

Download

Time it takes for the entirecontent of the response toget to the browser

Mostly limited by the bandwidthlimit of the connection(DSL/Cable/etc)



20/134


First view vs Repeat View


21/134


Concurrency

Blocking

Concurrent

Concurrency

Blocking script don't let thebrowser use available resources(network, connections, etc) tofetch more content from theserver

The overall page load time andrender time are both affectednegatively)


22/134


Case Study: Automation in action


23/134


Methodology


24/134


Lets Automate


25/134



26/134


A Few Points of Clarification

Well use it to describe where performance painpoints are, but that doesnt mean the pageactually has these problems

What were going to do:

Not sogood(slow)

Awesome(fast)

Improve performance incrementally

* The real Velocity site is somewhere in the middle!


27/134


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


28/134


Waterfall

First View Repeat View


29/134


Per Object


30/134


Content Analysis by Type


31/134


Content Analysis by Domain


32/134


Show Me Where It Hurts

Problem Analysis


33/134


Performance Problems

Too many connections (too much orange)


34/134


Too Many Connections

97 Connections(almost one per request)


35/134


Too Many Connections


36/134




Too many bytes (too much blue)


37/134


Too Many Bytes

By Type By Domain


38/134





Concurrency


39/134


Concurrency

Browsers can only open and use so manyconnections at once

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


40/134





Concurrency

Bad Caching for repeat views


41/134


Bad Repeat View

Full Fetches

Validation


42/134


Bad Repeat ViewConnections Bytes


43/134





Concurrency


No CDN (the greens are too big)


44/134


The Green Problem #1: No CDNTTFB


45/134





Concurrency



Too Many Roundtrips (too many greens)


46/134


The Green Problem #2: Roundtrips

First View Repeat View

80Requests

27 Requests

78Requests

14 Requests


47/134


The Green Problem #2: Roundtrips

Every fetch still pays the HTTP overhead penaltyTTFB is still a problem

Exacerbated by concurrency issues

Getting worse as number of objects per page

grows Generally, the hardest problem to solve


48/134



Too many connections


Concurrency



Too Many Roundtrips (too many greens)

Others


49/134


Examples of Other Problems

Blocking Javascript

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


50/134


Summary


51/134


Lets Fix It!!


52/134


Set-Up


53/134


Testing Environment

AutomationSERVICE (CLOUD)

WebPageTest Client(East Coast)

OReilly Datacenter(West Coast)


54/134


Acceleration Methodology

S


55/134


Stepwise Acceleration

Start from the beginning and fix the easy stuff

Step by step acceleration of the page

Apply techniques/methods/etc and see the result

Try to make it as fast as possible


56/134


Step 1:

Low Hanging Fruit

K Ali


57/134


Keep-Alive

Solves the too-many connection problem (LessOrange!)

Will help alleviate the TCP connection setupoverhead

97Connections

C i


58/134


Compression

Addresses the too-many-bytes problem (LessBlue!)

Well compress textual content (html/css/etc)

Not the only solution to less blue, but the easiest

W bP T t


59/134


WebPageTest

http://bit.ly/cKkjGz

B f d Aft
http://bit.ly/cKkjGzhttp://bit.ly/cKkjGzhttp://bit.ly/cKkjGz


60/134


Before and After

~17.8sec ~10.5sec

Wh t W H l d K Ali


61/134


What We Helped: Keep-Alive

97 Connections 19 Connections

Wh t W H l d C i


62/134


What We Helped: Compression

H Did W D ?


63/134


How Did We Do?

Original

KA+Comp

First View

Repeat View

52%

71%

34%

94%

31%

51%

23%

75%

40%

62%

Improvement


64/134

Before and after: Keep-alives & compressionhttp://www.youtube.com/watch?v=KPYBF41yiFw

Pros and Cons
http://www.youtube.com/watch?v=KPYBF41yiFwhttp://www.youtube.com/watch?v=KPYBF41yiFw


65/134


Pros and Cons

Pros

Really easy to do

Single configuration switches in servers, proxies,or load balancers

Good benefit seen right away

Cons

Compression has processing overhead

On their own theyre just not enough


66/134


Step 2:

Repeat View Problem

Poor Client Side Caching


67/134


Poor Client Side Caching

Original

KA+Comp

Problem Still Exists


68/134


Problem Still Exists

~6.2sec

How Do We Get Better Caching


69/134


How Do We Get Better Caching

RFC 2616, Section 13

Caching headers should be used on static (non-changing) objects, so they can be cachedbrowser-side

And by intermediate caching proxies Validators are not enough

WebPageTest


70/134


WebPageTest

http://bit.ly/aCP3iX

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


71/134


Before and After

~6.2sec

~2.0sec

How Did We Do?


72/134


How Did We Do?

KA+Comp

With Good

Caching

Repeat View 70% 42%67%

Improvement


73/134

Pros and Cons


74/134


Pros and Cons

Pros

Good caching can have a major performanceimpact on repeat visits to a page

Sometimes its easy to do

Browsers generally pay attention (although

interpretation may vary slightly)

Cons

The spec appears scary

Invalidation and stale content


75/134


Step 3:

CDN

What Does a CDN do?


76/134


What Does a CDN do?

Global network of

proxy caches

Get cacheable

content close tousers

Reduce TTFB

(smaller greens)

TTFB Problem


77/134


TTFB Problem

WebPageTest


78/134


WebPageTest

http://bit.ly/a9ZJcF

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


79/134


Before and After

~10.5sec ~8.3sec

TTFB Savings


80/134


TTFB Savings

Per object TTFB savings of~50%

How Did We Do?


81/134


How Did We Do?

KA+Comp

+CDN

First View 21% 17%22%

Improvement

0.7 sec 2.3 sec 2.7 secSeconds Gained


82/134

Before and after: Adding a CDN

http://www.youtube.com/watch?v=BR5hO5rL8lE

Pros and Cons
http://www.youtube.com/watch?v=BR5hO5rL8lEhttp://www.youtube.com/watch?v=BR5hO5rL8lE


83/134


Pros and Cons

Pro

Good mitigation of the TTFB problem

Established industry: lots of vendors to choosefrom

Cons

Sometimes costly

May require code change (CDNed objects shouldbe written to the CDN domain)


84/134


Step 4:

Steroids- the Hard Stuff

We Can Get Better!


85/134


We Can Get Better!

Still too many roundtrips

Still too many bytes

Not Fast Enough!!

What to do Next?


86/134


What to do Next?

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


87/134


eb age es

http://bit.ly/bbT3v4

Before and After
http://bit.ly/bbT3v4http://bit.ly/bbT3v4


88/134


~8.3sec

~3.8sec

How Did We Do?


89/134


+CDN

+Strangeloop

First View 19% 30%54%

Improvement

0.5 sec 4.6 sec 4.1 sec

45% 31%

SecondsGained

81 107

11 37


90/134

Before and after: The final, fastest version

http://www.youtube.com/watch?v=IPn0T1UacIA

Pros and Cons
http://www.youtube.com/watch?v=IPn0T1UacIAhttp://www.youtube.com/watch?v=IPn0T1UacIA


91/134


Pros

Most significant benefit for the hardest part of theacceleration lifecycle

Address multiple performance points (somtimesmultiple ones with the same technique)

Cons Its not easy

Regression

Different Browsers


92/134


Different Browsers

Chrom

e9Ch

rome

10 Fire

Fox3Fir

eFox4 IE6 IE7 IE8

Safari5 Safar

i

Mobile

Flow


93/134


Flow

3.8 Seconds11 Roundtrips

Conversion

? ? ?


94/134



95/134



96/134



97/134



98/134



99/134



100/134


These stats dont apply to me.


101/134



102/134



103/134


These stats dont apply to meeither.


104/134


How to perform a 5-minutespeed/revenue benefitanalysis of your site

Step 1


105/134


Step 1

Perform WebPagetests in IE7 and IE8.

Calculate the load time difference as a

percentage.

Step 2


106/134


Step 2

Use Google Analytics to calculate yourcurrent order value per visit for IE7 and IE8.

Step 3


107/134


Step 3

Determine your order value per visit, byconnection speed (cable, DSL, T1, dialup).

Step 3 cont


108/134


Step 3 con t

Determine your order value per visit, byconnection speed (cable, DSL, T1, dialup).

Step 4


109/134


Step 4

Correlate the results of steps 1 to 3 insimple graphs.

Step 5


110/134


Step 5

Test your site to get a sense of how muchfaster it could be.

strangeloopnetworks.com/test-your-website

Step 6


111/134


Step 6

Compare these gains to your graphs fromstep 4.

What lift can you anticipate in value pervisit?

Caveats


112/134


Correlation does not imply causation.

Browser and connection speed might imply

something about the buyer (i.e. s/he is moreaffluent) that is unrelated to the effects ofspeed.


113/134


But this trend seems to hold

true in the real world.

Case study


114/134


y


115/134


How to be your companys in-house performance evangelist

Th t t k 3 thi


116/134


The average exec wants to know 3 things

Whats in it for the company?

Whats in it for me?

How do we compare to our competitors?

When talking to an exec


117/134


g

Tell the time, not how the watch works.

Most important, urgent point first.

Keep it short.

Keep it simple.

Make it visual.

Be ready to give context.

What to say: #1


118/134


y

Our site is slower than our competitors.

Were losing money.


119/134



120/134


What to say: #2


121/134


y

Weve proven that, when our site is faster for

users, they spend more.

What to say: #3


122/134


This is where we should be aiming.

What to say: #4


123/134


Consumers expect

EVERY website toload fast.


124/134


Performance automation market


125/134


1993 20021999 20062000 200719961995 1998 20042003 20092008 2010

History of performance automation


126/134


I will deliver what the server gives me.as efficiently as possible to the browser

I will transform what the server gives me to optimize it for the user s browserDelivery

Transformation

O i i l D li T f ti

Delivery vs Transformation


127/134


Original Delivery Transformation

9.5 secondsroun tr ps 5.7 secondsroun tr ps s on s roun tr ps

Delivery market


128/134


Delivery market


129/134


Players delivery market


130/134


Transformation market


131/134




132/134




133/134



134/134

London Meetup - Performance for Mortal Companies - JOSH-FINAL

Documents