STATE OF THE UNION. Ecommerce Page Speed & Web Performance Summer 2013 SHARE THIS WHITEPAPER

Transcription

1 STATE OF THE UNION Ecommerce Page Speed & Web Performance Summer 2013 SHARE THIS WHITEPAPER

2 Table of Contents Executive Summary... 3 Why Test Leading Ecommerce Sites?... 3 A New Focus: Time to Interact ()... 3 Key Findings... 4 Who Was Fastest?... 4 The 10 Fastest Sites (Time to Interact)... 4 The 10 Fastest Sites (Full Load Time)... 5 Finding #1: Web Pages Continue to Slow Down... 5 What This Means... 5 What Site Owners Can Do... 5 Finding #2: Median Time to Interact is 4.9 Seconds... 6 What This Means... 6 What Site Owners Can Do... 7 Finding #3: Median Page is 1095 KB and Contains 91 Resources... 8 What This Means... 8 What Site Owners Can Do... 8 Finding #4: Use of Performance Best Practices Has Plateaued or is Trending Down... 9 Use a CDN... 9 Enable keep-alives Compress images Compress text What This Means What Site Owners Can Do Finding #5: Firefox Outperformed Other Browsers What This Means What Site Owners Can Do Takeaways Leading ecommerce sites are not meeting the performance demands of online consumers Adoption of core performance best practices has plateaued or is on the decline Web pages need to work smarter and harder Test regularly and often from a real user s perspective Methodology About Radware Sources Smart Network. Smart Business. 2

3 Executive Summary No matter how interesting, beautiful, or cleverly interactive your web pages are, if they take more than two or three seconds to render, whether on a desktop or a mobile device, users quickly become impatient. They are measurably less likely to convert from browsing to buying and may even hit the back button or close the browser before the page ever loads. Even delays of less than 1 second significantly affect the user experience. In 2006, Marissa Mayer, who was then with Google, recounted that, after users indicated they wanted to see more than 10 search results per page, Google experimented with showing 30 results instead. To Google s surprise, traffic and revenue dropped by 20% in this experiment, apparently because the pages with more results took just an extra half-second to load. 1 When it comes to web site load times, user expectations are constantly escalating. In 1999, the optimal load time for an ecommerce site was 8 seconds. 2 In 2006, that wait time had been slashed in half, to 4 seconds. 3 By 2010, 57% of online shoppers stated that they would abandon a web page after waiting 3 seconds for it to load. 4 Why Test Leading Ecommerce Sites? In June and July 2013, we tested the load times in Internet Explorer 10, Chrome 27, and Firefox 21 of the home pages of the top 500 leading retail web sites, as ranked by Alexa.com. We then analyzed this data alongside previous benchmark tests. The goals of this research are threefold: 1. To obtain visibility into the performance and page composition of leading ecommerce sites. 2. To understand how these sites load for real people in real-world scenarios, via popular browsers and connection types. 3. To gain historical perspective into performance, seeing where sites have come from in terms of page size, composition, and adoption of performance best practices, and predicting their future direction. A New Focus: Time to Interact () As with our previous benchmark tests, we measured a core set of metrics, including load time (first view and repeat view), resource requests, page size, and implementation of core performance best practices. This set of tests marks the inauguration of a new metric for this report: time to interact (). Time to interact is defined as the point at which a page displays its primary interactive content (e.g., feature banners with functional call-to-action buttons), and it is considered by many within the performance community to be a more meaningful indicator of a page s ability to deliver a satisfactory user experience to a visitor. Our goal in exploring this metric is to provide additional insight into real-user performance. Except where specifically noted, the results discussed in this report are for pages tested in Chrome 27. As of June 2013, Chrome held a market share of 34%, making it the most widely used browser in the United States. 5 Smart Network. Smart Business. 3

4 Key Findings 1. Web pages continue to slow down. The median load time is 7.72 seconds, a slowdown of 13.7% since Spring The median page takes 4.9 seconds to load feature content. Ideally, pages should be interactive in fewer than 3 seconds. 3. The median page is 1095 KB and contains 91 resources (images, JavaScript, CSS files, etc.) This represents an 8% growth since Spring Adoption of performance best practices has either plateaued or is on the decline. Site owners who neglect core best practices miss out on the opportunity to make relatively easy performance gains. 5. Across all three major browsers, performance has either plateaued or is trending downward. Browser vendors are challenged to keep pace with the demands of today s large, complex, dynamic web pages. Who Was Fastest? There is a strong correlation between pages that had a faster time to interact () and those that had a faster overall load time; however, it is worthwhile to note that, for some sites (i.e. Netflix.com, iherb.com, and LivingSocial.com), had no relationship to load time. This is at least partially due to the fact that these pages have optimized their content so that primary resources load first, whereas secondary resources (e.g. social widgets and page analytics) load last. 8.58s The 10 Fastest Sites (Time to Interact) Among the top 100 sites, these were the fastest in terms of their ability to display meaningful, interactive content (e.g., feature banners with functional call-toaction buttons), otherwise known as time to interact (). We have provided the alongside the full load time in order to give perspective into the distinction between the two. 4.37s 5.05s 2.46s 2.22s 2.06s 2.95s 1.85s 2.68s 2.87s 0.7s Adpost.com 0.8s Groupon.com 0.8s Abebooks.com 1.4s Netflix.com 1.5s HM.com 1.7s Ikea.com 1.7s CDUniverse.com 1.8s iherb.com 2.0s 2.2s LivingSocial.com Nordstrom.com Smart Network. Smart Business. 4

5 STATE OF THE UNION The 10 Fastest Sites (Full Load Time) Among the top 100 sites, these were the 10 fastest in terms of the time required for all page elements to load. 1.85s 2.06s 2.20s 2.22s 2.46s 2.68s 2.68s 2.68s 2.87s 2.87s Ikea.com Abebooks.com Pixmania.com Groupon.com Adpost.com Walgreens.com CDUniverse.com Vitacost.com Nordstrom.com Forever21.com Finding #1: Web Pages Continue to Slow Down The median page took 7.72 seconds to fully load for a first-time visitor. This represents a slight (0.8% slowdown over the benchmark we recorded in our Spring 2013 State of the Union, and a 13.7% slowdown since Spring 2012 (6.79s). 13.7% slowdown What This Means Historically, load time has been a useful metric for understanding total page weight and the challenges of delivering large, complex, highly dynamic pages to global users. While it is important for site owners to understand the volume of the pages they are serving, load time is not an ideal metric for understanding the user experience. < 3s IDEAL 6.79s 7.36s 7.65s 7.72s SPRING 2012 FALL 2012 SPRING 2013 SUMMER 2013 What Site Owners Can Do The next section of this report addresses the challenges and benefits of identifying and measuring a performance metric that is more relevant to the end-user experience. It also outlines a number of strategies site owners can adopt in order to improve the user experience for online shoppers. 70,000 (MILLISECONDS) 60,000 50,000 Median Load Time 7.72s 40,000 30,000 20,000 10,000 Smart Network. Smart Business. 0 5

6 STATE OF THE UNION Finding #2: Median Time to Interact is 4.9 Seconds Time to interact () is the point at which a page displays its primary interactive content (e.g., feature banners with functional call-to-action buttons). Of the top 100 ecommerce sites we tested, the median was 4.9 seconds. Only 8% of the top 100 sites had a sub-2-second time, while 9% had a time of 8 or more seconds % 3s 10 hhad a of 8 or more seconds IIdeal Load Time 4.9s 8 Median Time This filmstrip view of the page load for Barnesandnoble.com shows that time to interact occurs at 2.7 seconds, when the feature image and call-to-action button have rendered enough to be usable. What This Means Time to interact () is a crucial indicator of a page s ability both to deliver a satisfactory user experience (by delivering content that the user is most likely to care about) and to fulfill the site owner s objectives (by allowing the user to engage with the page and perform whatever call to action the site owner has deemed the key action for that page). Ideally, pages should be interactive in 2 seconds or less. Separate studies have found that: 57% of consumers will abandon a page that takes longer than 3 seconds to load. A user who has to endure an 8-second download delay spends only 1% of their total viewing time looking at the featured space on a page. In contrast, a user who receives instantaneous page rendering spends 20% of their viewing time within the feature area of a page.7 A site that loads in 3 seconds experiences 22% fewer page views, a 50% higher bounce rate, and 22% fewer conversions than a site that loads in 1 second, while a site that loads in 5 seconds experiences 35% fewer page views, a 105% higher bounce rate, and 38% fewer conversions.8 6

7 Knowing this proven relationship between load time and business metrics, it is clear that a time to interact of 4.9 seconds fails to meet the needs of both consumers and site owners. Consumers are significantly more likely to abandon pages that take more than 3 seconds to load, and as a result, poorly performing sites can suffer conversion rate decreases of 22% or more. What Site Owners Can Do There are several tactics site owners can employ in order to improve the time to interact of their pages. 1. Defer rendering below the fold content. You can assure that the user sees the page quicker by delaying the loading and rendering of any content that is below the initially visible area, sometimes called below the fold. To eliminate the need to reflow content after the remainder of the page is loaded, replace images initially with placeholder <img> tags that specify the correct height and width. 2. Ensure that interactive features, such as carousels, are optimized to load early and quickly. As the filmstrip view below shows, the image carousel on the Staples.com home page doesn t render until 5.5 seconds. This carousel a JavaScript feature that generates personalized content doesn t begin to load until the 2-second mark, and then demands more than 3 seconds to actually appear in the browser. 3. Defer loading and executing non-essential scripts. Many script libraries aren t needed until after a page has finished rendering. Downloading and parsing these scripts can safely be deferred until after the onload event. For example, scripts that support interactive user behavior, such as drag and drop, can t possibly be called before the user has even seen the page. The same logic applies to script execution. Defer as much as possible until after onload instead of needlessly holding up the initial rendering of the important visible content on the page. The script to defer could be your own or, often more importantly, scripts from third parties. Poorly optimized scripts for advertisements, social media widgets, or analytics support can block a page from rendering, sometimes adding precious seconds to load times. 4. Use AJAX for progressive enhancement. AJAX (Asynchronous JavaScript and XML) is a technique for using the XHR (XMLHttpRequest) object to fetch data from a Web server without refreshing the page where the code is running. AJAX enables a page to display updated data in a section of a page without reconstructing the entire page. This is often used to respond to user interaction, but it can also enable your application to load a bare-bones version of a page quickly, and then fill in more detailed content while the user is already viewing the page. Smart Network. Smart Business. 7

8 Finding #3: Median Page is 1095 KB and Contains 91 Resources 91 resource requests 1095kb median page size Resource Requests Spring Fall 2012 Spring 2013 Summer 2013 At 1095 KB, the median page is more than 1 MB in size and contains 91 resources (images, JavaScript, CSS files, etc.). While this is slightly smaller than the median of 93 resources we benchmarked in Spring 2013, it represents 8.3% growth since Spring What This Means For most sites, the biggest drain on performance is the need to complete dozens of network round-trips to retrieve resources such as style sheets, scripts, and images. Only 20% of the time required to display a typical web page is consumed by loading the page s HTML. The remaining 80% is spent loading the additional resources needed to render the page and performing client-side processing. Each page resource makes an individual round trip from the user s browser, which requests the file from the host server, which in turn delivers the file to the browser. Each round trip can take milliseconds (or more) for desktop browsers numbers that add up quickly when a typical page contains almost 100 resources. What Site Owners Can Do There are a number of strategies for reducing the number of resource requests and minimizing the total payload for a web page: 1. Use a content delivery network While content delivery networks (CDNs) can help by bringing content geographically closer to users, using a CDN is only the first step in performance optimization. The total number of requests has a much greater impact on page-load times than the distances those requests travel, so site owners still need to address reducing requests and payload. 2. Consolidate page resources By now, it is standard practice for developers to consolidate JavaScript code and CSS styles into common files that can be shared across multiple pages. This technique simplifies code maintenance and improves the efficiency of client-side caching. In JavaScript files, be sure that the same script isn t downloaded multiple times for one page. Redundant script downloads are especially likely when large teams or multiple teams collaborate on page development. Smart Network. Smart Business. 8

9 Spriting is a CSS technique for consolidating images. Sprites are simply multiple images combined into a rectilinear grid in one large image. The page fetches the large image all at once as a single CSS background image and then uses CSS background positioning to display the individual component images as needed on the page. This reduces multiple requests to only one, significantly improving performance. 3. Compress text and images Compression technologies such as gzip reduce payloads at the slight cost of adding processing steps to compress on the server and decompress in the browser. These operations are highly optimized, however, and tests show that the overall effect is a net improvement in performance. Text-based responses, including HTML, XML, JSON (JavaScript Object Notation), JavaScript, and CSS, can all be reduced in size by as much as 70 percent. 4. Minify code Minification, which is usually applied only to scripts and style sheets, eliminates inessential characters such as spaces, newline characters, and comments. A correctly minified resource is used on the client without any special processing, and file-size reductions average about 20 percent. Script and style blocks within HTML pages can also be minified. There are many good libraries available to perform minification, often along with services to combine multiple files into one, which additionally reduces requests. 5. Resize/reformat images Images often consume the majority of the network resources required to load Web pages, and the majority of the space required to cache page resources. Images with unnecessarily high resolution waste bandwidth, processing time, and cache space. Additionally, inappropriate image formatting is an extremely common performance culprit. An image that is saved to the wrong format can be several times larger than it would be if saved to the optimal format. As a general rule of thumb, these are the optimal formats for common image types: Photos JPEG, PNG-24 Low complexity (few colors) GIF, PNG-8 Low complexity with transparency GIF, PNG-8 High complexity with transparency PNG-24 Line art SVG Another option is to load a very low-resolution version of an image initially to get the page up as quickly as possible and then replace that with a higher-resolution version on the onload or ready event after the user has begun interacting with the page. Finding #4: Use of Performance Best Practices Has Plateaued or is Trending Down While the adoption of some fundamental performance best practices (use a CDN, enable keep-alives) remains widespread, the adoption rate has plateaued. For other best practices (compress text, compress images), adoption is still lagging. Use a CDN 58% of sites currently use a content delivery network (CDN) to cache resources closer to end users, thereby shortening server round trip time. This number has not increased dramatically since our Spring 2013 benchmark of 57%. Smart Network. Smart Business. 9

10 Enable keep-alives This technique allows site owners to control how many times the TCP connection takes place. (TCP connection is the process by which both the user and the server send and receive acknowledgment that a connection has been made and that data can begin to be transferred. Too many TCP connections will slow down a site.) Currently, 90% of the Alexa Retail 500 have keep-alives enabled on their sites, up slightly from 86% in Spring Compress images Images comprise the bulk of a typical page s total size. As discussed in the previous section of this report, image compression is a core performance best practice that allows site owners to reduce this payload. Our tests show that only 8% of the Alexa Retail 500 are currently compressing images. Compress text Text-based responses (including HTML, XML, JSON, JavaScript, and CSS) can all be reduced in size by as much as 70 percent, yet we found that just over half (53%) of site owners implemented text compression. USE A CDN ENABLE KEEP-ALIVES 50.6% 50.8% 57.6% 58.4% 86% 86.8% 86.4% 90% SPRING 2012 FALL 2012 SPRING 2013 SUMMER 2013 SPRING 2012 FALL 2012 SPRING 2013 SUMMER 2013 COMPRESS IMAGES 8% of sites use image compression COMPRESS TEXT 53% of sites use text compressionsion What This Means Site owners who neglect core best practices miss out on the opportunity to make relatively easy performance gains. Using a CDN can reduce load time by up to 30%. Implementing keep-alives and compression can have a similarly dramatic impact on page speed: Up to 52% improvement in start render time Up to 40% improvement in document complete Up to 31% improvement in time to fully load While best practices such as using a CDN and enabling keep-alives approach the saturation point among leading sites, it is concerning that fundamental techniques such as image and text compression are not more widely adopted. These findings are consistent with separate findings, recently announced by Google performance engineer Steve Souders, who has stated that the adoption of performance best practices has been flat or trending down. Souders also points out that we are seeing declining numbers in the adoption of core techniques such as optimizing header caching and avoiding redirects. 9 Smart Network. Smart Business. 10

11 This declining interest in applying core performance best practices could be caused by a number of factors: lack of performance education, lack of resources dedicated to ongoing performance optimization, lack of investment in front-end optimization tools that automate the implementation of these practices and/or lack of developer control over resources (e.g. due to content management systems). It should be noted that the two techniques that are thriving use a CDN and enable keep-alives both fall outside the web developers domain. For most site owners, content delivery is outsourced to third parties. Enabling keep-alives is a server/load balancer configuration issue. What Site Owners Can Do There is no single magic bullet for delivering faster pages to your visitors. Site owners who succeed in meeting their performance goals do so using a multi-tiered approach that includes: In-house performance engineers. At a high level, performance engineers champion performance throughout the organization and are instrumental in creating a company s performance culture. On a day-to-day basis, engineers pinpoint, diagnose, and resolve performance degradation. Content delivery network (CDN). CDNs address the performance middle mile by bringing resources closer to users shortening server round trips and, as a result, making pages load faster. Automated front-end optimization (FEO). Due to a combination of constantly changing factors including browser evolution, increasingly complex web pages, and emerging performance best practices performing manual front-end optimization is a never-ending task. FEO solutions automatically apply a host of performance techniques across a web site, as well as monitoring for page breakage and other site health metrics. Note: Our tests simulated load time for a user viewing a single site within the browser. Our tests did not cover other common scenarios that can affect performance, such as the following: 1. Browser performance under stress from having multiple tabs or windows open simultaneously. 2. Browser performance degradation over time (e.g., the longer the browser remains open, its likelihood of crashing). 3. Browser performance when visiting sites that use HTML5 or Flash, or when watching videos. 4. Usability. This comes down to personal preference. For example, while some users may prefer a more minimal look and feel, others might value the functionality of add-on features. Firefox irefox 77.18s s 42 SPRING 2013 SUMMER 2013 Internet Explorer 10 Finding #5: Firefox Outperformed Other Browsers While this survey focuses on Chrome, as the current dominant browser in the US, we also tested the load times of the Alexa Retail 500 on other popular browsers Firefox and Internet Explorer to gain a sideby-side perspective on browser performance s s 67 SPRING 2013 SUMMER 2013 Chrome Firefox experienced the fastest median load time (7.42s), edging out Internet Explorer 10 and Chrome by 3.2% and 4%, respectively. What This Means In recent years, speed has emerged as an extremely competitive issue among browser vendors. While our tests simulated how fast each site 77.65s 65 Smart Network. Smart Business. SPRING s 72 SUMMER 2013

12 loads for a user who is viewing only one site at a time within the browser, this is only one lens through which to examine browser performance. Our findings should not be taken as a definitive statement as to which browser is the fastest. What is much more telling is the fact that, across all three major browsers, performance has either plateaued or is trending downward as browser developers struggle to keep pace with the demands of today s large, complex, dynamic web pages. What Site Owners Can Do Given the constant growth in page size and complexity, it is important to note that it is surprising that pages are not even slower than they currently are. This is in large part attributable to browser developers, who continue to focus on performance as a key feature. Site owners should recognize that, while modern browsers are more or less equal, they are not the same. Each browser has its own unique preferences in terms of how it renders pages: e.g., a page that is optimized for Chrome may not perform nearly as well in Firefox. Site owners should educate themselves about these preferences and develop their pages accordingly. The W3C offers guidelines for optimizing content for different browsers. 10 Takeaways 1. Leading ecommerce sites are not meeting the performance demands of online consumers. The majority of shoppers state that they will leave a page if it takes more than 3 seconds to load, yet the median time to interact (definition: the point at which a page s featured content is rendered and interactive) is 4.9 seconds. 2. Adoption of core performance best practices has plateaued or is on the decline. These findings are consistent with separate findings, recently announced by Google performance engineer Steve Souders, who has stated: The adoption of performance best practices has been flat or trending down. 11 This declining interest in applying core performance best practices could be caused by a number of factors, ranging from lack of performance education to lack of developer control over page resources (e.g., due to limitations imposed by content management systems). To address this, site owners must first create a performance culture within their organization, which recognizes speed as a critical feature. 3. Web pages need to work smarter and harder. Core performance best practices such as compression, consolidation, minification, and enabling keep-alives are essential, but they are just the first steps in the optimization process. Site owners need to leverage advanced techniques that optimize the browser s efficiency in terms of rendering the most critical content first. These advanced techniques include progressive enhancement, deferring the rendering of below the fold content, deferring the loading and execution of non-essential scripts (i.e. third-party tags), and optimizing feature content so that it loads first. 4. Test regularly and often from a real user s perspective. No discussion of performance optimization would be complete without a reminder that continuous and careful testing is essential. Guessing where performance bottlenecks occur is meaningless unless based on real test data. There are excellent open-source and commercial tools that provide synthetic tests, complete with geographical distribution and bandwidth/latency throttling. In addition, RUM (real user monitoring) tools take testing out of the lab and into the field of unpredictable user behavior. Smart Network. Smart Business. 12

13 Methodology The tests in this study were conducted using a free online tool called WebPagetest an open-source project primarily developed and supported by Google which simulates page load times from a real user s perspective using real browsers. We tested the home page of every site in the Alexa Retail 500 nine times in a row. (The system clears the cache between page loads.) The median test result for each home page was recorded and used in our calculations. The tests were conducted over a two-week period June 24 to July 5, 2013 via the WebPagetest.org server in Dulles, VA, using the following browsers on a DSL connection: Internet Explorer 10 Firefox 21 Chrome 27 In very few cases, WebPagetest rendered a blank page or an error in which none of the page rendered. These instances were represented as null in the test appendix. Also, in very few cases, WebPagetest.org rendered a page in more then 60 seconds (the default timeout for webpagetest.org). In these cases, 60 seconds was used for the result instead of null. To identify the time to interact () for each page, we generated a timed filmstrip view of the page load for the median page for each site in the Alexa Retail 100. Time to interact was defined as the moment that the featured page content and primary call-to-action button or menu was rendered in the frame. About Radware Radware (NASDAQ: RDWR), is a global leader of application delivery and application security solutions for virtual and cloud data centers. Its award-winning solutions portfolio delivers full resilience for business-critical applications, maximum IT efficiency, and complete business agility. Radware s solutions empower more than 10,000 enterprise and carrier customers worldwide to adapt to market challenges quickly, maintain business continuity, and achieve maximum productivity while keeping costs down. For more information, please visit Sources 1 Marissa Mayer, Web 2.0, Zona Research, The Economic Impacts of Unacceptable Website Download Speeds, Jupiter Research, Retail Web Site Performance: Consumer Reaction to a Poor Online Shopping Experience, June PhoCusWright, Consumer Response to Travel Site Performance, June StatCounter Global Browser Stats, June 2012 to June PhoCusWright, Consumer Response 7 Jakob Nielsen, Website Response Times, June Strangeloop Networks, The 90-Minute Optimization Life Cycle, June Steve Souders, How fast are we going now?, May W3C, Optimizing Content for Different Browsers: The Right Way, May Souders, How fast are we going now? 2013 Radware, Ltd. All Rights Reserved. Radware and all other Radware product and service names are registered trademarks of Radware in the U.S. and other countries. All other trademarks and names are the property of their respective owners. Smart Network. Smart Business. 13