When I optimise a website for speed, I usually focus on the front end first. Note there are many other things that could affect speed, such as server location, database queries and so on. This article covers mostly the front end stuff.
Lazyload all the things
Media, such as images, are the biggest burden to optimising a website for speed. It goes without saying that serving up responsive images with a picture element helps a lot. But also, not loading images until they’re actually in the viewport (known as lazyloading) will help a website run more smoothly. The concept of lazy loading is slowly being implemented directly via browsers. But for now we usually have to rely on some javascript for a more universal solution.
One method I’ve used is to have javascript replace src urls within an image element. So on page load, it’ll only request thumbnail sized images, until the image is within the viewport. Then it will swap them out for the actual image sizes. So the markup looks something like:
<picture class="js-lazyload">
<source data-srcset="//placehold.it/1200x300" srcset="
//placehold.it/
120x30" media="(min-width: 36em)" /> <img data-src="
//placehold.it/
480x480" src="//placehold.it/
48x48"></picture>
We simply drop the last digit from thumbnail sizes, to keep the aspect ratio correct.
Image formats
The format of your image is also important, depending on the type of image you want to serve. SVGs are well supported these days, so I try to use them where I can. Mostly for flat coloured images such as icons etc. Failing that, pngs can be compressed quite well, especially if you don’t need any transparency on them. Jpegs are obviously reserved for just photos.
The new kid on the block is webp, though at time of writing, it’s not quite as well browser supported. I’ve not really used this format much. My only concern is how to edit these files. You need to run a convertor script on your chosen image(s) to get your webp format, which seems a bit of a pain to me when I’m so used to editing images in something like photoshop.
There are also other formats on the horizon, so the compression techniques will surely get better over time.
Obviously when it comes to CMS websites for clients, using things like webp isn’t practical. Also, sometimes there’s the dreaded habit of uploading really large images. Though not ideal, having something to lazy load your images can mitigate the impact of a clients huge 9000px jpeg upload.
Third party dependencies
When you start to include third party scripts, such as youtube videos, chatboxes, google maps and so on, you’ll find that it adds up in load time. Unfortunately, you can’t always get around scripts that are loaded externally. One way around this is to follow the same lazy load approach. I’ve seen this applied to google maps in particular, which would load the map and it’s scripts only when it’s in the viewport.
Another method I’ve used for things like video content, is to have a clickable screenshot for the video rather than the iframe embed itself. Clicking it will open the video embed via a pop up lightbox. This method seems obvious, but is universal when you want to load things only specifically when you need them.
Utilise browser capabilities
There are a few options to using the capabilities of your browser to cache and serve content. One such method is the service worker. Without going into too much detail, this caching method will allow you to serve a website via cache, even when you’re offline. There are only two caveats to this; the website needs to be first loaded normally (to allow it to cache), and any site using service worker need to be SSL enabled. Of course, this capability makes it much easier to turn a basic webpage into something more like a web app for mobile users. More info on this topic can be found at: https://web.dev/progressive-web-apps/
Don’t forget the server
I know that this article mostly covers front end page load speed, but it’s still worth mentioning some of the optimisations that can work for the server. Serving content via gzip compression certainly has it’s benefits. Also, if you have a site with a database connection, you can minimise calls to it via some server caching to generate static html pages. Though there’s also a way to do this client side…
About Static HTML
Of all the methods used for building websites, plain static HTML has remained the fastest way of loading pages. But how can this still be relevant in today’s workflow? Surely maintenance of potentially hundreds of pages is a nightmare. Dreamweaver isn’t really a thing anymore, right? Not really, with the rise of static site generators. As you build, edit and so on, the process of generating your pages is automated. Using a static approach bypasses all the overhead you need for a database, CMS and so on. This is known as the jamstack, and has the potential to be one of the greatest tools to optimise a website for speed.
Taking cues from Google
A controversial topic for some, the google AMP platform uses some techniques that can be useful for page load speed. One being unable to allow developer written javascript, other than that which is provided by the platform. This is a big one, because obviously you can’t use jquery, third party plugins and so on. If you’re able to achieve your development goals with minimal use of javascript, you might find you’ll lose some of the overhead that these scripts can take up with page load. There’s a lot more you can do with CSS nowadays, obviously.
Another interesting feature is that you can’t reference external CSS, it needs to be inline. Whilst it’s not always practical to do this on all websites, we can at least take some cues on having at least some inline CSS ( known as critical CSS ) to give the perception of a faster loading site. These styles normally include the bare minimum to mitigate the flash of unstyled fonts, layout of the page, menus etc.
Checking your results
When I’m done with my optimisations, my go-to place to test for speed is at gtmetrix.com. It’s a handy all on one free tool to optimise a website for speed. It uses page insights as well as yslow for it’s testing, so the results it gives you is quite comprehensive. This is one of my essential web development tools I find myself using a lot.