london web performance meetup: performance for mortal companies

© 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2

Agenda

• Introduction

• What is performance automation

• Basic terminology and concepts

• Automation at work

• Performance stats and Case Studies

• Market overview

• Q&A

Web Performance

Making sites faster

without changing code


Basic terminology and concepts


Waterfall chart

12


Waterfall chart

13

HTML


Waterfall chart

14

Resources

HTML


Waterfall chart

15

Start Render

Document Complete

FullyLoaded


Waterfall component breakdown

16

DNS lookup

DNS Lookup

• Takes one packet in each direction

• Time is limited to the latency of the connection (DSL/Cable/etc) for the single round trip



17

TCP Connection

TCP Connection

• 3 packets

- ClientServer (SYN) - ServerClient (SYN/ACK) - ClientServer (ACK)

• Time is limited to the latency of the connection (DSL/Cable/etc) for the single round trip


Time To First Byte

Time to First Byte

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

• Includes the latency of the connect ion (DSL/Cable/etc) for a single round trip

• Also includes whatever server think time was involved in generating the response



Content Download

Download

• Time it takes for the entire content of the response to get to the browser

• Mostly limited by the bandwidth limit of the connection (DSL/Cable/etc)



First view vs Repeat View


Concurrency

Blocking

Concurrent

Concurrency

•Blocking script don't let the browser use available resources (network, connections, etc) to fetch more content from the server

•The overall page load time and render time are both affected negatively)


Case Study: Automation in action


Methodology


Let’s Automate


A Few Points of Clarification

• We’ll use it to describe where performance pain points are, but that doesn’t mean the page actually has these problems

• What we’re going to do:

Not so good(slow)

Awesome(fast)

Improve performance incrementally

* The real Velocity site is somewhere in the middle!


Performance Summary

http://bit.ly/au01VY /

http://bit.ly/au01VY

http://www.webpagetest.org/result/100614_aacdab746259dd7c89dfe994c1997d3b/


Waterfall

First View Repeat View


Per Object


Content Analysis by Type


Content Analysis by Domain


Show Me Where It HurtsProblem Analysis


Performance Problems

• Too many connections (too much orange)


Too Many Connections

97 Connections(almost one per request)


Too Many Connections



• Too many connections (too much orange)• Too many bytes (too much blue)


Too Many Bytes

By Type By Domain



• Too many connections (too much orange)• Too many bytes (too much blue)• Concurrency


Concurrency

• Browsers can only open and use so many connections at once

• www.browserscope.org

http://www.browserscope.org/



• Too many connections (too much orange)• Too many bytes (too much blue)• Concurrency• Bad Caching for repeat views


Bad Repeat View

Full Fetches

Validation


Bad Repeat ViewConnections Bytes



• Too many connections (too much orange)• Too many bytes (too much blue)• Concurrency• Bad Caching for repeat views• No CDN (the greens are too big)


The Green Problem #1: No CDNTTFB



• Too many connections (too much orange)• Too many bytes (too much blue)• Concurrency• Bad Caching for repeat views• No CDN (the greens are too big)• Too Many Roundtrips (too many greens)


The Green Problem #2: Roundtrips

First View Repeat View

80 Requests

27 Requests

78 Requests

14 Requests


The Green Problem #2: Roundtrips

• Every fetch still pays the HTTP overhead penalty TTFB is still a problem

• Exacerbated by concurrency issues• Getting worse as number of objects per page

grows• Generally, the hardest problem to solve



• Too many connections• Too many bytes (too much blue)• Concurrency• Bad Caching for repeat views• No CDN (the greens are too big)• Too Many Roundtrips (too many greens)• Others


Examples of Other Problems

• Blocking Javascript

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

http://stevesouders.com/p3pc/


Summary


Let’s Fix It!!


Set-Up


Testing Environment

Automation SERVICE (CLOUD)

WebPageTest Client(East Coast)

O’Reilly Datacenter (West Coast)


Acceleration Methodology


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


Step 1:

Low Hanging Fruit


Keep-Alive

• Solves the too-many connection problem (Less Orange!)

• Will help alleviate the TCP connection setup overhead

97 Connections


Compression

• Addresses the too-many-bytes problem (Less Blue!)

• We’ll compress textual content (html/css/etc)• Not the only solution to less blue, but the easiest


WebPageTest

http://bit.ly/cKkjGz




Before and After

~17.8sec ~10.5sec


What We Helped: Keep-Alive

97 Connections 19 Connections


What We Helped: Compression


How Did We Do?

Original

KA+Comp

First View

Repeat View

52%

71%

34%

94%

31%

51%

23%

75%

40%

62%

Improvement

Before and after: Keep-alives & compression

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




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 they’re just not enough


Step 2:

Repeat View Problem


Poor Client Side Caching

Original

KA+Comp


Problem Still Exists

~6.2sec


How Do We Get Better Caching

• RFC 2616, Section 13• Caching headers should be used on static (non-

changing) objects, so they can be cached browser-side – And by intermediate caching proxies

• Validators are not enough


WebPageTest

http://bit.ly/aCP3iX

http://bit.ly/aCP3iX


Before and After

~6.2sec

~2.0sec


How Did We Do?

KA+Comp

With Good Caching

Repeat View 70% 42%67%

Improvement


Pros and Cons

• Pros– Good caching can have a major performance impact

on repeat visits to a page– Sometimes it’s easy to do– Browsers generally pay attention (although

interpretation may vary slightly)

• Cons– The spec appears scary– Invalidation and stale content


Step 3:

CDN


What Does a CDN do?

• Global network of proxy caches

• Get cacheable content close to users

• Reduce TTFB (smaller greens)


TTFB Problem


WebPageTest

http://bit.ly/a9ZJcF

http://bit.ly/a9ZJcF


Before and After

~10.5sec ~8.3sec


TTFB Savings

Per object TTFB savings of ~50%


How Did We Do?

KA+Comp

+CDN

First View 21% 17%22%

Improvement

0.7 sec 2.3 sec 2.7 secSeconds Gained

Before and after: Adding a CDN

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

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


Pros and Cons

• Pro– Good mitigation of the TTFB problem– Established industry: lots of vendors to choose from

• Cons– Sometimes costly– May require code change (CDN’ed objects should be

written to the CDN domain)


Step 4:

Steroids- the Hard Stuff


We Can Get Better!

Still too many roundtrips

Still too many bytes

Not Fast Enough!!


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

http://bit.ly/bbT3v4

http://bit.ly/bbT3v4


Before and After

~8.3sec

~3.8sec


How Did We Do?

+CDN

+Strangeloop

First View 19% 30%54%

Improvement

0.5 sec 4.6 sec 4.1 sec

45% 31%

Seconds Gained

81 107

11 37

Before and after: The final, fastest version

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

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


Pros and Cons

• Pros– Most significant benefit for the hardest part of the

acceleration lifecycle– Address multiple performance points (somtimes

multiple ones with the same technique)

• Cons– It’s not easy– Regression


Different Browsers

Chrome 9Chrome

10 FireFox 3

FireFox 4IE 6 IE 7 IE 8

Safari 5Series1

0

0.5

1

1.5

2

2.5

3

3.5

4Performance differences across browsers

Safari

Mobile


Flow

3.8 Seconds11 Roundtrips

Conversion

? ? ?


“These stats don’t apply to me.”


Conversion Cart size Sales

9%

11%

13%


Revenue Per visit Overall revenue

8%

6%


“These stats don’t apply to me either.”


How to perform a 5-minute speed/revenue benefit analysis of your site


Step 1

Perform WebPagetests in IE7 and IE8.

Calculate the load time difference as a percentage.


Step 2

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


Step 3

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


Step 3 con’t

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


Step 4

Correlate the results of steps 1 to 3 in simple graphs.


Step 5

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

strangeloopnetworks.com/test-your-website


Step 6

Compare these gains to your graphs from step 4.

What lift can you anticipate in value per visit?


Caveats

• Correlation does not imply causation.

• Browser and connection speed might imply something about the buyer (i.e. s/he is more affluent) that is unrelated to the effects of speed.


But this trend seems to hold true in the real world.


Case study


How to be your company’s in-house performance evangelist


The average exec wants to know 3 things

• What’s in it for the company?

• What’s in it for me?

• How do we compare to our competitors?


When talking to an exec…

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

“Our site is slower than our competitors. We’re losing money.”


What to say: #2

“We’ve proven that, when our site is faster for users, they spend more.”


What to say: #3

“This is where we should be aiming.”


What to say: #4

“Consumers expect EVERY website to load fast.”


Performance automation market


1993 20021999 20062000 200719961995 1998 20042003 20092008 2010


“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 browser”

Delivery

Transformation

History of performance automation


Original Delivery Transformation

9.5 seconds63 roundtrips



Delivery vs Transformation


Delivery market

Delivery

Load Balancers (scale and availability)

CDN (scale, availability and performance)

Other

TCP (Fastsoft)

WAN Optimization (Riverbed)

DNS (Neustar)


Delivery market

Delivery

Load Balancers• Compression Smaller blues on HTML and resources• TCP Optimization & Multiplexing Smaller greens on HTML and some resources• Caching Smaller greens on HTML and resources• SSL Offload Higher scale and potentially smaller greens on HTML and smaller

blues

CDN- Static and Dynamic• Static object delivery smaller greens on resources• ESI smaller greens on HTML• DNS smaller teal • Compression Smaller blues on HTML • TCP Optimizations smaller greens and blues on HTML and some resources• Routing Optimization smaller blues on HTML and some resources


Players delivery marketDelivery

Load Balancers

Basic

Kemp

Barracuda

Coyote Point

Advanced

F5

Citrix

Radware

Zeus

Cisco

CDN

Small object delivery

Akamai

Level 3

Limelight

CD Networks

Edgecast

Dynamic

Akamai

Level 3

CDNetworks

Contendo


Transformation market

Transformation

Server side

Network

Cloud

Beta

Production



Transformation

Server

Platform agnostic

Strangeloop (Virtual)

Platform specific

Aptimize

Webo

Mod_Page speed

Network

Basic

F5 Web Acc

Cisco ACE4710

(fineground)

Advanced

Strangeloop

Aptimize (beta)

Cloud

Basic

Akamai

Limelight

Level 3

Advanced (beta)

Limelight (Acceloweb)

Torbit

Yotta

Blaze

Cotendo ( page_speed

)

Advanced (production)

Strangeloop

Level 3 (Strangeloop)

london web performance meetup: performance for mortal companies

Technology

wco