• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
London Web Performance Meetup: Performance for mortal companies
 

London Web Performance Meetup: Performance for mortal companies

on

  • 2,789 views

You're probably familiar with the well-known performance success stories from companies like Amazon, Google, Microsoft and Shopzilla. But how relevant are these megasites to "mortal companies" that ...

You're probably familiar with the well-known performance success stories from companies like Amazon, Google, Microsoft and Shopzilla. But how relevant are these megasites to "mortal companies" that don't make billions of dollars per year or have teams of in-house performance engineers to do their bidding?

Strangeloop president Joshua Bixby walks through case studies of Strangeloop customers like AutoAnything.com and Artbeads.com to show how mortal companies have improved performance and achieved measurable success, including:

· Increased revenue by 13%
· Increased cart size by 6%
· Increased conversions by 9%

Joshua offers practical tips for successfully evangelizing performance within your organization. He also gives a snapshot of the current performance landscape in North America, as well as a sense of where the industry is headed.

Statistics

Views

Total Views
2,789
Views on SlideShare
1,887
Embed Views
902

Actions

Likes
4
Downloads
41
Comments
0

8 Embeds 902

http://www.seriticonsulting.com 627
http://www.strangeloopnetworks.com 184
http://www.linkedin.com 66
http://stage.strangeloopnetworks.com 18
https://twitter.com 4
http://www.strangeloopnetworks.net 1
http://www.strangeloopnetwork.com 1
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • If you’re here, you’re a performance convert. But one of your biggest problems may be trying to explain the urgency of performance to non-techies in your company… and getting higher-ups to commit to long-term investing in performance. Sure, there are lots of high-profile stories of how speeding up pages has been successful for mega-sites…
  • I talk to a lot of execs, and I hear this a lot. I get why. It’s difficult for mortal companies to see themselves in relation to ecommerce mega-giants thatmake billions of dollars a year and have teams of in-house performance engineers to do their bidding.
  • Again, performed 50/50 test to see the impact of faster pages on performance:Conversions increased by 9%Cartsize by 11%Sales by 13%
  • Again, 50/50 test of the site after implementing the Site Optimizer service. Wetracked three metrics among both test groups: revenue per visitor, revenue per visit, and overall revenue. The goal was a baseline increase of 2.5% across all three metrics. The accelerated site dramatically outperformed this goal:Revenue per visit +8%Overall revenue +6%
  • I talk to a lot of execs, and I hear this a lot. I get why. It’s difficult for mortal companies to see themselves in relation to ecommerce mega-giants thatmake billions of dollars a year and have teams of in-house performance engineers to do their bidding.
  • The obvious answer is to just implement Site Optimizer, speed things up, then check out conversion rate changes using a segmentation test, but this isn’t an option for everyone. So we developed a hack. It lets you use two tools you’re probably already familiar with – Google Analytics and WebPagetest – to slice your own data a bunch of different ways, and create decent proxies for performance.
  • Last fall, we performed a study which showed that IE8 is about 25% faster than IE7 across almost 200 websites. Based on this, we felt that browser version is a solid performance proxy for exploring conversion behaviour. Reference original case study: “The first thing we did was perform a Webpagetest in IE7 and IE8. We found that his site was 30% faster in IE8.”
  • Explore different connection speeds within IE8. First, perform Webpagetests on the different connection speeds, and then compare them to the results in Google Analytics.If you’re using Google Analytics, I think the easiest way to get this data is with a custom report that looks something like this. (reference Google Analytics screen grab)From case study: “Again we found a remarkable relationship between connection speed and order value. On average, online shoppers using T1 connections spent about 11% more than shoppers with DSL connections. And shoppers with T1 connections spent roughly 32% more than those using dialup.”
  • To pass any hardcore statistical muster, a much more in-depth regression test would need to occur. But these early proof points are enough to convince many non-believers that performance matters and they should invest in it.
  • In a real-world application of this approach, with all variables accounted for, the optimized site still outperformed the unoptimized site.
  • From case study:Before I released this hack into the wild, I needed to apply this methodology to one last test to determine if it had any validity in the real world. I took a Strangeloop customer who had been through a rigorous month-long 50/50 test. In this particular case, with all other variables accounted for, the optimized site outperformed the unoptimized site. On average, order value for the optimized site was 20% greater than for the unoptimized site
  • This is what you need to start with.You may have your own variation on this. What’s the best way of showing this?
  • With a table?This is a table showing the load time and start render time for the top 20 ecommerce sites of the 2009 holiday shopping season. There’s some interesting data here, but if you were a performance newbie, you wouldn’t know it.Tables show that you’ve done your homework and tabulated your data. Okayin the appendix of a performance report, but they’re not goingto light fires under any butts.
  • Better…Side by side comparison graphic. (It’s easy to create using Webpagetest’s visual comparison feature. First, run your side-by-side test, then click the “Export filmstrip as an image” text link on the bottom of the results page.)You can see how your site loads, frame by frame, compared to your competitors.Interesting, but requires a bit of scrutiny to understand.Good to include in a competitive analysis section of your performance audit, but not a showstopper.
  • This is when you share the findings of your 5-minute speed/benefit analysis. It can be as simple as Google Analytics screenshots like this.
  • After you’ve grabbed attention, then start providing big-picture context.Use concrete benchmarks to create goals… and introduce competitiveness.You can get this data from companies like Gomez, which updates benchmarks every week.This index may focus on larger companies, but these numbers are relevant to all companies. Here’s why…
  • Users don’t care if your company is large or small. They expect all sites to load quickly.
  • Organizations that recognize the need to take their website’s performance to the next level need to change their basic assumption about acceleration. This change is not a 180-degree turn, however – it’s an evolutionary change. Delivery-based solutions such as CDNs and network devices still form a solid foundation for a total acceleration solution. Transformation-based solutions complement this foundation.
  • Here we see three waterfall graphs showing how web page objects are delivered from the server to the browser.OriginalThis is an unaccelerated site, with 63 objects making 63 roundtrips between server and browser. The total page load time is 9.5 seconds.DeliveryThis graph shows how a delivery solution – comprised of a content delivery network (CDN) and an application delivery controller (ADC) – shortened these roundtrips by bringing content closer to the user’s browser. There were still 63 roundtrips, but the total page load time was 5.7 seconds.TransformationThis graph shows how Strangeloop worked in conjunction with the CDN and ADC to not just shorten the roundtrips, but reduce the number of roundtrips required – from 63 to just 9. The result: The same page loads in just 2.1 seconds. It is important to remember that 2 seconds is the goal that every site should be aiming for, based on current user expectations. It’s also worth remembering that only one company out of the Fortune 500 actually meets this standard.
  • Twitter @joshuabixby

London Web Performance Meetup: Performance for mortal companies London Web Performance Meetup: Performance for mortal companies Presentation Transcript

  • Web Performance Optimization (WPO)Web Content Optimization (WCO)Web Code Optimization (WCO)Web Transformation (WT)Front end performance Optimization (FEO)…Stories from an emerging market…
  • 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
  • Waterfall component breakdown
    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
  • Waterfall component breakdown
    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
  • Waterfall component breakdown
    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
  • Performance Problems
    Too many connections (too much orange)
    Too many bytes (too much blue)
  • Too Many Bytes
    By Type
    By Domain
  • Performance Problems
    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
  • Performance Problems
    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 View
    Connections
    Bytes
  • 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)
  • The Green Problem #1: No CDN
    TTFB
  • 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)
  • 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
  • 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
  • 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
  • Delivery market
  • Players delivery market
  • Transformation market
  • Transformation market
  • Transformation market