Over the past few years, we’ve made great strides in understanding and optimizing mobile web performance. However, for the most part, mobile web browsing continues to be slow. Google Analytics data shows that the average web page takes over 10 seconds to load on mobile. We know that a user’s thought process is typically interrupted after waiting for just one second, resulting in that user starting to become disengaged. So at a minimum, the “above the fold” content of a web page should render in less than one second. Clearly, we’ve still got a lot of work to do.

But where should we focus our attention when optimizing mobile web performance? We know that mobile networks have highly variable latency and bandwidth characteristics, and that in general mobile network latency is substantially higher than that on desktop connections. We also know that for modern networks, it is round trip time, not bandwidth, that is the dominating factor in page load time. Given this, to make the mobile web fast, our attention should be focused on minimizing the number of blocking round trips incurred before a web page can render its content to the device’s screen.

What blocks rendering a web page to the screen?

First, let’s look at the sequence of events that happens between the time a user initiates a page navigation and the time the browser can render that page to the screen. Round trips may be incurred for DNS resolution, TCP connection, and the request being sent to the server and the response being streamed back. Unfortunately, there’s not much developers can do to avoid these round trips. For repeat visitors, a longer DNS TTL can help, but TCP connection and request/response overhead will be incurred on every new navigation to a page (assuming there is no warm TCP connection ready to be reused by the client).

Once these initial round trips are incurred, the mobile device can begin parsing the HTML response. But the browser can’t paint content to the screen just yet. Before content in the HTML can be painted to the screen, the browser must construct the render tree to determine where the elements in the DOM will appear on screen. And before the render tree can be constructed, the DOM tree must be constructed. The DOM tree is constructed through a combination of parsing HTML and possibly JavaScript execution.

So what are the things that block parsing of HTML, DOM tree construction, and render tree construction? Most of the time, parsing, DOM tree, and render tree construction are very fast. However, there are a few antipatterns that can cause these processes to get blocked on the network.

Sources of delay during rendering: external JavaScript and CSS

The most significant source of delay during HTML parsing is external JavaScript. When a browser encounters a (non-async) external script during HTML parsing, it must halt parsing of subsequent HTML until that JavaScript is downloaded, parsed, and executed. This incurs additional round trips, which are especially expensive on mobile. If the script is loaded from a hostname other than the hostname the HTML was served from, additional round trips may be incurred for DNS resolution and TCP connection.

In addition, render tree construction gets blocked on stylesheets, so just as external JavaScript introduces delays during DOM tree construction, external stylesheets introduce delays during render tree construction.

In short, external JavaScript and CSS loaded early in the document (e.g. in the <head>) are performance killers, and they are especially expensive on mobile due to the higher round trip times associated with mobile networks.

Making mobile pages fast

To be fast, a mobile web page must include all of the content needed to render the above the fold region in the initial HTML payload without blocking on external JavaScript or CSS resources. Ideally, all the content needed to render the above the fold region should be in the first 15kB on the network (this is post-gzip-compression size; pre-gzip can be larger), since this is the size of the initial congestion window on modern Linux kernels. This does not mean simply inlining all of the JavaScript and CSS that used to be loaded externally. Instead, just the JavaScript and CSS needed to render the above the fold region should be inlined, and JavaScript or CSS needed to add additional functionality to the page should be loaded asynchronously. For instance, if we have a page like the following:

<html>
<head>
  <link rel="stylesheet" href="my.css">
  <script src="my.js"></script>
</head>
<body>
  <div class="main">
    Here is my content.
  </div>
  <div class="leftnav">
    Perhaps there is a left nav bar here.
  </div>
  ...
</body>
</html>

We need to identify the parts of my.js and my.css needed to render the initial content, inline those parts, and delay or async load the remaining JavaScript and CSS needed for the page. This may end up looking something like:

<html>
<head>
  <style>
  .main { ... }
  .leftnav { ... }
  /* ... any other styles needed for the initial render here ... */
  </style>
  <script>
  // Any script needed for initial render here.
  // Ideally, there should be no JS needed for the initial render
  </script>
</head>
<body>
  <div class="main">
    Here is my content.
  </div>
  <div class="leftnav">
    Perhaps there is a left nav bar here.
  </div>
  ...
  <!-- 
    NOTE: delay loading of script and stylesheet may best be done
     in an asynchronous callback such as `requestAnimationFrame` 
     rather than inline in HTML, since the callback will be invoked 
     after the browser has rendered the earlier HTML content to the screen.
   -->
  <link rel="stylesheet" href="my_leftover.css">
  <script src="my_leftover.js"></script>
</body>
</html>

The current state of the mobile web

A brief survey of mobile web pages shows that nearly all pages include blocking external JavaScript and/or CSS before any above the fold content is displayed. Exceptions include Google Maps, Google Search, Yahoo! News, and sites like http://www.yummly.com/ and Kayak. Unfortunately, some of these sites inline JavaScript and CSS that isn’t needed for the initial render, which unnecessarily delays the time it takes to render these pages.

Interestingly, browsing the mobile web with JavaScript disabled reveals that even though most pages load blocking external JavaScript in the head, few of these pages actually need that JavaScript to render their initial content. These pages would benefit from delay or async loading their JavaScript to get the JavaScript out of the critical path of the initial render of the page.

What else can block the initial render of a web page?

Blocking external JavaScript and CSS are the most common sources of delay on the web. However, there are other common sources of delay that mobile developers should be aware of. One source is HTTP redirects of the main HTML document. These redirects incur additional round trips, and if the redirect navigates to a different hostname (e.g. www.example.com to m.example.com), they add even greater delays due to DNS resolution and TCP connection times. A second source of delay is server backend time spent generating the HTML response. All of the time spent generating the initial HTML response will block rendering on the screen, so server backend time should be kept to a minimum.

Rendering in under one second

If we estimate 3G network round trip time at 250ms, we can compute the minimum estimated time between when a user initiates a web page navigation and when that page renders its above the fold content on the screen. Assuming no blocking external JavaScript or CSS, we incur three round trips for DNS, TCP, and request/response, for a total of 750ms, plus 100ms for backend time. This brings us to 850ms. As long as render-blocking JavaScript and CSS is inlined and the size of the initial HTML payload is kept to a minimum (e.g. under 15kB compressed), the time it takes to parse and render should be well under 100ms, bringing us in at 950ms, just under our one second target.

Summary

In summary, to make your mobile web page render in under one second, you should:

  • keep server backend time to generate HTML to a minimum (under 100ms)
  • avoid HTTP redirects for the main HTML resource
  • avoid loading blocking external JavaScript and CSS before the initial render
  • inline just the JavaScript and CSS needed for the initial render
  • delay or async load any JavaScript and CSS not needed for the initial render
  • keep HTML payload needed to render initial content to under 15kB compressed

If you are looking to improve the performance of your mobile web pages, give these optimizations a try.

ABOUT THE AUTHOR
Bryan McQuade photo

Bryan McQuade (@bryanmcquade) leads the Page Speed team at Google. He has contributed to various projects that make the web faster, including Shared Dictionary Compression over HTTP and optimizing web servers to better utilize HTTP.

35 Responses to “Make your mobile pages render in under one second”

  1. Alberto

    Great tips! I think you can also add some tools like Slowly app that allows you to deeply inspect how your web page performs with a throttled bandwidth.

  2. Thierry

    Question concerning: “Sources of delay during rendering: external JavaScript and CSS.” As far as speed goes am I better off with jQuery Core, UI being hosted from the same source as my HTML or from CDN or Google hosted jQuery libraries?

  3. Eric Perret

    Good article. What about caching in the browser? If I have a dynamically generated page which has some CSS and JS inline (which will need to be downloaded every time), that seems less efficient than having it in an external file that can be cached in the browser and referenced on repeat view of the page (or different pages).

  4. chaenu

    Why do you even load some css on top? Don’t you prefer to have no stylings, but the content some ms earlier?

  5. Bob Pelerson

    “Since this is the size of the initial congestion window on modern Linux kernels.”

    Why do we care about the init cwd on Linux kernels? We should care more about FreeBSD kernels here – most high performance websites use FreeBSD for good reason.

  6. Adam

    How would you recommend delaying load of JavaScript? Do you simply mean to use setTimeout? Thanks

  7. Richard Hearne

    Do you have any advice on how best to implement this in responsive design?

    Do you suggest dynamic markup delivery based on requesting client type?

  8. Mobile SEO with Google’s Pierre Far | Dev Inform

    [...] Make Your Mobile Pages Render in Under One Second [...]

  9. Nate Volker

    It might be important to note that using a inside the body as you suggest to do here goes against the spec. elements, (unless they are used with the itemprop attribute to provide metadata) are only allowed in the of the document.

  10. Nate Volker

    It might be important to note that using a <link> element inside the <body> as you suggest to do here goes against the spec. <link> elements, (unless they are used with the itemprop attribute to provide metadata) are only allowed in the of the <head> document.

  11. Google Will Punish You For Not Having A Mobile Website

    [...] Make your mobile pages render in under one second: Common delays are due to external JavaScript and CSS. [...]

  12. Google Will Punish You If You Don’t Have A Mobile-Friendly Website - I Live Mobile : I Live Mobile

    [...] Make your mobile pages render in under one second: Common delays are due to external JavaScript and CSS. [...]

  13. The Ultimate Responsive Web Design Beginners Resource List » Target Local

    [...] Bryan McQuade: Make your mobile pages render in under one second [...]

  14. Optimizing smartphone websites | Chuck Camroux Blog

    [...] the rest of Bryan McQuade’s important post about site speed [...]

  15. Smartphone Website Mistakes Can Hurt Search Visibility

    [...] According to Bryan McQuade (head of Google’s Page Speed team), you should work to make your mobile pages render in under one second. [...]

  16. Kamal

    Very nicely articulated, thank you for helping millions to improve the mobile app performance.

  17. Mobile SEO with Google’s Pierre Far

    [...] Make Your Mobile Pages Render in Under One Second [...]

  18. Terry Jett

    Excellent article and advice!

    I am starting to see more and more bloated mobile sites. Even on 4G with 5 bars signal many of the larger companies sites take up to 20 (sometimes +) seconds to load.

    Just by rearranging the loading of java files and compressing css has gained me new clients. It does not take a lot of work to cut loading time in half.

    Thanks for sharing your knowledge,

    Terry Jett

  19. Site pour les mobiles : 6 points importants

    [...] vos sites pour améliorer et accélérer leur chargement est primordial. Il y a beaucoup de Best Practicies qui traînent sur internet pour corriger ce point. Si vous avez un site sur WordPress déjà [...]

  20. Mukul

    How to identify and fix the problems of blocking script resources blocking CSS resources of a website created using wordpress.

  21. techno blog

    Great tips.
    wonderful artiicle bro….
    visit Visit technoblog !

  22. Timothy

    So your advice is not to have a m.yourwebsite.com as it will delay rendering the page under a second. Anyway I will try to get it under that time and will keep the things you suggested in this article . Thanks

  23. Battlefield

    Awesome trick! Thanks :) Just used Page Speed, got some work.

  24. Melhorando Performace na Web – Parte 1 | Bruno Sato

    […] Perf Calendar – Make your mobile pages render in under one second […]

  25. The Mega Guide to Maximizing eCommerce Sales, Revenues and Performance on all Fronts

    […] Again, don’t forget about mobile. Bryan McQuade (Google’s Page Speed team lead) has an excellent guide for making mobile pages render super-fast. […]

  26. The Mega Guide to Maximizing eCommerce Sales, Revenues and Performance on all Fronts - Oscar Pena

    […] Again, don’t forget about mobile. Bryan McQuade (Google’s Page Speed team lead) has an excellent guide for making mobile pages render super-fast. […]

  27. | ConnectingtotheCloud.com

    […] Again, don’t forget about mobile. Bryan McQuade (Google’s Page Speed team lead) has an excellent guide for making mobile pages render super-fast. […]

  28. Mega Guide to Maximizing eCommerce Sales, Revenues and Performance on all Fronts | ravibhushanseo

    […] Again, don’t forget about mobile. Bryan McQuade (Google’s Page Speed team lead) has an excellent guide for making mobile pages render super-fast. […]

  29. An Unapologetic Update On Mobile SEO | iAcquire Blog

    […] will be less likely to rank slow-loading websites on mobile devices. Google’s blog references this piece on making your mobile web pages render in under one second, as well as this blog of their own, so […]

  30. Mobile SEO for Ecommerce: Bridging The Gap Between Google & Customers' Fingertips | Search Engine People | Toronto

    […] just went up in importance. Brayn McQuade of Performance Calendar insists on making sure that your web pages load under a second. Now, that's more challenging for ecommerce stores due to product/service images and tons of […]

  31. A Quick SEO Guide to Optimizing Mobile Sites | The Level

    […] Does your site load under one second? If not, visitors may be bouncing off your site. Google urges developers and companies to take into account the speed of network connections on mobile devices. Making your mobile pages load faster involves making sure that content above the fold is rendered in such a way that external JavaScript and CSS are not blocked. Bryan McQuad, does an excellent job describing how you can Make Your Mobile Pages Render in Under One Second. […]

  32. Aurélien Strasbourg

    Thanks for this very helpful paper !

  33. dikamrafli

    Saya baru punya blog mobile.apa yang harus kerjakan di blog mobile supaya cepat di rayapi mesin telusur?
    Saya belum mengerti apa apa.
    Kasih keterangan yang sederhana mengatur blog mobile.
    Terima kasih.

  34. 구글이 충고하는 모바일대응 전략 (5) 관계없는 상호링크와 페이지로딩속도 |

    […] 충고합니다. 그리고 이러한 왕복시간 단축에 관심을 기울여야 하는 부분이 외부의 자바스크립트와 CSS에 대한 최적화를 권유하고 있습니다. […]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities