London Web Performance Meetup: Performance for mortal companies

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

9
www.strangeloopnetworks.com

10
www.strangeloopnetworks.com

Waterfall chart
12

Waterfall chart
HTML
13

Waterfall chart
HTML
Resources
14

Waterfall chart
Start
Render
Document
Complete
Fully
Loaded
15

Waterfall component breakdown
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
16

TCP Connection
TCP Connection
3 packets
- ClientServer (SYN)
- ServerClient (SYN/ACK)
- ClientServer (ACK)
Time is limited to the latency of the connection (DSL/Cable/etc) for the single round trip
17

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
18

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)
19

First view vs Repeat View
20

Concurrency
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)
Blocking
Concurrent
21

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:
Improve performance incrementally
Not so good
(slow)
Awesome
(fast)
* The real Velocity site is somewhere in the middle!

Performance Summary
http://bit.ly/au01VY /

Waterfall
First View
Repeat View

Per Object

Content Analysis by Type

Content Analysis by Domain

Show Me Where It Hurts
Problem Analysis

Performance Problems
Too many connections (too much orange)

Too Many Connections
97 Connections
(almost one per request)

Too Many Connections

Too many bytes (too much blue)

Too Many Bytes
By Type
By Domain

Concurrency

Concurrency
Browsers can only open and use so many connections at once
www.browserscope.org

Concurrency
Bad Caching for repeat views

Bad Repeat View
Full Fetches
Validation

Bad Repeat View
Connections
Bytes

Concurrency
No CDN (the greens are too big)

The Green Problem #1: No CDN
TTFB

Concurrency
Too Many Roundtrips (too many greens)

The Green Problem #2: Roundtrips
Repeat View
First View
80 Requests
78 Requests
27 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
Concurrency
Too Many Roundtrips (too many greens)
Others

Examples of Other Problems
Blocking Javascript
3rd party calls (http://stevesouders.com/p3pc/)

Summary

Let’s Fix It!!

Set-Up

Testing Environment
WebPageTest Client
(East Coast)
O’Reilly Datacenter
(West Coast)
Automation
SERVICE (CLOUD)

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
Improvement
First View
Repeat View
52%
71%
34%
94%
31%
51%
23%
75%
40%
62%

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

Before and After
~2.0sec
~6.2sec

How Did We Do?
KA+Comp
With Good Caching
Improvement
Repeat View
70%
42%
67%

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

Before and After
~8.3sec
~10.5sec

TTFB Savings
Per object TTFB savings of ~50%

How Did We Do?
KA+Comp
+CDN
Improvement
First View
21%
17%
22%
0.7 sec
2.3 sec
2.7 sec
Seconds Gained

Before and after: Adding a CDN
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

Before and After
~3.8sec
~8.3sec

How Did We Do?
+CDN
81
107
+Strangeloop
11
37
Improvement
First View
19%
30%
54%
45%
31%
0.5 sec
4.6 sec
4.1 sec
Seconds Gained

Before and after: The final, fastest version
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
Safari Mobile
Chrome 10
IE 7
IE 8
IE 6
FireFox 4
Chrome 9
FireFox 3
Safari 5

Flow
Conversion
?
?
?
3.8 Seconds
11 Roundtrips

“These stats don’t apply to me.”

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

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

Step 1Perform WebPagetests in IE7 and IE8. Calculate the load time difference as a percentage.

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

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

Step 3 con’tDetermine your order value per visit, by connection speed (cable, DSL, T1, dialup).

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

Step 5Test your site to get a sense of how much faster it could be.
strangeloopnetworks.com/test-your-website

Step 6Compare 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
2002
1999
2006
2000
2007
1996
1995
1998
2004
2003
2009
2008
2010

History of performance automation
“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

Deliveryvs Transformation
Transformation
Delivery
Original
9.5 seconds
63 roundtrips
5.7 seconds
63 roundtrips
2.1 seconds
9 roundtrips

Delivery market

Players delivery market

Transformation market

http://www.seriticonsulting.com	499
http://www.strangeloopnetworks.com	154
http://www.linkedin.com	60
http://stage.strangeloopnetworks.com	18
http://www.strangeloopnetworks.net	1
http://www.strangeloopnetwork.com	1

London Web Performance Meetup: Performance for mortal companies

by Strangeloop

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 733

Statistics

London Web Performance Meetup: Performance for mortal companies Presentation Transcript