Loading Mobile Web Pages in 2 Seconds or Less
Page Construction Best Practices for Mobile Websites
2010: Google begins factoring site performance into its Page Rank formula. 1Google, “Using site speed in web search ranking,” April 2010. http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html
Early 2013: Google reports that global mean time for real users to load pages is 7 to 8 seconds. 2Google, “Is the web getting faster?” Apr 2013 http://analytics.blogspot.com/2013/04/is-web-getting-faster.html
Mid-2013: Strangeloop reports that 85 percent of mobile users expect sites to load at least as fast or faster than sites on their desktop. 3Strangeloop Networks, “Mobile Device Users Expect Sites to Load Fast,” 2013. http://www.strangeloopnetworks.com/resources/infographics/web-performance-and-user-expectations/mobile-device-users-expect-sites-to-load-fast/
Late 2013: Google recommends that mobile pages render above-the-fold content in less than 1 second. 4Google, “Mobile Analysis in PageSpeed Insights,” updated November 2013. https://developers.google.com/speed/docs/insights/mobile Meanwhile, only 16 percent of Fortune 100 websites come close to that threshold. 5The Search Agency, “Mobile Experience Scorecard: Fortune 100 Companies,” November 2013. http://info.thesearchagency.com/TheSearchAgencysMobileExperienceScorecardFortune100Companies.html
Talk about setting the bar high.
Mobile Web page performance is a tough nut to crack as it is. Users expect desktop-like responsiveness despite the lower throughput and higher latency of mobile networks. High performance on a mobile site results in more stickiness, greater ad revenue and increased sales, while poor performance leads users to abandon the site or, worse yet, complain about it.
Site designers may have little control over the mobile network itself, but they have plenty of control over how their pages behave on both the device and the server. Nobody can guarantee 2-second page load times, but techniques abound for rendering satisfying, above-the-fold (i.e., initial page render) content on a mobile browser with minimal delay. Above all, applying those techniques to reduce the number of network round-trips per page should be the site designer’s top priority.
This white paper encapsulates the recommendations of the Keynote Analytics team in analyzing thousands of Keynote customer sites since 2001. Designers, developers and DevOps professionals familiar with Web terminology can use the paper as a roadmap toward 2-second page load times on their own mobile sites.
Introduction – Focus Above the Fold
To achieve the optimal user experience, the immediately visible, above-the-fold content on the page’s critical rendering path needs to display and be functional to the site visitor as soon as possible.
The sequence in which the browser requests resources on the page affects the visitor’s experience. Keynote recommends the following order to render a useful, above-the-fold page most quickly:
- Base page HTML
- Third-party tags
Speeding up the delivery of both above-the-fold and below-the-fold page content requires that designers deal with six broad areas of the Web, each of which has its own set of variables:
- Improving Overall Architecture
- Accelerating Initial Render
- Dealing with Latency on Mobile Networks
- Shortening Render Times
- Reducing Page Size
- Enhancing the Return Visitor Experience
We examine each of those areas and variables below.1. Improving Overall Architecture
All pages follow the same basic steps while loading, and there is room for improvement at each step:
- Perform DNS lookups
- Establish TCP connection(s) to the web server(s)
- Establish SSL connections (for secure page content)
- Load the base page HTML document
- Execute application calls
- Load content
Use no more than 2 domains per page.
Sites routinely use multiple domains to accommodate mobile and non-mobile content, third-party tags for analytics and ads, secure and non-secure content, assets pulled from internal business units, and intentional domain sharding (which Keynote does not recommend). However, every additional domain on a page requires an additional DNS lookup – particularly costly on a mobile network – and at least one additional TCP connection to a Web server.
Keep TCP connections persistent with HTTP Keep Alive.
The entire process of delivering a page depends on TCP and the critical initial connection that usually takes place once per domain. But if HTTP Keep Alive (i.e., persistent connection) is disabled, the site forces a costly, new TCP connection for each request. When HTTP Keep Alive is enabled:
- the browser establishes a new TCP connection to each domain and reuses it for the life of the session;
- connections remain open unless forced to close (by a server or network device setting);
- the savings from not having to close connections can reduce page load time by seconds.
Use Secure Socket Layer (SSL) sparingly.
SSL enables secure communication between the server and the browser through encryption. However, each new TCP connection requires establishing SSL (via key exchange), slowing down page load. Using HTTP Keep Alive is especially helpful on pages served with SSL connections.
Reduce Size of HTML file.
The HTML code served for a page contains its core structure, but server-side generation for the HTML can be a performance bottleneck. Keynote recommends that mobile-optimized sites deliver all HTML required for initial page render in a single file 14KB or smaller. Techniques like minification (removing whitespace and trimming text) and compression (all mobile browsers support gzip compression) can reduce the size of the HTML file without compromising content. See “Deliver base page HTML in first round trip” below.
Retrieve HTML code in a single request.
Except for the simplest web pages, all sites require application calls (HTTP GET or HTTP POST) to retrieve the core, dynamically-generated HTML or multiple HTML documents. Where possible, avoid multiple application calls to reduce the number of HTTP requests over the mobile network. Also avoid application calls that return redirections, which serialize (i.e., induce delay by forcing the browser to load assets one at a time, rather than in parallel) and slow the process of loading the HTML in the browser.
Serve content optimized for connection type.
2. Accelerating Initial Render
Deliver base page HTML in first round trip.
To initially render the page most quickly, the browser must receive critical HTML content in the first Round Trip Time (RTT) of the initial TCP connection. With normal TCP settings, the maximum load for the first round trip of data delivery is 14KB, so if the base page (i.e., HTML required for initial page render) can fit in a 14KB file, the browser can begin work without waiting for additional round trips. Load additional HTML beyond the base 14KB from a separate file after initial render.
Deliver CSS as early as possible
Initial render is delayed until the browser can build the Cascading Style Sheet Object Model (CSSOM), so it is imperative to load CSS early. The browser parses HTML incrementally, but it must wait for the entire CSS file to load before it can process any of it. Deferring non-critical CSS content to files loaded later can speed up the initial page render.
3. Dealing with Latency on Mobile Networks
Reducing the number of round trips per page should be the site designer’s top priority.
Latency can be as much as 10 times worse on a typical 3G mobile network than on a high-speed wired network connection. Round trips for requests, responses and DNS lookups that take 20 to 50 ms on a wired network might require 250 ms or longer over a 3G network. Web designers can avoid compounding that latency by carefully using redirections, HTTP requests, images and content delivery networks (CDNs).
Redirect on the server side.
Redirections are useful for moving from a mobile to a non-mobile domain, from a non-secure to a secure domain and from a generic to a customized response (e.g. iPhone- versus Android-optimized HTML). However, redirections serialize the download in the browser, especially when they precede the base page HTML delivery, making a 2-second initial render almost impossible. Except when moving from a non-secure to a secure domain, avoid redirections and their very high-latency round trips to the server.
Limit HTTP requests to 20 per page.
Limiting the number of elements on a page is the best way to reduce round trips between browser and servers. For sites with most visitors on 4G networks, Keynote recommends a maximum of 20 or fewer requested assets per page—fewer for slower connections, but only 50 maximum even at WiFi speeds. Ways to reduce HTTP requests:
- No redirections if possible
- 1 HTML file
- 1-2 CSS elements
- 12 or fewer image files
- 2 or fewer third-party or analytics tags
Reduce separate requests for images.
Several techniques can lead to fewer image requests:
- CSS sprites combine multiple small images in a grid in a single file, and CSS background image rules display appropriate portions of the image file where needed on the page.
- Image manipulation tools in HTML5 enable effects like rotations to replace loading separate left and right versions of images, or to replace certain wait transition images altogether. HTML5 can also eliminate the need for color swatches.
- Data URIs– small images in-lined directly to HTML using Base64 encoding – eliminate separate round trips to the server. (Note that data URIs are not suited to large images, and that they can complicate the caching model.)
Tune CDN usage.
Keynote encourages the owners of all sites – especially global sites – to move their static content to CDN edge servers located closer in geography and on the network to site visitors. A well-implemented CDN can improve responsiveness, even for dynamic content, and provide a form of peak-capacity load handling. (Note that most of the latency on mobile-optimized sites occurs in the last wireless hop to the device. Not all CDNs deliver the same level of benefit for mobile-optimized site visitors as for desktop site visitors.)
4. Shortening Render Times
Limit third-party tags to 2 per page.
Each third-party call (e.g., for advertising, marketing analytics, tracking) requires a new round-trip request and response from a Web server and may require a DNS lookup. Furthermore, third-party providers may introduce quality problems or tags that block other page content from loading. At the very least, they occupy browser resources that other page content could be using.
Replace click events with touch events.
On the touch screens used in mobile devices, onclick events often incur delays of 300 to 500 ms after the user taps the screen, as the browser or OS waits for additional input or gestures. Replacing onclick with touch events (e.g., touchstart, touchmove, touchend) eliminates this delay and helps speed up page transitions. Sites can be designed either to support both touch events and onclick, or to identify the device type and serve only the appropriate version of the HTML.
Use Server-Sent Events for asynchronous communication.
Prefetch anticipated content.
Prefetching page assets in anticipation of their use in subsequent page loads (e.g., through fixed steps in a purchase path, or a search -> search results -> search result details path) can be effective on mobile-optimized sites, provided that:
- The assets load only after the current page is completely loaded;
- The prefetched assets do not flush other assets out of the cache prematurely; and
- Customers with metered usage have the option of disabling prefetching.
5. Reducing Page Size
Although the number of requests is more important to page load time (see “Limit HTTP requests to 20 per page” above), heavy pages generally result in poor performance on mobile networks.
Limit overall page weight to 200KB.
Limit image size to 10KB each.
Keynote recommends a maximum of 10KB per image. Beyond that, consider optimizing or replacing the image.
- Most photographic images in JPEG format look acceptable at 85 percent quality.
- Scale images to be size- and quality-appropriate for mobile device displays.
- Image files with few colors may be smaller in GIF or PNG formats than in JPEG.
Also, put controls in place to prevent internal content owners from accidentally publishing large images on the mobile-optimized site. Inappropriately heavy content can ruin good mobile site design.
Take advantage of HTML5 and CSS 3.0.
Optimize HTML and CSS content.
Some development frameworks introduce validation tags to the HTML header that are unnecessary when deployed to production, adding weight without adding value. Web designers should examine all META tags for their necessity and CSS rules for their occurrence on the page to avoid sending useless bytes. Development frameworks may also automatically add attributes like target=“_self” or class=“” to anchor (a) and image (img) elements; designers can safely remove them and reduce HTML size.
Trim unnecessary HTTP headers.
Although it is not a part of Web page design per se, many sites send unnecessary HTTP headers with every request. To speed up page load, designers should remove header values for server IDs or server software versions that mobile browsers generally ignore anyway.
6. Enhancing the Return Visitor Experience
Understanding and efficiently managing the cache can reduce round trips for return visitors.
Tune caching for return visitors.
Pulling an asset from cache avoids round trips and improves the return visitor experience. However, most mobile devices have relatively small caches (e.g., the iPhone 3GS has a limit of 25KB per HTML object, and most Android devices limit the total component cache size to 4 MB) that may not persist across device reboots. Other options for reducing requests include setting far future Expires headers 7 or more days – or even years – into the future, and managing versions with unique date stamps or codes in the filename to force new versions of elements to browsers on demand.
Keynote recommends avoiding the use of ETags to improve the return visitor experience on mobile-optimized sites. ETags are designed to validate content with a single server, but in multi-server environments they can actually backfire by forcing the browser to fetch from a different server a new version of a file already in cache.
Cache in offline storage.
Use local storage instead of cookies.
To get to a 2-second mobile Web page, site designers must reduce the number of round trips. Not all pages can be optimized to load that quickly, but it is a worthwhile goal. Designers must select the optimizations that make sense for their particular site.
The best way to implement the recommendations provided in this document is to collect and analyze actual performance measurements. Instead of a rules-based approach, Keynote strongly recommends taking ongoing measurements of the site and pages. By analyzing the resulting data, site designers can see exactly what is slowing page load and build their own mobile page guidelines for maximum performance.