Notes on making websites fast
The elevator pitch. I guess because most of us are distractable, we may not be able to listen to you for a longer than it takes to ride an elevator. So you must say it all before the ride is over. Otherwise, you may be trailing us out the elevator doors and maybe even into our cab.
Ideal: within 7 seconds a web page loads, says what it’s about, and invites its visitor to read or do more.
The elevator pitch and the website pitch have the speed mandate in common. They say an elevator pitch should be 30 seconds, and that’s not a bad benchmark for your website. But a website should get started in on that pitch really quickly. Ideal: within 7 seconds a web page loads, says what it’s about, and invites its visitor to read or do more. That’s my unscientific guess of what is ideal. Sometimes you’ll see claims like “the average web page visit is 7 seconds”. Or “the average web page visit is 59 seconds”.
But in truth, there is no universal average and the site average doesn’t matter anyway; what matters is how long visitors will stick around on a given page; you can figure that out through testing and analysis. Analytics tools like Hotjar that record videos of user activity are the best gauge of visit duration. I guess site visits are kind of like elevator rides in that they vary in duration. But 7 seconds is a good, aggressive benchmark for how much time you have to tell your visitor what your web page is about. If I can’t figure out what the point of a web page is within 7 seconds, I probably will not stick around.
So how much of that 7 seconds of time should be spent waiting for the page to load versus scanning its content? According to CNN, 0.2 seconds, because that is how long on average, a CNN.com page takes to load into a broadband connection. Leaving 6.8 seconds for the content to hook you into a longer visit. But many websites take 3, 4 or even the whole 7 seconds to load.
Here’s a spectrum of site speeds to think about.
- 0.2 seconds or less. So fast it feels like a desktop app and very hard to achieve with complex sites. No matter how lame content and design may be, most users love a site that loads this fast.
- 2 second or less. A fast but realistic goal for even complex sites. Users love sites that load in 2 seconds.
- 4 seconds or less. Acceptable; many sites we visit fall in this range and we’re so used to it we don’t notice.
- 4 to 7 seconds. This is too slow and is noticeable. And of course, abiding by the 7-second rule, it leaves little or no time for a page to be scanned once it’s loaded.
- 8 or more seconds. I do think that most people will close a browser window if a page takes this long to load.
Site speed for trusted transactions
There are many ways to engender trust in users who you want to engage in transactions and site speed is one of them. Site speed is especially important digital commerce transactions, but it matters a lot if any kind of personal information is collected.
According to a study by CDN infrastructure company Akamai, two seconds is ideal for ECommerce transactions. Amazon.com released a study that indicated that by increasing their speed by 0.1 seconds, they earned 660 million dollars in annual profit. And perhaps you have read or been told that Google uses site speed as a factor in its search rankings.
We have all experienced the feeling of waiting for a page to load, wondering whether our profile, our comment, or our order was processed. Never is this experience shadier than when we have just entered credit card information into a web form.
I think what’s going on here is that it’s not just that speed is less frustrating, it’s that it feels safe. We have all experienced the feeling of waiting for a page to load, wondering whether our profile, our comment, or our order was processed. Never is this experience shadier than when we have just entered credit card information into a web form. Page load stalling, the loading icon spinning, white page, etc. And I think that’s true to a lesser extent for each visit in a “conversion funnel” — a series of pages leading a user to perform a transaction. When you make that first page the user visits in the funnel load extremely quickly, whether it’s the homepage or a custom landing page, you may have earned a little trust.
Site speed optimization is something my colleagues and I have worked on a lot in recent years. It became especially important with Drupal 7, which is big powerful application and slower than its close relatives Drupal 6 and WordPress, any version. Drupal 8 is also slow; both products are meant to be carefully fine-tuned and both are capable of rendering blazing fast loading pages.
What technical speed optimization actually consists of
Technology, design and copywriting, even internal processes that have nothing at all to do with technology, are all means of making your site faster but I’ll limit this to technical. Without going into much detail, the five main areas are:
- Image optimization, which is really easy to do and very rarely done.
- Web development, which is mostly about leaner, smarter code through front-end web development.
- Application optimization, which is largely about designing data structure and application logic intelligently but also about caching.
- Server manipulation, which is largely about caching.
- Hosting infrastructure, which is about load balancing and also CDN integration.
Believe it or not, that’s the short version; the long version gets pretty overwhelming and I think that’s why a lot of sites languish in the 4-7 second load range — and why a site that loads in fractions of a second is so rare. Each of these 5 areas needs some attention at some point and a slow site almost always suffers from being lacking in more than one of these areas. Unfortunately, some of this stuff is fairly complex and not necessarily inexpensive to implement.
And another important consideration is that mobile versus desktop considerations need to be planned for. Image optimization has an outsize impact on mobile load times since smaller processors may have a hard time loading, for example, enormous banner images. Google PageSpeed Insights changes its functionality rather often, but I have found over the years that it tends to offer an excellent scoring of desktop versus mobile site speed.
Some things I have noticed
If there’s any guiding principle, it’s that good ROI will only happen when site speed optimization is carefully designed in advance. So before creating new web servers, installing new software and databases and developing new website code, some kind of plan should be written down that guides functional design and development towards a fast-loading site.
If there’s any guiding principle, it’s that good ROI will only happen when site speed optimization is carefully designed in advance.
If there’s another guiding principle it’s that site speed optimization is not a one and done thing. With Drupal implementations especially, it’s too complex a system not to be at risk of paralysis as the website gets bigger and more feature-ridden. It’s not about unseen monkey wrenches setting off bad chain effects, though that’s a consideration, it’s about brute power and cause and effect. We expect a website to do more and more ad infinitum, but every piece of software has its limits. Think of an elevator again — as you put more and more people and things on an elevator, it goes slower; it may even stop going. And the same is particularly true of software implementations like enterprise Drupal: if you keep adding more functionality and content to them, without fine-tuning or beefing up their engines, they will eventually get very, very slow and ultimately come to a halt. No matter how brilliantly designed a new feature addition to an application may be, it’s still a new feature addition. So continuous attention to site speed is great and a continuous enhancement schedule may be called for.
So in addition to advance planning and ongoing attention, the thing I’ve learned from putting site speed optimization into practice is that it inherently correlates with other good things, especially application optimization. A better designed Drupal application might accidentally yield or enhance:
- a more intuitive website management interface for site owners
- a clearer UX for site visitors by reducing navigation or category clutter,
- a shorter page-to-page navigation path to get users from A to B
- less overhead on server maintenance and analysis
- an Agile, iterative deployment methodology
So site optimization is a challenge with sometimes unforeseen, virtuous-cycle benefits, but broadly speaking it’s not something I think falls into the category of “recommend or not” or “9 on a scale of 1-10”. It’s like responsive mobile: it’s here to stay as its own thing, and it’s something that can be an inherent part of designing, developing and deploying any website or product.
Next up in this series: how to IPO your company with a fast-loading website.