More Related Content More from Strangeloop (13) Velocity 2010: The 90 Minute Optimization Life Cycle - Faster by default before our eyes?2. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 2
Today’s Hosts
Hooman Beheshti
VP Products
Strangeloop
Joshua Bixby
President
Strangeloop
3. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 3
Agenda
• Why is faster better
• Making a site faster
•Measurement
•Diagnosis
• Demos
• What did we miss
• Q&A
5. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 5
Why is faster better?
http://www.webperformancetoday.com/2010/06/15/everything-
you-wanted-to-know-about-web-performance/
(http://bit.ly/8YB3ET )
11. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 11
Impact of page load time on average daily
searches per user
-0.70%
-0.60%
-0.50%
-0.40%
-0.30%
-0.20%
-0.10%
0.00%
50ms
pre-header
100ms pre-
header
200ms post-
header
200ms post-
ads
400ms
post-header
13. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 13
Impact of additional delay on business
metrics
-5.00%
-4.50%
-4.00%
-3.50%
-3.00%
-2.50%
-2.00%
-1.50%
-1.00%
-0.50%
0.00%
50 200 500 1000 2000
Percentchange
Added delay
Queries per visitor Query refinement Revenue per visitor
Any clicks Satisfaction
15. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 15
Shopzilla had another angle
Big, high-traffic site
◦ 100M impressions a day
◦ 8,000 searches a second
◦ 20-29M unique visitors a
month
◦ 100M products
16 month re-engineering
◦ 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. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 16
5-12% increase in revenue
26. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 26
Measurement:
27. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 27
Where should we start?
Ylsow from
Page Speed from
29. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 29
Example: Gomez
30. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 30
HTTP Watch
31. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 31
Webpagetest.org
32. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 32
Visualizing the problem
33. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 33
Web Performance Problem
Definitions
• Backend:
Time from when the user makes the request to when
the last byte of the HTML document arrives. Includes
the time for the initial request to go up, the Web
server to stitch together the HTML, and for the
response to come back.
• Frontend:
Shorthand for everything after the HTML document
arrives. In reality, includes backend time (primarily
reading static files) and network time, as well as true
frontend activities such as parsing HTML, CSS, and JS,
and executing JS.
33www.strangeloopnetworks.com
34. Front-end Problem is getting worse
14.1
93.7
312.05
498
0
100
200
300
400
500
600
TotalBytes(K)
AverageNumberofObjects
60
50
30
40
20
10
0
49.92
25.7
2.3
Average Page Size (K)
Average Number of Objects
75.25
70
35. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 35
Waterfall chart
35
36. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 36
Waterfall chart
36
HTML
37. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 37
Waterfall chart
37
Resources
HTML
38. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 38
Waterfall chart
38
Start
Render
Document
Complete
Fully
Loaded
39. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 39
Waterfall component breakdown
39
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
40. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 40
Waterfall component breakdown
40
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
41. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 41
41
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
Waterfall component breakdown
42. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 42
42
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)
Waterfall component breakdown
43. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 43
Let’s Accelerate
The unsuspecting victim
45. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 45
A Few Points of Clarification
• We’re using this page because it’s more fun!
• 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!
46. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 46
Performance Summary
http://bit.ly/au01VY /
47. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 47
Waterfall
First View Repeat View
48. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 48
Per Object
49. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 49
Content Analysis by Type
50. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 50
Content Analysis by Domain
51. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 51
Show Me Where It Hurts
Problem Analysis
52. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 52
Performance Problems
• Too many connections (too much orange)
53. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 53
Too Many Connections
97 Connections
(almost one per request)
54. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 54
Too Many Connections
55. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 55
Performance Problems
• Too many connections (too much orange)
• Too many bytes (too much blue)
56. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 56
Too Many Bytes
By Type By Domain
57. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 57
Performance Problems
• Too many connections (too much orange)
• Too many bytes (too much blue)
• Concurrency
58. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 58
Concurrency
• Browsers can only open and use so many
connections at once
• www.browserscope.org
59. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 59
Performance Problems
• Too many connections (too much orange)
• Too many bytes (too much blue)
• Concurrency
• Bad Caching for repeat views
60. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 60
Bad Repeat View
Full Fetches
Validation
61. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 61
Bad Repeat View
Connections Bytes
62. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 62
Performance Problems
• 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)
63. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 63
The Green Problem #1: No CDN
TTFB
64. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 64
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.1
Accept: */*
Referer: http://en.oreilly.com/velocity2010/
Accept-Language: en-us
User-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 CLR
3.0.4506.2152; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Host: en.oreilly.com
Cookie: _session_id=6e76e8d4a4eccc63b4be7937e719ca9e
65. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 65
Performance Problems
• 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)
66. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 66
The Green Problem #2: Roundtrips
First View Repeat View
80 Requests
27 Requests
78 Requests
14 Requests
67. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 67
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
68. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 68
Performance Problems
• 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
69. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 69
Examples of Other Problems
• Blocking Javascript
• 3rd party calls (http://stevesouders.com/p3pc/)
70. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 70
What does it look like
http://bit.ly/a6COcQ
72. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 72
Let’s Fix It!!
74. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 74
Testing Environment
SERVICE (CLOUD)WebPageTest Client
(East Coast)
O’Reilly Datacenter
(West Coast)
75. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 75
Possible Deployments
SERVICE (CLOUD) VIRTUALAPPLIANCE
76. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 76
Acceleration Methodology
77. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 77
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
78. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 78
Kind of Like a Video GamePagePerformance
Level
Easy Hard
79. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 79
Kind of Like a Video GamePagePerformance
Level
Not Good Enough
80. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 80
Strangeloop Site Optimizer UI
81. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 81
Step 1:
Low Hanging Fruit
82. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 82
Keep-Alive
• Solves the too-many connection problem (Less
Orange!)
• Will help alleviate the TCP connection setup
overhead
97
Connections
83. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 83
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
84. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 84
WebPageTest
http://bit.ly/cKkjGz
85. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 85
Before and After
~17.8sec ~10.5sec
86. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 86
What We Helped: Keep-Alive
97 Connections 19 Connections
87. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 87
What We Helped: Compression
88. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 88
How Did We Do?
Original
KA+Comp
First View
Repeat View
52%
71%
34%
94%
31%
51%
23%
75%
40%
62%
Improvement
89. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 89
How Does It Look
http://bit.ly/917B61
90. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 90
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
91. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 91
Step 2:
Repeat View Problem
92. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 92
Poor Client Side Caching
Original
KA+Comp
93. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 93
Problem Still Exists
~6.2sec
94. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 94
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
95. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 95
WebPageTest
http://bit.ly/aCP3iX
96. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 96
Before and After
~6.2sec
~2.0sec
97. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 97
How Did We Do?
KA+Comp
With Good Caching
Repeat View 70% 42%67%
Improvement
98. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 98
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
99. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 99
Step 3:
CDN
100. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 100
What Does a CDN do?
• Global network of
proxy caches
• Get cacheable content
close to users
• Reduce TTFB (smaller
greens)
101. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 101
TTFB Problem
102. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 102
WebPageTest
http://bit.ly/a9ZJcF
103. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 103
Before and After
~10.5sec ~8.3sec
104. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 104
TTFB Savings
Per object TTFB savings of ~50%
105. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 105
How Did We Do?
KA+Comp
+CDN
First View 21% 17%22%
Improvement
0.7 sec 2.3 sec 2.7 secSeconds Gained
106. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 106
How Does It Look
http://bit.ly/92DbI0
107. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 107
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)
108. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 108
Step 4:
Steroids- the Hard Stuff
109. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 109
We Can Get Better!
Still too many roundtrips
Still too many bytes
Not Fast Enough!!
110. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 110
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
111. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 111
WebPageTest
http://bit.ly/bbT3v4
112. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 112
Before and After
~8.3sec
~3.8sec
113. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 113
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
114. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 114
How Does It Look
http://bit.ly/bNjKoW
115. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 115
Pros and Cons
• Pros
– Most significant benefit for the hardest part of the
acceleration lifecycle
– Address multiple performance points (sometimes
multiple ones with the same technique)
• Cons
– It’s not easy
– Regression
116. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 116
Congratulations - we are done…right?
117. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 117
3rd Party Content
118. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 118
Server Think Time
Server Think Time
119. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 119
Browsers?
0
1
2
3
4
Performance differences across browsers
120. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 120
Mobile Web
fast by default
121. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 121
Flow
3.8 Seconds
11 Roundtrips
Conversion
? ? ?
122. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 122
Regression
“Our Developers have repeatedly redesigned
the web site’s software to scale but the job is
never done. It’s kind of like painting the
Golden Gate Bridge, where every time you
finish, it’s time to start over again. There are
many lessons to be learned and we learn
them the hard way by coding.”
Jim Benedetto
MySpace Vice President
Technology
Editor's Notes How much was fast enough? It was anybody’s guess. And guess they did.This is Zona’s formula for patience, the basis for the “eight second rule.” Unfortunately, things like tenacity, importance, and natural patience aren’t concrete enough for the no-nonsense folks that run web applications. And guess they did.This is Zona’s formula for patience, the basis for the “eight second rule.” Unfortunately, things like tenacity, importance, and natural patience aren’t concrete enough for the no-nonsense folks that run web applications. One example of this is performance experimentation that Google’s done. Google’s a perfect lab. Not only do they have a lot of traffic, they also have computing resources to do back-end analysis of large data sets. Plus, they’re not afraid of experimentation – in fact, they insist on it. So they tried different levels of performance and watched what happened to visitors. The results, which they presented at Velocity in May, were fascinating. There was a direct impact between delay and the number of searches a user did each day – and to make matters worse, the numbers often didn’t improve even when the delay was removed. You may think 0.7% drop isn’t significant, but for Google this represents a tremendous amount of revenue. Microsoft’s Bing site is a good lab, too. They looked at key metrics, or KPIs, of their search site. They showed that as performance got worse, all key metrics did, too. Not just the number of searches, but also the revenue (earned when someone clicks) and refinement of searches. Microsoft’s Bing site is a good lab, too. They looked at key metrics, or KPIs, of their search site. Shopzilla overhauled their entire site, dramatically reducing page load time, hardware requirements, and downtime. They saw a significant increase in revenues Microsoft’s Bing site is a good lab, too. They looked at key metrics, or KPIs, of their search site. One example of this is performance experimentation that Google’s done. Google’s a perfect lab. Not only do they have a lot of traffic, they also have computing resources to do back-end analysis of large data sets. Plus, they’re not afraid of experimentation – in fact, they insist on it. So they tried different levels of performance and watched what happened to visitors. Website owners are sending out increasingly huge web pages through a pipeline whose ability has not grown in the same proportion.Web page objects, then and now:1995: The average web page contained just 2.3 objects. That means just 2.3 calls to whatever data centers were serving the site.Today: The average web page contains a whopping 75.25 objects – everything from CSS to images to Javascript. That means 75.25 server round trips are needed to pull all the page’s resources to the user’s browser. The result: pages that load slowly and inconsistently.Page size, then and now:1995: The average page size was a lean 14.1k.Today: The average page size is a bloated 498k.