All about website loading speeds

Last month we had an enquiry from a client asking if we could look into some of their page loading times on a site we had built. We did and found the numbers showed certain areas of the site were being delivered noticeably slower then others; as a result we were asked what we could do, but more importantly the question was posed internally, what's our responsibility when it comes to loading times in a site development? And a good question it is too. The simple answer in my opinion is that we are to deliver a swift yet reasonable loading time with any site development; When developing a site we do so with best practice to ensure the quickest flow of data possible in loading and rendering resources. This includes keeping files served to the user as low as sensible through the use of sprite sheets for images, optimised images, sensible CSS structures and combined Javascript files to name a few. These practices are ones we're always improving on with each new build. Even with best practices in place though there is still more we can do to improve loading times, so why not just do it from day one? Beyond good practice There are many factors within our control that go into site loading time; let's say we perceive the load time to be when the the stop button changes in to the refresh button, this is the browsers way of saying it's done. To keep things basic we have two things to consider, the browser needs to get all the files and then render them and these are the areas we can optimise. The most significant boosts I've found to load speed is with file delivery and so this is what I'm going to focus on in the following discussion. We use Wordpress for a lot of our site builds, it's a great, free and widely trusted CMS with great extendability but this comes at a cost. The way it is built to allow for plugins and user extension means it loads Javascript and CSS in it's own way to ensure plugins work smoothly and to cut down on conflicting scripts and duplicated information. If we were to optimise all this it would require to be a lot more hands on then is a reasonable request for a development budge; as we choose Wordpress because it's cost effective for the clients, to then have to optimise beyond the capabilities would require a lot more time and wouldn't necessarily provide a relevant loading time improvement for the extended effort and consequent cost. As an example, if we look at the default theme for Wordpress you have six Javascript files and two CSS files, this is about as clean as it will get! This you could optimise the file download time for with a fairly simple method, at least simple if you weren't using a CMS. To do this would require would taking the file contents, compressing (or minifying) them and combining them into a single file (per script type). The problem occurs now that you would then have to write into your Wordpress theme an override to stop it automatically trying to get all the individual files. This means the whole process takes a lot of analysis and work to achieve what may only be around 50ms loading time, not at all a noticeable difference to the average site visitor. Now consider with plugins sites can easily have 14+ Javascript files and 12+ CSS files, you can optimise these but as most are for plugins the chances are they'll be overwritten on update or worse, you'll have to manually update your optimised files to complete updates and avoid site breakages. We're sure clients would rather suffer the minor page loading time to save on hands on maintenance! Third party services are also an issue. The client we were looking into loading times for uses a third party live chat support which unfortunately requires files to be taken from their server which seems to be poorly configured server. Disabling this service would save literally seconds of page loading time (though much of the visible page and interactions loaded long before) but the ability to optimise this time is beyond our control. The service is functionally complete for the clients and the browsing experience isn't hugely effected but the harsh truth is the only way to optimise is to find a better optimised service provider for it. Conclusion When we get asked "How much is a website?" we like to use the analogy "How much is a car? You could have a Ferrari or a Micra". This analogy can be extended to loading times. Chances are you have a reasonable budget for you car, it runs without breaking down, is fuel efficient and gets you where you want to go in reasonable time. But you want to go faster and who doesn't? So what can you do? You can't take the car back to the garage and say "this car isn't fast enough" but you still have the option to get it tuned up. You can strip excess weight, add ECUs, bore cylinders, get better tyres, etc. All improvements that help to varying degrees but nothing that you'd expect out of the shop unless you'd asked and paid for it. So while we do what we can to make sure each site we build loads promptly, it's not as simple as of the shelf scripts and settings switches. As is the way we build sites for SEO we follow good practice and do as much as is feasible for each development; going beyond this takes time and the budgeted time is often better spent elsewhere. After all, what's a half second compared to a better conversion rate?