You know the acronym “tl;dr” — that’s a comment about long articles and social posts, and means “too long, didn’t read.” Let’s think about a new acronym: “ts;dw.” That means your website is “too slow, didn’t wait.”
Slow website load times might cause the user to close the window or hit the back arrow, not only depriving you of a unique visitor and pageview, but also denying you the opportunity to make a sale, gain a subscriber, show an ad, make a restaurant booking, or get out your message.
There are two types of website visitors, and neither is particularly patient.
Someone who deliberately seeks you out — by visiting your site via a bookmark, or who has typed your name specifically into a search engine — might be inclined to stick around a few moments, even if the site is a bit sluggish. You might get 10 seconds, if you’re lucky.
Someone who discovered you for the first time by clicking a link in an article or on social media, or by clicking through a list of search results, has no patience. You need to deliver the page in under a second, or at worst a few seconds. You’ve undoubtedly experienced that yourself, whether on a desktop/notebook or on a mobile device. The page starts to load, the progress indicator stalls — and you hit the back arrow.
According to “The Need for Speed,” a classic article by tech usability expert Jakob Nielson:
“Research on a wide variety of hypertext systems has shown that users need response times of less than one second when moving from one page to another if they are to navigate freely through an information space. Traditional human factors research into response times also shows the need for response times faster than a second. For example, studies done at IBM in the 1970s and 1980s found that mainframe users were more productive when the time between hitting a function key and getting the requested screen was less than a second.
Distribution of the bandwidth of users' connections to the Internet over the last three years Unfortunately we are not getting subsecond response times on the Web any time soon, so we know that users are going to be hurt by slow downloads. Currently, the minimum goal for response times should therefore be to get pages to users in no more than ten seconds, since that's the limit of people's ability to keep their attention focused while waiting.”
In a newer article, “Website Response Times,” Nielson explains:
“0.1 seconds gives the feeling of instantaneous response — that is, 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 (direct manipulation is one of the key GUI techniques to increase user engagement and control).
1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.
10 seconds keeps the user's attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it. After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.
A 10-second delay will often make users leave a site immediately. And even if they stay, it's harder for them to understand what's going on, making it less likely that they'll succeed in any difficult tasks.”
Causes of slow website load times
There are obviously some delays that are beyond our control — like the user being on a very slow mobile connection. However, for the most part, our website’s load time is entirely up to us.
For the most part, our website’s load time is entirely up to us.
We need to do everything possible to accelerate the experience, and in fact I would argue that load time may be the single most important aspect of your site. That’s especially true of your home page, but also of other pages, especially if there are deep links to them from search engines, other Internet sites, or your own marketing emails and tweets.
We used to say that the biggest cause of slow websites was large images, especially too-large images that are downloaded to the browser and dynamically resized. Those are still issues, and you should optimize your site to have a few small graphics, instead of large images. Images are no longer the main culprit, however.
Here are other areas to look for:
External APIs. Those are the killer. Whether they are ad delivery systems, cookie-based tracking systems, dynamically loaded content, or social media widgets, these can be slow slow slow — and worse, inconsistent. Consider eliminating everything that’s not truly essential to your visit. Do you really need to have a dynamic Twitter feed on your home page, or a link that requests a Google map to your showroom every time the page loads? (If you truly need a map on your home page, make it a static image that’s clickable to a dynamic one.)
Too many static parallel resource downloads. If your page is downloading many images or other resources from the same server, that server can bottleneck and begin queuing the responses. The result? A wait.
A failure to compress HTTP. If you aren’t compressing, you are wasting bandwidth. While this sounds obvious, the process isn’t trivial. Here’s an informative article on compression, “Lose the Wait.” Also make sure that you are fully leveraging caches on both the server and browser side for images, content, style sheets and other elements.
Server overload, or insufficient bandwidth to the server. This is particularly prevalent on web servers hosted on premises; many organizations and businesses simply don’t have great Internet connectivity, especially “up” connectivity needed to serve web pages and content quickly. The solution here is to host the web server, and related servers that have content, in the cloud or in a colocation facility.
Server-side or client-side scripts that are too complex. Scripts that run quickly on a test server can bog down under loads. And don’t forget that mobile devices have limited processing power and not much RAM. Look at your JavaScript (and while you’re at it, your CSS). Too much JQuery? Simplify, simplify.
Slow website load times: What to do
Just because the website seems to load fast for you doesn't mean a darn thing. You need objective measurements that simulate genuine website visitor performance — not just right now, not as a one-time test, but on a consistent basis.
Cameron Laird offer excellent advice in “3 Ways to Audit Web Page Load Time on your VPS or Dedicated Server”:
“Your site’s true first impression is temporal. Is your site ready for your customers quickly enough that they don’t wander off to something more captivating, more responsive?”
Your ISP has site monitoring tools. Plus, there are free and paid site monitoring services all over the Internet, some of which go deep into page load times, and can alert you if (or shall we say “when”) things slow down. Find those tools and use them — and respond quickly when the site slows down.
How to respond? Check out another article by Cameron, “5 Steps for Optimizing the Load Time of Web Pages,” for ways to keep an eye on your website performance.
Too slow, didn’t wait
Page load time is arguably the single most aspect of your site. There’s no point in having compelling content, outstanding merchandise and the best prices in town if customers click away. Understand the site’s performance, and always strive to make it faster. Simplify, optimize, cache, then simplify some more. After all, you can’t make a good impression if you aren’t making any impression at all — or if that impression is “ts;dw.”
