Velocity 2010: The 90 Minute Optimization Life Cycle - Faster by default before our eyes?

8,371 views
7,544 views

Published on

Rated one of the top 10 sessions at Velocity 2010 by attendees.

By now, we’ve all internalized Steve Souders’ rules for optimizing web performance, but the question is: do you need to spend 6 months and raise an army of top developers to make your sites fast by default?

In this workshop, Joshua Bixby and Hooman Beheshti of Strangeloop subject an unsuspecting website – the Velocity home page – to real-time optimization, following Google and Yahoo’s rules for high-performance websites.

Over the course of the workshop, witness the entire optimization life cycle:

* Using various measurement tools to benchmark current performance, focusing on load time, start render time and round trips.
* Implementing A/B segmentation to measure key business metrics like conversion, bounce rate and page views/visit.
* Iterating through acceleration best practices.
* Analyzing results from different geographical locations using different browsers.

Published in: Technology, Design
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,371
On SlideShare
0
From Embeds
0
Number of Embeds
1,298
Actions
Shares
0
Downloads
195
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • 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.
  • Velocity 2010: The 90 Minute Optimization Life Cycle - Faster by default before our eyes?

    1. Author of presentation 90 Minute Optimization Life Cycle “Fast 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
    4. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 4 Methodology
    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 )
    6. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 6
    7. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 7
    8. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 8
    9. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 9
    10. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 10
    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
    12. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 12
    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
    14. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 14
    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
    17. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 17
    18. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 18
    19. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 19
    20. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 20
    21. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 21
    22. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 22
    23. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 23
    24. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 24
    25. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 25
    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
    28. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 28
    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 - 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
    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
    44. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 44
    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
    71. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 71 Summary
    72. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 72 Let’s Fix It!!
    73. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 73 Set-Up
    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
    123. © 2010 Strangeloop Networks Strangeloop. Faster Websites. Automatically. 123 Q&A

    ×