When Robert Stephenson’s Rocket won the Rainhill Trials in 1829, few people said the concept was great but that it just needed slowing down a bit. Just over a century later, steam trains had broken the 100mph barrier, and now 140mph is normal.
It’s the same with the online experience, too. Some of us might fondly remember the days of 56 kbit/s modems, but would you go back to those days? If you really want to, you could throttle your connection, but be warned – the internet is a lot more data-hungry than it was back then. As the internet has grown in stature and capacity, many developers have instinctively tried to push it to its limits.
It’s normal nowadays to launch a website that has auto-playing video on the home page, something that would have been unthinkable ten years ago. And the stuff that’s going on in the background – various scripts, analytics data gathering, sourcing code from other websites – all add up to web pages that eat bandwidth for breakfast.
This is all fine, as long as it’s done with speed in mind. There’s always going to be a compromise with a website. On the one hand you have how it looks, what the user experience is like, how much data you gather, and what technology is running in the background to make it perform. That adds up to how attractive and useful it is.
But on the other hand, it has to be acknowledged that all these tricks will have a cumulative effect on performance, whether that’s the amount of bandwidth it consumes or the processing power that’s demanded, both of the user’s device and any server-side processes that are taking place. A site that runs well on your own desktop PC might perform very differently on a phone using a data connection.
So when you’re building a website, it’s important to consider not just what’s possible, but what’s necessary. If you’re big on background data and functionality, it might mean you have to scale back your ambitions when it comes to visual bells and whistles.
That’s not always a bad thing, of course – brilliant things can happen when you’re forced into finding a solution to a problem based on limitations. HTML5 can do some magnificent visual things with a pretty small amount of data and processing, so think about how it can help you design interesting pages that don’t slow everything down. In a nutshell, you’re looking to minimise the resources your site consumes at every step.
Users hitting the back button is bad enough for the success of your site, but there’s another, perhaps more compelling, reason why you need to keep your site small and efficient. It’s pretty well known nowadays that site speed is a ranking factor with Google. If you’re the kind of business that is trying to get a foothold in a busy marketplace, or if you rely on a constant stream of new customers, your search rank is vital to your bottom line. A single ranking drop could send customers to your competitors, and if you drop to page 2, you’ll really notice it.
Achieving optimal site speed is a blend of back-end and front-end development, and it should be an ongoing process. It’s not always about squeezing the most performance out of the available technology – more often, it’s a case of leaving plenty in reserve so your site is always firing on all cylinders. Your customers will appreciate it, and so will your business.
