Recently, I had occasion to want to read an article on <a well-known development company>’s developer blog. It took, believe it or not, over 17 seconds to load and display on my wired connection, around 10 seconds longer than I would have waited if I hadn’t have wanted to read the content. Apparently on a phone it took over 60 seconds to load. I ran it under Firebug because I just didn’t believe it and wanted to see what would take so long. This is the tweet I sent:
When we navigate to a web page, we tend to have certain expectations. We assume that the page renders quickly, or at least quickly enough that we’re not aware of it (rather than the opposite case: has our sketchy internet connection died again). We also take it as read that there won’t be weird rendering artifacts, such as the content rendering one way and then immediately rendering in another. After all, we are visiting a web page because we have to accomplish one or more tasks with that page. Our task may be as simple as just reading the article, or it may be that we need to see some list of products, one of which we want to buy, or it may be a login screen.
In this series of posts, I want to explore how to present the content of a web page as quickly as possible to the reader. It’s based on a session I’ve presented at various conferences over the past year, and it’s also been used by others at DevExpress when I’ve been unable to attend.
The first thing to realize is that it’s not necessarily about raw performance – although that has a lot to do with it – but rather it’s about perceived performance. If the web developer was canny enough to present the content you, the reader, needed as fast as possible, but the remaining parts of the page took longer (say, a list of recent posts or similar posts, ads, the tweet stream, whatever), you’d rate the page as a whole as faster than the alternative (that is, get all the data and render only when it was available). The overall time to render the whole page would be the same, give or take, but the reader’s task (read the content) could be started much earlier. The “performance experience”, if I may call it that, is essentially subjective, and not necessarily objective.
As an example: navigate to Amazon.com. As you do so, don’t look at the page, but stare at where the scrollbar will be displayed on the right. Depending on your connection speed, general traffic, etc, you’ll glimpse the main banner displayed on the left out of the corner of your eye, well before the scrollbar gets displayed when the rest of the page is downloaded and renders large enough. An Amazon shopper’s perception then will be that the website is displayed instantaneously, even though the content “below the fold” doesn’t arrive immediately. You could say Amazon’s devs have heightened this perception to the level of performance art.
There have been studies published on web response times showing that taking longer than a few seconds means the user will probably leave and maybe never come back. One such study is Jacob Nielsen’s article on the subject, where he divides response times into orders of magnitude.
Next time, in part two, I’ll talk about how to measure the speed of a webpage and how to use that information to speed up your own webpages. As an amuse-bouche until then, I will consider optimizing three main things: the number of requests for files, the sizes of the files returned, and where they are coming from. Sharding to the rescue! After that I’ll consider the content of the markup and how that can affect your perception of the rendering speed of the page.