Shared publicly  - 
Sub-second loading of mobile pages

Different research groups have recently found that:

1. users use smartphones because it's quick and easy
2. smartphone-optimized pages are sometimes (very) slow; the average (mean) loading time is 7 seconds
3. users hate slow pages and are likely to not come back to the website.

Well, then. What's a webmaster to do?

The answer lies in thinking about how the page loads and change a few things.

Firstly, cell networks (3G, and to some extent 4G) have huge latencies compared to wired broadband. These latencies mean that any extra network connection to get an external resource (CSS, JS, images, etc) will add a few hundred milliseconds (at least!) and that will kill the rendering performance of the page.

Secondly, historically webmasters focused on the blocking nature of JavaScript: because the JS can alter the DOM, browsers stop the rendering of pages until they fetch, parse, and execute the JS. That all takes time. 

BUT: CSS is also blocking. Before the browser paints anything on the screen, it needs to know what it looks like; i.e., it will need to have the CSS handy. And if the CSS is not there, it needs to download it (more latency!) and parse it (which has to be done once all the CSS is downloaded because CSS selectors are cascading).

So we need both the JS and the CSS.

Thirdly, instead of trying to get the whole page to render in under a second, think about breaking up the page into the "above-the-fold" part and "the rest. Prioritizing the rendering of the above-the-fold content gives users something to read/interact with while the rest of the page continues to download. This means that in under a second, the user gets something useful.

How do you prioritize the rendering of above-the-fold content? In addition to the page speed best practices, we recommend you inline the CSS and JS required for the above-the-fold content. This means that the rendering of the initial content is not blocked on any more network fetches for external resources.

There is more to it, of course, and full details and references, including the new PageSpeed Insights tool, are in this blog post +Bryan McQuade and I published yesterday :

Finally, there is an important point here: The total loading time can still be more than one second (some pages simply need that), but because we've engaged the user very quickly, the perception the user gets is that the page is fast. To put it as +Steve Souders did earlier this year, we're not just webmasters, we're also "perception brokers":

Steve Souders' Ignite presentation, "The Illusion of Speed", at Velocity 2013.
Thursday, August 08, 2013 at 2:24 PM. Webmaster level: Intermediate Users tell us they use smartphones to search online because it's quick and convenient, but today's average mobile page typically takes more than 7 seconds to load. Wouldn't it be great if mobile pages loaded in under one second?
Pierre Far's profile photoPhilip Jones's profile photoAdam George's profile photodan barker's profile photo
Interesting. For a start, I could swith the way the js/css are included (server side include, html tag) depending on the user agent.

Also, the "below the fold" section could be loaded via ajax after the page is loaded.
I love the emphasis on mobile user experience in this and your announcement from June. How long before you start penalizing desktop pages in smartphone search?
+Andrea Doimo If it's a question of network speed, then UA sniffing is a pretty rough science. I can, and do, use my laptop via my phone's 3G connection. Likewise I use my phone on wifi. I think any speed techniques should be applied as a whole to a web site. The distinction between mobile and desktop is going to slowly (quickly?) fade as the gap between fast and slow, small and big, touch and mouse disappears. My two cents.
Nice, except not sure about about inlining the js & css...
Lot of info to optimize websites !!
To be clear, this is about inlining the CSS and JS required just for above-the-fold content. It's not about inlining the CSS and JS required for the whole page. This HTML + inlined (CSS+JS) is called the critical rendering path to get something in front of the user ASAP while the rest of page continues to load.

It's all detailed in the references in the blog post. The video, in particular, is a great overview.
+Andrea Doimo media queries can be inlined but now it comes down to the browser. Not all the browsers react to media queries the same.
How would you define "above the fold?" Every mobile device will be different (compare smart-phone to phablet to tablet, portrait and landscape). What happens when the page content changes and you no longer need the css/js for that above-the-fold widget? What if the content/purpose and landing page varies? Do you inline it for every page? Honestly, it sounds good in principle - idealistic but a maintenance nightmare. 
hi, Pierre, how is life?

I have 3 progressively-sillier questions about this if it's ok.

QUESTION 1: Does this assume that users view only one page?

For example, if I inline the css/js for a complicated mega-menu system that forms an integral part of the 'above the fold' content, that may mean adding a lot of code across every page on my site. That may speed up the rendering of the first page, but surely slows the rendering of every other page that would normally use a cached version of that code? (especially with things like jquery hosted on/cached  from google's servers)

QUESTION 2: Does the '7 second' figure include Safari?

I don't think Google Analytics records page speed for Safari. Here's an example of a particularly slow page, and how I can't see the data for Safari:

Sorry for the rude questions - mostly for the benefit of my understanding - but hopefully will benefit somebody else too if you are able to answer!

QUESTION 3: Mean vs Median

Silliest question of the lot: you quote 'mean' loading time here. Do you think 'mean' or 'median' is more useful for measuring mobile load speed?


Add a comment...