Why your website should be fast, and how to do it

Let me start off by saying, I know you have read probably hundreds of articles on how to optimise your site for speed. But whereas most just repeat the same thing, hopefully here will be some genuinely insightful tips that will help you get your sites up to speed.

Why is speed important?

Multiple reasons – but perhaps the most important is your users. We’ve all been there, sitting waiting for a site to load until we give up and take our interest elsewhere. If you run a business, a slow website could therefore be costing you significant business. Furthermore, search engines such as Google use speed as one of their metrics that affect ranking, so if being top of Google is important to you then having a fast website is critical.

Work closely with your designer

Let’s start from the beginning – how fast your websites can be is intrinsically linked to the design. Certain designs lend themselves better to speed, so working with your designer from the off to create an idea that has the potential to be fast is critical. How are they using images? How much scripting will be required to make the design work? You should be thinking about speed right from the beginning, and so should your designer.

Learn how to build your projects

So you’re uploading the bower components folder to your hosting? Uh-oh – this is already a sign that you’re not really quite using your tools and frameworks correctly. The whole point of a task runner such as Grunt is that you can manage your front-end more effectively. Part of the way you can do this is by having separate tasks for different build states.

If you use Foundation, for example, the default Gruntfile does not compile your JS. It won’t even autoprefix your SASS. So to get your site working, you’re uploading a bower components folder of which 95% of the files you’re not using. Either that, or your manually dragging the JS files you need into your JS folder. Neither are a great way to work, and neither will help site performance.

Utilising Concat and Uglify, you can create a build task in your Gruntfile which compiles your JS into one small minified file. This will reduce http requests for your site as well as page size, which should significantly speed up page load times.

Stop loading what you’re not using

It sounds obvious, but so many developers (including on occasion myself) make the mistake of loading various scripts they’re not actually using. At the end of every project when you’re signed off and ready to upload, run through your project and completely ditch everything you’re not using.

For example, if you’re not actually using Modernizr in any capacity, remove it. And with Foundation, you can selectively load only the JS components you need to. As long as you maintain your project on your dev box, you can always add back in what you need if you need to in the future.

Optimise your images

It’s a bit of a sweeping statement, but you shouldn’t be loading any images that are more than a couple hundred or so kb in size. There are dozens of image optimizer tools out there, which are worth a look if you need better performance than Photoshop’s Save for Web.

What to aim for?

Exactly what should you aim for? There isn’t really an answer to this because it depends on the project. However, as a general rule I have for myself, I always aim to get every page to load in about 1 second with a page size of no more than 1mb.There are of course the occasional exceptions, but it’s a good rule to aim for