Making your web pages fast (part one)

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:

@JohnKaster @delphijunkie @NickHodges So I ran it under Firebug: 117 reqs, 16 servers, 6.98s for the page; 17.02s before onload. Just. Bad.

— Julian M Bucknall (@JMBucknall) August 30, 2015

So this one blog post used 117 HTTP requests for various files (HTML, CSS, JavaScript, images, whatever) from 16 separate web servers. It took a smidge under 7 seconds just to generate and receive the initial HTML page (from which all the other requests would be derived). It was a grand total of 17 seconds before the browser signaled the onload event (after which a whole bunch of scripts would run, etc). All in all, pretty bad. And in reality a lot of this can be avoided with just a little more care.

About to reveal all

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.

• At around 0.1 second, the user feels it’s instantaneous. To quote Nielsen: “The outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation.” That is, at this order of magnitude, it feels like the browser is directly responding to you, the user.
• At around 1 second, the user is aware that the browser is doing something or that the network is introducing some level of latency, but their train of thought is not broken (and as devs we know how annoying that can be). Quote: “Users [. . .] still feel in control of the overall experience and that they're moving freely rather than waiting on the computer.”
• At 10 seconds, well that’s it: you have pretty much lost the user. Nielsen again: “They start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.” That page I was describing above? I really wouldn’t have bothered had I not been timing it. (And if fact I haven’t visited that overall blog site again since, so it could have the best content in the world, I wouldn’t know.)

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.

  Loading links to posts on similar topics...