Improving Performance by Changing the Rules - From Fast to SPDY Ido Safruti (Cotendo Inc), Mike Belshe (Google) 1:50pm Wednesday, 06/15/2011 http://velocityconf.com/velocity2011/public/schedule/detail/21089

1. From Fast to SPDY
Ido Safruti,
Mike Belshe,

2. SPDY

3. SPDY
ee

4. Agenda
 Challenges of HTTP/1.1
 SPDY
 Some data, and results
 How we tune today
 What’s next

5. rfc2616: HTTP/1.1
drafted:1998
released June 1999

6. What else was there in 1998

7. What else was there in 1998

8. What else was there in 1998

9. What else was there in 1998

10. What else was there in 1998

11. What else was there in 1998

12. What else was there in 1998
http://web.archive.org/web/19980425182703/http://geocities.com/

13. What else was there in 1998
4/25/1998
no external scripts or css files
20 images, ~65KB entire page
http://web.archive.org/web/19980425182703/http://geocities.com/

14. Did They Plan for That!?

15. HTTP/1.1
 Compression
 Headers
 Poor connection management
 Only one request can be done at a time (Half duplex)
 Particularly important on high latency links (mobile)
 short lived connections
 security - optional

16. Compression
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

17. Compression
Optional
Only for response body
~99% of browsers support
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

18. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

19. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

20. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
no request compression
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

21. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
no request compression
no header compression
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements

22. Headers
 Redundant
 Repeat on EVERY request/response
 Can’t compress
 User-agent
 Cookies

23. HTTP Connection - under the hood
Client Server

24. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Client Server

25. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Client Server

26. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Request/Response = 0.5 RTT
Client Server

27. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Request/Response = 0.5 RTT
}
Client Server

28. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Request/Response = 0.5 RTT
}
}
Client Server

29. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Request/Response = 0.5 RTT
} Spun additional connections
}
Client Server

30. HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Request/Response = 0.5 RTT
Slow Start - 30KB ~ 4 RTT (vs. 1 RTT warm)
Spun additional connections
Client Server

31. “Lost” Capacity on each RTT
User Data: User Data:
average bandwidth average RTT
BW Mbps RTT ms
Global 1.9 Broadband 30
US 5.1 Coast-to-Coast 100
Mobile - US 1.1 3G device-GW 80-200
Mobile - EU ~2
Source: State of the Internet, Q4 2010
http://www.akamai.com/stateoftheinternet/
US Broadband: 63.7KB
US Mobile: 27.5KB
Average obj size 8.1KB
Source: HTTP Archive, 6/1/2011 data for Top 1,000
http://httparchive.org

32. Security is optional
http://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg

33. Enters SPDY!

34. Requirements
 Avoid requiring the website author to change content
Allow for incremental changes
Performing "better" with content changes is okay
Performing "worse" without content changes is unacceptable
 Perform always better, never worse than HTTP
 Drop-in replacement from webapp's point of view
 Changing the web server/application server is inevitable and therefore
acceptable

35. What is SPDY?
 Goal: Reduce Web Page Load time.
 Multiplexing
 Better utilize client connections
 Compression
 HTTP headers are excessive
 Uplink bandwidth is limited
 Prioritization
 Today the browser holds back
 Priorities enable multiplexing
 Encrypted & Authenticated
 Eavesdropping at the Cafe must be stopped
 Server Push
 Websites do some of this today with data URLs

36. Deployment Status

37. Deployment Status
 Google
 Enabled for all Google SSL traffic
 On by default since Chrome 6

38. Deployment Status
 Google
 Enabled for all Google SSL traffic
 On by default since Chrome 6
 CDNs/Service providers:
 Cotendo

39. Deployment Status
 Google
 Enabled for all Google SSL traffic
 On by default since Chrome 6
 CDNs/Service providers:
 Cotendo
 Server implementations:
 Strangeloop
 SPDY Proxy available
 Others: C++, Python, Ruby, Go

40. Deployment Status
 Google
 Enabled for all Google SSL traffic
 On by default since Chrome 6
 CDNs/Service providers:
 Cotendo
 Server implementations:
 Strangeloop
 SPDY Proxy available
 Others: C++, Python, Ruby, Go
 Client implementation
 Chrome
 Android coming...

41. Results

42. Yahoo! Homepage, over broadband network

43. Yahoo! homepage
HTTP
Broadband
RTT = 20ms
Page Load: 1.23sec

44. Yahoo! homepage
SPDY
(via Cotendo)
Broadband
RTT = 20ms
Page Load: 1.21sec
-2%

45. Amazon.com Homepage, over 3G network

46. Amazon.com Homepage
HTTP
3G, AT&T
RTT = 200+ms
Page Load: 12.50sec

47. Amazon.com Homepage
SPDY
(via Cotendo)
3G AT&T
RTT = 200+ms
Page Load: 6.26sec
-49%

48. HTTPS vs SPDY (Production)

49. Increasing Parallelism

50. Less is More - Conns, Bytes, Packets

51. Not Too Shabby WebSockets
 docs.google.com has a "hanging get" for every doc open
 how to scale beyond 6 connections per domain?
 docs[1-N].google.com
 gets expensive, complicated, and is horribly inefficient
 SPDY is easy, works great, efficient
 Header compression mitigates the inefficiency of a hanging GET

52. Can't We Address Latency & Security Separately?

53. Can't We Address Latency & Security Separately?
No.

54. Can't We Address Latency & Security Separately?
 If eavesdropping in the cafe is still possible in 2020 with trivial tools, we have
failed our users.
 Security is not just for banks!
 Social/Mail/Content is a major target
 example: Comodo attack
 Firesheep tools make sniffing easy
 Major content providers want privacy
 Facebook opt-in
 Twitter opt-in
 Google working toward 100%

55. How we tune today

56. High Performance Web Sites
1.Make fewer HTTP requests
2.Use CDN
3.Add expires header
4.Gzip Components
5.Put stylesheets at the top
6.Put scripts at the bottom
7.Avoid CSS expressions
8.Make JS and CSS external
9.Reduce DNS lookups
10.Minify JS
11.Avoid redirects
12.Remove duplicate scripts
13.Configure Etags
14.Make Ajax cacheable
15.Sharding domains

57. High Performance Web Sites
1.Make fewer HTTP requests
2.Use CDN
3.Add expires header
4.Gzip Components
Du
5.Put stylesheets at the top
6.Put scripts at the bottom e
7.Avoid CSS expressions To
8.Make JS and CSS external HT
9.Reduce DNS lookups TP
10.Minify JS
Li
11.Avoid redirects m
12.Remove duplicate scripts ita
13.Configure Etags tio
14.Make Ajax cacheable ns
15.Sharding domains !

58. Firetruck

59. Domain Sharding

60. Domain Sharding
 Pros:
 Parallelism in HTTP
 Cookieless domains for static content

61. Domain Sharding
 Pros:
 Parallelism in HTTP
 Cookieless domains for static content

62. Domain Sharding
 Pros:
 Parallelism in HTTP
 Cookieless domains for static content
 Cons:
 DNS time
 Connection establishment overhead
 TCP slowstart / warmup
 SSL
 maintaining many connections
 user cache
 Prevents browser optimizations

63. Reduce number of requests
 Inlining
 Spriting
 Data URLs
 Combining javascripts and CSS files
 Cons:
 reduced cache efficiency
 Complicated

64. New Class of FEO

65. Rethink your optimizations
 As rules change, your need to re-evaluate your best practices
 13 years is a long time! start at the beginning...
 But also presents many new opportunities
 Delivery priorities
 Smart Push
 Simple web code
 Automate!

66. Image Compression
Number of Requests Transfer Size in KB
Other
HTML Other HTML
7.0
6.5 99 32
Scripts
Scripts 119
13.0
Stylesheets
Stylesheets
25
3.5
Images
Images
55.0
415
Source: http://httparchive.org/trends.php?s=Top1000

67. In mobile even stronger!
Number of Requests Transfer Size in KB
Other HTML
2 Other
4 HTML
6
42
Scripts
7
Scripts
Stilesheets 80
2
Images
Images 228
31 Stilesheets
20
Source: http://mobile.httparchive.org/trends.php?s=Top1000

68. Lossy compression is the way to go!
Billy Hoffman / Zoompf
AP Photo/John Bazemore

69. Lossy-Compression is
Not for Everything
http://www.flickr.com/photos/tracy_olson/61056391/

70. Progressive image compression
http://images.sixrevisions.com/2010/12/01-02_baseline_vs_progressive.jpg

71. Client Server

72. Client Server
Get HTML

73. Client Server

74. Client Server
Get all objects

75. Client Server
20% 20% 20% 20% 20%

76. Client Server
80% 80% 80% 80% 80%

79. Summary

81.  SPDY actually delivers!

82.  SPDY actually delivers!
 but we are still in the early phases

83.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution

84.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution

85.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!

86.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.

87.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.
 What’s next?

88.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.
 What’s next?

89.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.
 What’s next?
 Opens the door to implement new class of optimizations

90.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.
 What’s next?
 Opens the door to implement new class of optimizations

91.  SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be broken. Changes are possible!
 HTTP is built into the internet architecture, it can’t be changed.
 What’s next?
 Opens the door to implement new class of optimizations
 Get engaged NOW!

92. Measurement - Proving us Right
 No 3rd party tools (yet)!
 Chrome developer tools
 not good for large scale data...
 w3c Web Performance tools - Navigation Timing
 Supported on IE9, and Chrome 11+
 http://w3c-test.org/webperf/specs/NavigationTiming/
 Site metrics:
 Google Analytics

93. Ido Safruti, ido@cotendo.com
Mike Belshe, mbelshe@google.com