Visitor Monitoring Loading Mobile Web Pages in 2 Seconds or Less part 1 of 3 | Keynote

Loading Mobile Web Pages in 2 Seconds or Less part 1 of 3

By Aaron Rudger | June 4, 2014

CATEGORIES: Web Performance, Mobile Quality

Loading mobile web pages fast is a tough nut to crack. We've studied and discussed the how Web sites designed for smartphone customers far too often deliver a very slow user experience on average and a significant error rate. Small wonder when some of the mobile Web pages we tracked weighed in at more than 2.5MB and required dozens of round trips for initial page render. Our recent study co-sponsored by Internet Retailer revealed significant issues for mobile customers of Responsive Design websites.

Your customers and visitors don’t want to keep paying a performance penalty for using your mobile site. As we wrote last month, “Embrace it. Resistance is futile.” The trends are undeniable.

A big part of your future is the mobile Web, so if you’re going to take it seriously, you and your Web designers should start by setting the goal of loading your mobile Web pages in 2 seconds or less.

I’m talking about initial page render of above-the-fold content. Even for that, 2 seconds is pretty aggressive (Google wants you to do it in 1 second). But Ken Harker of our Keynote Analytics team is on your side in this. With years of experience in finding the slow, heavy, poorly behaved parts of mobile sites, Ken has summarized the team’s page construction guidelines in a new, free white paper titled “Loading Mobile Web Pages in 2 Seconds or Less.”

In this series of posts I’ll go through the recommendations in the paper. You and your Web designers may already know many of them, but I’m pretty sure you’ll find a few things you haven’t thought of.


First of all, the sequence in which the browser requests resources on the page affects the visitor’s experience. We recommend the following order to render useful, above-the-fold content most quickly:

  1. Base page HTML
  2. CSS
  3. JavaScript required for initial page render only
  4. Images
  5. All other JavaScript
  6. Third-party tags

Next, our recommendations assume that most mobile users are still on 3G-speed network connections. We have probably just crossed the point where 30-33 percent of mobile network connections in the US are LTE, and we probably won’t cross 50 percent until 2016. So, there are still plenty of good reasons to design with 3G in mind.

Finally, as site designer, your highest priority is to reduce the number of network round trips per page, as you’ll see vividly in these posts. Our top three recommendations for accomplishing that in mobile page design are to:

  • eliminate or reduce redirections
  • reduce the number of DNS lookups per page
  • minimize the number of new HTTP requests per page

Easy, huh?

Let’s start with the first two areas from the paper: Improving Overall Architecture and Accelerating Initial Page Render.

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, and keep elements critical to initial render on the same domain. Sites routinely use multiple domains. 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.


  • Always enable HTTP Keep Alive in all situations, on all domains. When HTTP Keep Alive is enabled, TCP connections remain open for the entire session, which can reduce page load time by full seconds.


  • Use Secure Socket Layer (SSL) only when absolutely necessary and on as few domains as necessary. SSL enables secure communication, but each new TCP connection requires establishing SSL (via key exchange), which slows down page load.

Base page:

  • Limit HTML code to 50KB or less and the base page HTML file to 14KB. We recommend that mobile-optimized sites deliver all HTML required for initial page render in a single file 14KB or smaller. Take advantage of techniques like compression, minification (removing whitespace and trimming text) and “early flush” of HTML (to allow loading of CSS and JavaScript before the entire HTML document is loaded).

App Calls:

  • Retrieve HTML code in a single request and defer application calls for additional functionality. Where possible, avoid multiple application calls – especially those that return redirections – to reduce the number of HTTP requests over the mobile network.


  • Serve right-sized content based on connection speed. More mobile operating systems (e.g. Android 2.2+, BlackBerry) are capturing data about the user’s current network connection (3G, 4G, Wi-Fi), letting you serve optimized content based on whether it’s low-speed or high-speed. Identifying the connection can often be done with a simple JavaScript request to the browser.

Accelerating Initial Page Render

For fast initial page 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 (<14KB) in first round trip. With normal TCP settings, the maximum load for the first Round Trip Time (RTT) is 14KB. If the HTML required for initial page render fits in a 14KB file, the browser can begin work without waiting for additional round trips.


  • Deliver render-critical CSS as early as possible. Initial page render waits for the browser to build the Cascading Style Sheet Object Model (CSSOM). Don’t forget that the browser parses HTML incrementally, but it must wait for the entire CSS file to load before it can process any of it. Send what you need early and defer the rest.


  • Load no JavaScript at all during initial page render, or make sure it doesn’t get in the way. 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.

Next Steps

I can see some of you skimming that list, checking the boxes mentally: “ that...yeah, we know about that...uh-huh...” But are you really following these guidelines as you build your mobile site? If you saw what our Keynote Analytics team sees every day, you’d know how much page load time most mobile sites are leaving on the table.

If you’re happy with your page load time and mobile website performance, then there’s not much for you to do. But if your abandon rate and snarky social media comments about your site’s performance are starting to get on your nerves, then have another look through these guidelines and subscribe to this blog to get my next post.

Meanwhile, get our new white paper “Loading Mobile Web Pages in 2 Seconds or Less” and send me your questions and ideas in the comments below.

Back to Top