As web technologies evolve and an ever-increasing number of tools, frameworks, and libraries become available, so too do many bloated and unnecessarily burdensome sites.
While these things are essential and aren’t inherently wrong, their mismanagement, overuse, and poor implementation is where the problems start to arise.
We can pick any library, framework, or theme from a dizzying number of sources and throw it into a project with little thought for the maintenance, optimisation, security, accessibility, or SEO implications of projects.
We have all, at one time or another, been guilty of indulging in this technical form of “buy now, pay later” mentality. I think, therefore, that it is time we took a step back.
Think critically and audit your sites
With that in mind, here are suggestions for reducing your site’s technical debt and improving the performance, usability, and SEO aspects of your site.
Before making any changes, I’d recommend starting with a Lighthouse audit for an overview of the areas that you need to adjust.
Its detailed suggestions are great for highlighting quick wins.
What’s more, it provides extra information and links to documentation, should you be unsure about the improvements it advises.
You can find the audit panel inside the Google dev tools and here’s how it looks:
On a personal note, I also find it quite satisfying seeing the green 100s appear across the board!
Alongside the audit, check the network tab of the dev tools and take a look into the timings for particular areas of your site.
The Time to First Byte (TTFB) is useful for giving you an idea of how heavy it is. Ideally, it should be no more than 200 milliseconds.
Once you’ve found the trouble spots for your site, you can begin to remove the excess, tidy things up, and optimise.
As there could be a multitude of issues, we’ll break them down into smaller pieces to cover as many bases as possible.
This list isn’t exhaustive, and the strategies employed will vary from project to project.
Finally, it’s worth noting that you can use as many or as few of these techniques as you like and in any combination, so experiment to see what works best for you and your scenario!
Thinking about HTML
As the browser receives your site, it will tokenise your HTML and begin to construct the Document Object Model (DOM).
This is an intense process; it is crucial that you aren’t using too many elements on a page.
A good rule of thumb is to get by with as few tags as possible.
Google recommends that your DOM on any given page has:
- A maximum of 1,500 nodes
- A maximum depth of 32 nodes
- No parent node with more than 60 child nodes
Ensure that your markup doesn’t contain any unused or empty elements. This is because the browser has to read the HTML, tokenise the element, add it to the DOM, possibly style it with CSS, and then render it.
A pet peeve of mine is the use of empty nodes as ‘spacers’ — this is unnecessary, as a CSS spacer class with the relevant margin properties can be used, negating the need for wasting resources on empty tags.
Tag relevance is also essential here. Using the correct semantic HTML is good practice and can also improve your site’s overall accessibility.
HTML5 provides a myriad of relevant, accessible tags, so don’t develop div-itus.
Thinking about CSS
Once the browser has found your stylesheet link in the HTML, it will go off and fetch the file.
It is during the time that render-blocking occurs — this means the rest of your site’s loading will be put on hold while the browser deals with the CSS.
With this in mind, it is vital that your CSS is written correctly and minified.
Unfortunately, clean, structured CSS seems to get overlooked quite frequently, so I’d highly recommend taking the time to address this issue.
Ensure your styles are relevant, appropriate and not duplicated. Additionally, create classes to handle styling that is used in multiple places and keep your code DRY.
Split your styles out into separate files and only use what it is that you need.
Element selectors slow things down unnecessarily as they require a browser to look for all of the correct elements in the CSS Object Model (CSSOM) before it can apply the styles.
The problem becomes even more pronounced if you target elements inside other elements as the browser will have to look for your target and then walk back up the CSSOM tree to check that it exists inside of the other element.
Minification is the process of removing certain aspects of code that can make the file unnecessarily large. This can include characters such as semicolons, spacing and new lines, while keeping the original functionality of the code intact.
Thankfully, many strategies can be employed to deal with this.
We can’t go into detail on each one here, so I’ll provide a brief overview.
Is it necessary?
Do you need to import an entire library/package/module to do something as trivial as say, animating a single element on one page? This could quite easily be done with vanilla JS/CSS.
In fact, most things can be done in vanilla JS and compilers such as BabelJs allow us to support older browsers, using newer features.
You can also use tools, such as BundlePhobia, to give you an idea of how big an npm package is before you decide if you want to use it or not — it can make for sobering reading!
Is it clean and have you implemented DRY?
Much like the CSS tips above, having correctly written and tidy JavaSript can do a world of good on its own. Remove unused code, unnecessary comments, and tidy up where possible.
Try to implement the Keep it Simple, Stupid (KISS) principle where possible.
Is it bundled?
Is it minified?
Webpack has the minimise option that will help in reducing the overall size of your bundle. This is set to true by default when running in production mode and works in the same way as discussed in the CSS tips.
A look into images
Make sure your images are optimised. Compress them to remove unnecessary data from the file and size them correctly. Also, use tools to help re-size them for varying screen sizes so that you’re not loading in unnecessarily large images.
There is a myriad of image optimisation tools available. TinyJPG, for example, is a personal favourite for image compression.
It is a manual tool, but other tools do exist for automating the process should you need them.
If you do use any icons, make sure they’re SVGs and added to a sprite sheet for even more performance improvements.
While it is easy to get sucked into the vortex of excess, it’s never too late to make a difference. With careful planning, you can even avoid these issues to begin with — they do say prevention is better than the cure.
After addressing the above, you’re likely to notice some performance gains across your site, and these refinements will all aid in improving your site’s user experience and SEO performance.