Performance has always been crucial to the success of websites. A growing body of research has proven that even small improvements in page-load times lead to more sales, more ad revenue, more stickiness, and more customer satisfaction for enterprises ranging from small e-commerce shops to megachains such as Walmart.
For years Web developers could count on steady improvements in hardware and bandwidth to help deliver an optimal user experience. In recent years, however, the explosion of mobile Web browsing has reversed this. The lower bandwidth, higher latency, smaller memories, and lower processing power of mobile devices have imposed an even more urgent need to optimize performance at the front end in order to meet user expectations.
This article summarizes the case for front-end optimization and provides an overview of strategies and tactics to speed up your pages, with an emphasis on addressing mobile performance issues.
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 one second significantly affect revenues. In 2006 Marissa Mayer, with Google at the time, recounted that, after users indicated they wanted to see more than 10 search results per page, Google experimented with showing 30 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.5
User expectations have only escalated since then. A 2009 study by Forrester Research on behalf of Akamai identified two seconds as the threshold for acceptable Web-page response times and found that 40% of consumers abandon a page that takes longer than three seconds to load. Just one year later, another study done for Akamai found that the number of users who abandon a page after three seconds had risen to 57%.1,7
Furthermore, users on mobile devices expect performance to be at least as good asif not better thanwhat they experience on their desktop. The Harris Interactive 2011 Mobile Transactions Survey, commissioned by Tealeaf Technology (now IBM), reported that 85% of adults who had conducted a mobile transaction in the previous year expected the mobile experience to be equal to or better than shopping online using a laptop or desktop computer, and 63% said they would be less likely to buy from the same company via other channels if they experienced a problem conducting a transaction on their mobile phones.10 In other words, poor mobile performance hurts companies on all other platforms, including bricks-and-mortar.
Mobile traffic is expanding rapidly. For many consumers, their phone or tablet has become their primary portal to the Internet, but performance is falling short of expectations. A study published by Equation Research on behalf of Compuware in February 2011 found that almost half (46%) of mobile users said websites load more slowly than expected on their phones. Nearly 60% expect pages to load in three seconds or less, and 74% report they would leave a site if a single page took five seconds or more to load. A 2012 study of 200 leading e-commerce sites by Strangeloop Networks (now Radware) found that the median load time was 11.8 seconds over 3G (see Figure 1); performance over LTE fared only slightly better, at 8.5 seconds.8
Three Limiting Factors for Mobile Performance. As already mentioned, mobile devices have inherent performance limitations: lower bandwidth, smaller memories, and lower processing power. These challenges are compounded by external issues, notably:
Web pages are bigger than ever. According to the HTTP Archive, the average Web page carries a payload of more than 1MB and contains at least 80 resources such as images, Java Script, CSS (Cascading Style Sheets) files, etc. This has a significant impact on desktop performance. Its impact on mobile performanceand particularly on 3G performanceis much more dramatic. This impact will be felt even more keenly over the next three years. At the current rate of growth, pages could surpass 2MB by 2015.
Latency can vary widely. It can range from as little as 34ms for LTE to 350 ms or more for 3G. Mobile latency is consistent only in its inconsistency, even when measured at the same location. This is due to a number of variables beyond the amount of data passing through the tower. Factors such as the weather, and even the direction the user is facing, can have a significant impact.
Download speeds can also experience huge variance. The speeds can range from a mere 1Mbps over 3G to as much as 31Mbps over LTE. It is interesting to compare this to the average U.S. broadband speed of 15Mbps, and to note that 3G can be up to 15 times slower than broadband, while LTE can be up to twice as fast.
M.Sites are not a Cure-All for Mobile Performance Pains. Many site owners attempt to respond to the combination of high user demands, large Web pages, and poor connection speeds by developing smaller, faster, stripped-down m.sites; however, these attempts are not completely effective, as up to 35% of mobile users will choose to view the full site when given the option.
These full-site visitors are significantly more likely to spend than m.site visitors. One study found that for every $7.00 of mobile-generated revenue, $5.50 was generated via full site. Only $1.00 came via m.site, and $0.50 via app.9
Addressing the Problem. The chief strategies for improving site performance have not changed as usage has migrated from the desktop to mobile phones and tablets, although a few new tactics have emerged.
Only 20% of the time required to display a typical Web page, whether in a desktop or mobile browser, is consumed by loading the page's HTML. The remaining 80% is spent loading the additional resources needed to render the pageincluding style sheets, script files, and imagesand performing client-side processing.
The three main strategies for improving performance are:
The biggest drain on performance is usually the need to complete dozens of network round-trips to retrieve resources such as style sheets, scripts, and images. This is especially true with the relatively low bandwidth and high latency of mobile connections. CDNs (content delivery networks) can help a bit by bringing content geographically closer to users, but the number of requests has a much greater impact on page-load times than the distances those requests travel. In addition, recent findings suggest CDNs have limited effectiveness for mobile users.3
Here, I discuss several approaches to minimizing HTTP requests.
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.
Ease of implementation: Moderate, but requires having access to resources. Depending on the level of control the developer has over the website, some resources may not be able to be consolidated (for example, if they are generated by a CMS). Also, some resources may be located on external domains, which can cause problems for consolidation. It is also important to note that resource consolidation can be a double-edged sword for mobile browsers. Reducing requests improves performance the first time, but larger consolidated resources may not be cached efficiently, so be careful to combine consolidation techniques with other techniques to optimize
Use Browser Caching and
Mobile browser caches, however, are usually much smaller than those on desktop machines, causing items to be flushed quickly. The HTML5 Web storage specification provides a great alternative to relying only on browser caching. The HTML5
localStorage and then use it, if available, to save and read key/value data, usually 5MB per domain. This capability makes
localStorage very well suited for client-side caching, although read/write speeds do vary for different mobile browsers. It is usually significantly faster to retrieve a resource from
localStorage than to request it from a server, and it is more flexible and reliable than relying only on cache headers and the limited browser cache storage available on most mobile devices. In addition, this is one area where mobile browsers are currently ahead of the desktop in efficiency
localStorage performance has lagged in desktop implementations where using the standard browser cache may still be the best option.
Ease of implementation: Advanced. While the
localStorage mechanism may be simple to use, building a cache around it does create some complexities. You will need to take into account all of the issues that a cache handles for you, such as cache expiry (when do you remove items?), cache misses (what if you expected something to be in
localStorage and it is not?), and what to do when the cache is full.
Embed Resources in HTML for First-time Use. The standard pattern in HTML is to include links to external resources. This makes it easier to maintain these resources as files on the server (or in a CDN) and to update them at the source rather than in each of many pages. This pattern also supports browser caching by allowing cached resources to be fetched automatically from the cache rather than from the server, as previously discussed.
For resources that are not already cached in the browser or in
localStorage, however, this pattern of linking to external resources has a negative impact on performance. A typical page can require dozens of separate requests in order to gather the resources needed to render the page. So, from a performance standpoint, if a resource does not have a high likelihood of already being cached, it is often best to embed that resource in the page's HTML (called inlining) rather than storing it externally and linking to it. Script and style tags are supported in HTML for inlining those resources, but images and other binary resources can also be inlined by using data URIs that contain base64-encoded text versions of the resources.
The disadvantage of inlining is that page size can become very large, so it is crucial for a Web application that uses this strategy to be able to track when the resource is needed and when it is already cached on the client. In addition, the application must generate code to store the resource on the client after sending it inline the first time. For this reason, using HTML5
localStorage on mobile devices is a great companion to inlining.
Ease of implementation: Moderate. This technique requires the site to have a mechanism to generate a different version of the page based on whether or not the user has visited that page before.
Eliminate Redirects. When users attempt to navigate to a standard desktop site from a mobile device, the Web application often will read the user-agent HTTP header to detect the request is from a mobile device. The application then can send an HTTP 301 (or 302) response with an empty body and a Location header, redirecting the user to the mobile version of the site as required. However, the extra round-trip to the client and back to the mobile site often consumes several hundred milliseconds over mobile networks. Instead, it is faster to deliver the mobile Web page directly in response to the original request, rather than delivering a redirect message that then requests the mobile page.
As a courtesy to users who prefer to view the desktop site even on their mobile devices, you can provide a link on the mobile site that signals your application to suppress this behavior.
Ease of implementation. While this technique is easy in theory, it may not always be possible to put into practice. Many sites redirect to a different server for their m.sites, since those may be hosted elsewhere. Other sites send cookies with the redirect to tell the Web application that they are mobile once they redirect. This may be more difficult to control, depending on the Web application.
Size matters. Smaller pages render faster, and smaller resources are fetched faster. Reducing the size of each server response does not usually help performance as much as reducing the number of responses needed for each page. Several techniques, however, do yield a net benefit for performance, especially on mobile devices where bandwidth and processing power must be managed wisely.
Browsers announce their decompression capabilities in the Accept-Encoding request header, and they perform decompression automatically when servers signal that a response is compressed in the Content-Encoding response header.
Ease of implementation: Easy. All modern Web servers will support compressing responses if correctly set up. However, there are still desktop security tools that will remove the Accept-Encoding headers from requests, which will prevent users from getting compressed responses even though their browsers support it.
Minify code. Minification, which is usually applied only to scripts and style sheets, eliminates inessential characters such as spaces, newline characters, and comments. Names that are not publicly exposed, such as variable names, can be shortened to just one or two characters. A correctly minified resource is used on the client without any special processing, and file-size reductions average about 20% 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.
Minification not only reduces bandwidth consumption and latency, but also may mean the difference between a cacheable object and one that is too big for the cache on a particular mobile device. Gzip compression is no help in this regard, because objects are cached by the browser after they have been decompressed.
Resize 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. Small-screen mobile devices present opportunities for speeding transmission and rendering by resizing images. High-resolution images waste bandwidth, processing time, and cache space if the user will be viewing the images only in a small mobile browser window.
To speed up page rendering and reduce bandwidth and memory consumption, dynamically resize images in your application or replace images with smaller versions for mobile sites. Don not waste bandwidth by relying on the browser to scale a high-resolution image into a smaller width and height.
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.
Ease of implementation: Advanced, especially for highly dynamic sites.
Simplify Pages with HTML5 and CSS 3.0. The HTML5 specification includes new structural elements, such as
In addition, new CSS 3.0 features can help create lightweight pages by providing built-in support for gradients, rounded borders, shadows, animations, transitions, and other graphical effects that previously required images to be loaded. These new features can speed up page rendering.
Ease of implementation: Advanced. Making these changes manually is extremely complex and time consuming, if not impossible. If you use a CMS, it may generate a great deal of HTML and CSS that you have no control over.
Defer Rendering Below-the-Fold Content. You can ensure 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.
onload event. For example, scripts that support interactive user behavior, such as drag and drop, cannot 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, script 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. Also, carefully evaluate the use of large script frameworks such as jQuery for mobile sites, especially if you are using only a couple of objects in the framework.
onload (for example, what do you do if you have a script that wants to attach to the
onload event? If you defer it after
onload, it has missed its chance).
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 to fill in more detailed content while the user is already viewing the page.
Despite the name,
XMLHttpRequest does not tie you to using only XML. You can call its
overrideMimeType method to specify "application/json" and work with JSON instead of XML. Using
JSON.parse is up to twice as fast and more secure than using the generic
Also, remember that AJAX responses will benefit from many of the same optimization techniques recommended for standard responses. Be sure to apply cache headers, minification, gzip compression, resource consolidation, among others, to your AJAX responses.
Ease of implementation: Difficult to quantify, as this technique is very application specific. Because of cross-domain issues, you would need to use XHR2, as well as control the external domain to make cross-domain XHR requests.
Adapt to the Network Connection. Especially with mobile networks that may charge extra for using more bandwidth, certain techniques should be used only when combined with code to detect the type of connection. For example, preloading resources in anticipation of future requests is usually smart, but it may not be a responsible strategy if the user's bandwidth is metered and some of those resources may never be needed.
On Android 2.2+, the navigator.connection.type property returns values that allow you to differentiate Wi-Fi from 2G/3G/4G connections. On Blackberry, blackberry.network provides similar information. In addition, server-side detection of User-Agent header data or other information embedded in requests can alert your application to the quality of the connection in use.
Ease of implementation: Advanced. The Network Information API has changed recently.11 Rather than defining the network as Wi-Fi, 3G, and so on, it now gives information about the bandwidth, with examples such as "very-slow, slow, fast and very-fast." There is a property that tries to tell the estimated MB/s, and a Boolean "metered" measurement that does its best to be correct, but this is very difficult for a browser to determine. Measuring somewhere and adapting is probably still the best idea but is quite challenging.
AJAX enables a page to display updated data in a section of a page without reconstructing the entire page.
For improving the performance of mobile sites, Web Worker code can be valuable for preloading resources that a user is likely to need to complete future actions, especially when the user's bandwidth is not metered. With the limited processor capabilities of mobile devices, extensive preloading can interfere with UI responsiveness in the current page. Using multithreaded code that employs Web Worker objects (and possibly
localStorage to cache the data), operations that preload resources can execute on a separate thread without impacting current UI performance.
Note that the Web Worker spec, while implemented in Android since 2.0, was not supported on the iPhone until iOS 5. On the desktop, Internet Explorer was the laggard, adding support for Web Worker only in IE 10.
Ease of implementation: Moderate. While this technique is not incredibly difficult to implement, there are some restrictions to Web Workers that make them difficult to find places for. They do not have access to the page's DOM and cannot modify anything on the page. Making this practice work requires a very specific type of background calculation or process that fits well as a background Web Worker.
Replace Click Events with Touch Events. On touchscreen devices, the
onclick event does not fire immediately when a user taps the screen. Instead, the device waits up to half a second (300 milliseconds on most devices), giving the user a chance to initiate some other gesture rather than a click. This delay, however, can significantly impede the responsive performance that users expect. To fix this, use the
touchend event instead. That event fires immediately when the user taps the screen.
To ensure the user does not experience unexpected behavior, you may also want to use the
touchmove events. For example, do not assume that touchend on a button means click unless there was also a
touchstart event on the buttonnot if the user touched somewhere else and dragged to the button before ending the touch. You could use a
touchmove event after
touchstart to prevent treating the following
touchend as a click, assuming the moving gesture was not intended to be a click.
In addition, you may still want to handle the
onclick event to ensure the browser changes the appearance of the button to show a clicked state, and to support browsers that do not handle touch events. To avoid duplicate code execution when both
onclick code fire, add a click event handler that calls
stopPropagation if the click was the result of a user tap that was already handled by
Ease of implementation: Advanced. This technique requires much more work to add and maintain links on a page. The code testing for touch events must be resilient against gestures that may be happening instead of a click, such as a zoom or swipe.
Support the SPDY Protocol. Some of the performance bottlenecks that afflict websites, whether desktop or mobile, result from inefficiencies in the application-layer HTTP and HTTPS protocols. In 2009, Google began work on an alternative protocol named SPDY (pronounced "speedy") that addresses some of these limitations. The goal is to make this an open source project that will be implemented by multiple browsers and Web servers, but initially it was supported only in Google's Chrome browser (in version 10 or later) and on Google sites. As Web servers are released that implement SPDY, sites will be able to use this protocol for any user with a browser that supports it. In a test implementing SPDY on a representative group of 25 of the top 100 Internet sites, Google observed speed improvements from 27% to 60%.2
SPDY automatically uses gzip compression on all content, and unlike HTTP, it also uses gzip on header data. SPDY employs multiplexing technology to enable multiple streams of requests of responses to be sent over a single TCP connection. In addition, SPDY allows requests to be prioritized, so, for example, a video that is central to a page's content can be given a higher priority than an advertisement in the margin.
Perhaps the most revolutionary innovation in SPDY is that streams can be bidirectional and can be initiated by either the client or the server, allowing content to be pushed to clients without first being requested. For example, when a user first visits a site, and therefore does not yet have any of the site content cached, the server can push all required resources in response to the first page request instead of waiting for each resource to be separately requested. As an alternative, the server can send hints to the client, suggesting resources that will be needed, but still allowing the client to initiate the requests. This is still faster than waiting for the client to parse the site pages and discover the resource requirements on its own.
Although SPDY is not specific to mobile platforms, the limited bandwidth available over mobile networks means SPDY optimizations will be especially useful in reducing latency for mobile sites when supported.
Ease of implementation: Moderate to advanced, depending on the site and server environment. Google has a SPDY module for Apache 2.2mod_spdythat is available for free; however, mod_spdy has threading model issues and does not play well with mod_php by default, so this requires additional attention in order to ensure it is running correctly on your site.6
No discussion of performance optimization would be complete without a reminder that continuous and careful testing is essential. Every change to your system is just a theory until it is tested against a baseline. Guessing where performance bottlenecks occur is meaningless unless based on real test data.
Great open source and commercial tools are available to provide synthetic tests, complete with geographical distribution and bandwidth/latency throttling. In addition, real-user monitoring (RUM) tools take testing out of the lab and into the field of unpredictable user behavior.
Look for testing options that support mobile, as well as desktop scenarios. If you choose an automated solution, be sure to choose one that continually tests and refines the optimizations it applies.
Performance optimization cannot be effective if it is merely a single step in a linear development process. Rather, it must become part of an ongoing cycle of continuous improvement.
Mobile Application Development: Web vs. Native
Andre Charland and Brian LeRoux
The Evolution of Web Development for Mobile Devices
Nicholas C. Zakas
Making the Mobile Web Faster
1. Bustos, L. Every second counts; how web-site performance impacts shopper behavior. GetElastic (2009); http://www.getelastic.com/performance/.
2. Chromium Projects. SPDY: an experimental protocol for a faster Web; https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper.
3. Everts, T. Case study: How effective are CDNs for mobile visitors. Web Performance Today; http://www.Webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/.
4. Fioravanti, R. Creating fast buttons for mobile Web applications. Google Developers (2011); http://code.google.com/mobile/articles/fast_buttons.html.
5. Linden, G. Marissa Mayer at Web 2.0. Geeking with Greg (2006); http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html.
6. mod-spdy; http://code.google.com/p/mod-spdy/.
7. PhoCusWright. PhoCusWright/Akamai study on travel site performance; http://connect.phocuswright.com/2010/06/phocuswrightakamai-study-on-travel-site-performance/; http://www.akamai.com/dl/whitepapers/Akamai_PcW_Travel_Perf_Whitepaper.pdf.
8. Radware. Case studies from the mobile frontier: the relationship between faster mobile sites and business KPIS (2011); http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/.
9. Radware. 2012 state of mobile e-commerce performance; http://www.strangeloopnetworks.com/resources/videos/case-studies-from-the-mobile-frontier-the-relationship-between-faster-mobile-sites-and-business-kpis-video/.
10. Tealeaf. Report on the Mobile Customer Experience. Based on the Harris Interactive 2011 Mobile Transactions Survey; http://www.tealeaf.com/customer-experience-management/resource-center/rgister.php?doc=mobile-cem.
11. W3C. Network Information API (2012); http://www.w3.org/TR/netinfo-api/.
12. YUI. ImageLoader. Yahoo! User Interface Library; http://yuilibrary.com/yui/docs/imageloader/.
©2013 ACM 0001-0782/13/08
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from firstname.lastname@example.org or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.
No entries found