Visitor Monitoring Loading Mobile Web Pages in 2 Seconds or Less | Keynote
White Paper

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.

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

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.

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. Meanwhile, only 16 percent of Fortune 100 websites come close to that threshold. 5The Search Agency, “Mobile Experience Scorecard: Fortune 100 Companies,” November 2013.

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:

  1. Base page HTML
  2. CSS
  3. Any JavaScript required for initial page render
  4. Images
  5. All other JavaScript
  6. 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:

  1. Improving Overall Architecture
  2. Accelerating Initial Render
  3. Dealing with Latency on Mobile Networks
  4. Shortening Render Times
  5. Reducing Page Size
  6. 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:

  1. Perform DNS lookups
  2. Establish TCP connection(s) to the web server(s)
  3. Establish SSL connections (for secure page content)
  4. Load the base page HTML document
  5. Execute application calls
  6. 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.

A growing number of mobile operating systems (e.g. Android 2.2+, BlackBerry) are capturing data about the user’s current network connection (3G, 4G, Wi-Fi), enabling server-side application processes to serve optimized content based on whether the connection is low-speed or high-speed. Identifying the connection can often be done with a simple JavaScript request to the browser.

2. Accelerating Initial Render

For fast initial render, all critical, above-the-fold content must be delivered as quickly as possible. Correctly incorporating HTML, Cascading Style Sheets (CSS) and JavaScript to the overall architecture of the page is a big step toward shorter page load time.

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.

Eliminate blocking JavaScript.

JavaScript can slow initial page render when it blocks the loading of all other content on the page, delays the construction of the Domain Object Model (DOM) in the browser’s memory, or queries/modifies the DOM or CSSOM.

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
  • 2-4 JavaScript calls
  • 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

JavaScript, third-party tags and other essentials contribute to good user experience but slow page load.

Limit external JavaScript calls to 4 per page.

JavaScript calls can serialize download in the browser and slow page load, especially on mobile-optimized sites. Slow JavaScript calls can make the entire page feel slow to the user. Keynote recommends caching JavaScript, combining it into as few files as possible and auditing the code to avoid redundancies introduced by different development teams. If a JavaScript call occurs on only one page (e.g., a single geolocation function), deploy it within the HTML for a single file request; otherwise, move frequently used code to an external file instead.

Optimize JavaScript.

Some JavaScript is not needed on a page until after initial render, so deferring their download and execution can make the page load faster. Also, the Web Worker specification in HTML5 allows concurrent, multi-threaded execution of JavaScript in the browser for better performance, especially on limited-capability mobile processors. Large, complex development frameworks like jQuery often include code that mobile-optimized sites do not need.

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.

EventSource JavaScript objects and Server-Sent Events in HTML5 allow the browser to establish efficient, asynchronous communication with the server, especially over a mobile network. The techniques ensure that some page content is deferred until initial page render and functionality are complete. For sites that meter their customers’ data usage, this is more responsible than auto-refreshing pages or sending polling requests.

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;
  • Prefetching does not interfere with JavaScript execution on less-powerful processors;
  • 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.

Keynote recommends page weight (i.e., the sum total size of all the objects sent across the mobile network) below 200KB, with a maximum 400KB for mobile-optimized sites. (Entry pages and marketing pages can be slightly larger if they employ the techniques in this paper for faster page render.) gzip compression is a server setting supported by all mobile browsers, so a 200KB compressed file meets the recommendation as well as a 200KB uncompressed file. Designers can minify text elements like HTML, CSS and JavaScript by removing whitespace in the files.

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.

HTML5 offers new structural elements, functionality (e.g., header, navigation, article, footer), attributes for focus, and data-constrained input types such as date, time, email address and URL; most of those have traditionally required JavaScript. New effects in CSS 3.0 – gradients, rounded corners, border effects – along with animations and transitions eliminate the need for many external images. All popular mobile browsers support these new specifications.

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.

Now that popular mobile browsers support the HTML5 Web Storage specification for offline application caching, Web designers can typically count on access to 5 MB of storage per site rather than 4 MB for all sites on a typical Android component cache. Although this requires explicit management of the cache assets as key-value pairs through the localStorage JavaScript object, items in local storage persist across reboots and will not be flushed out of cache by visits to other sites.

Use local storage instead of cookies.

Because cookies are sent with each HTTP request, implementing cookies for domains on mobile-optimized sites hampers performance. This poses two undesirable alternatives for the return visitor experience: multiple domains, only one of which uses cookies (which will increase initial page load time with extra DNS lookups and/or TCP connections) or a single domain that uses cookies (which adds overhead to every resource request). Instead, Keynote recommends using local storage through HTML5 for storing and managing cookie-like information as efficient key-value pairs used only when explicitly necessary.


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.

Back to Top