How to improve the speed of your website
Speed is King. Google knows that. Amazon does, too. What holds true to those big corporations, also affects smaller sites, like mine and yours. Visitors will click away when you’re site isn’t snappy, especially when they’re in a hurry (like browsing the web on their smartphones, where connection speeds are still rather low).
What can you do to make your site fast? A lot, as it turns out, even with hardly touching any code. Check out those six tips:
- Make use of browser preloaders
Every modern web browser has one. Google reports that the preloader in Chrome makes websites load 20% faster on average.
What you need to do to get the benefit? Just don’t get fancy! Preloaders work by scanning the HTML returned by the server, looking for JS, CSS and image files it can intelligently pre-fetch. But it can only do that if the resources are contained in the HTML. So forget those fancy script loaders, just use regular <style> and <script> tags in your markup.
- Use the async attribute, where fit
The async attribute tells the browser to continue parsing the page, loading the script in the background and executing it as soon as it’s available. Sounds great, right?
Well, there’s a drawback: you can no longer guarantee the order in which scripts are executed. So if you have three scripts A, B, and C, where C depends on B which depends on A, and you load the with the async attribute, you’re lost.
You can still make use of the async feature for self-contained scripts, like web tracking (Google Analytics) or other 3rd party integrations.
- Inline small CSS files
I recently integrated Mapbox into one of my projects (Mapbox is an alternative to Google Maps). I also needed several plugins, each providing its own CSS files for styling. Bluntly, I just copied the <style>tags over to my site and deployed it. Coming back to it a few days later, I discovered that those stylesheets are only a few lines each and they never change. I inserted them into my main site’s CSS and thus saved multiple HTTP requests!
- Use a CDN
A CDN (short for Content Delivery Network) is a service that sits between your users and your webserver. On each request from your user’s browser, it looks inside its cache to check if it can serve the resource requested.
If the resource is found within the cache, it’s returned to the browser. That significantly faster than a request to your backend, cause CDNs have lots and lots of locations around the globe, where you visitors are routed to, reducing latency.
If the resource couldn’t be found, it’s requested from your server and stored inside the cache, so that the next request is faster.
Note that not only latency is improved, but you can also cache resources which take a significant amount of processing time (DB queries or other costly operations).
CDNs are great for things like commonly used JS files (jQuery and other libraries are served via CDNs, so you can benefit from other people linking to it in their pages), but it’s also quite easy to setup for your own website. Services like Fastly or Amazon Cloudfront make it both easy and quite cheap.
- Don’t shard your assets across more than two hosts
Browsers have a limit on the number of resources they will request from a single hostname (like www.mysite.com) at a time. To fix this, you can setup additional DNS records for your site and name them assets1.mysite.com, assets2.mysite.com, and assets3.mysite.com and link your images, CSS and JS files to one of those hostnames randomly (that process is called sharding). You can go crazy with the number of shards, but you should be careful. Turns out that even big sites like Etsy.com got this wrong in the beginning, but it’s now a great read for the rest of us. Rule of thumb: start with two shards and see how it performs.
Even if you’re using a CDN, the best way how to save time and thus requests on your site is to not do any requests at all. The only real way how to do this is to have things ready in the browser’s cache. How do things get there? Set the HTTP Cache-Control and Expires headers correctly. What works well for me is setting Cache-Control to Public and Expires to the furthest date in the future, possible (that’s one year from now). Of course, you can only do that if you use some sort of asset digests (like Rails offers them), so you can easily “invalidate” new resources by changing the filename. Check your framework’s documentation on how to do that!