This article is a continuation of my 3 Tips on Preserving Website Speed article.
Let's assume you did a project that was not optimized enough for your users. You then optimized it to match some criteria or performance budgets. Repeating this behavior is time-consuming — it is cheaper and more user-friendly to never introduce slowdowns in the first place, rather than fixing them later. Let's make good practices a habit.
So here are my tips for your next project.
1. Do retrospection
This scrum ritual is one of the most important things you can do after a project, no matter if everything went well or something went wrong. Sit down and think about what you accomplished. You have to ask yourself two questions: What went well? What could be improved?
- Read more on retrospection from a Scrum perspective
In the context of performance, you want to remember and consciously decide on some new habits, automation, notifications, processes that will help you track everything that needs to be tracked for your project to not fall into the red performance scores in Lighthouse again.
Some of my conclusions from recent years:
- Review all PRs to check if someone is not adding big images (read my article on image optimization).
- Update npm dependencies once a month to not get too far behind.
- Set up Lighthouse-CI and Slack notifications to catch performance regressions (read my article on monitoring your website performance).
- Write a proper readme (or even better, tool) for yourself on how to optimize fonts (read my article on font optimization).
- Do more due diligence before adding dependencies.
2. Keep researching
Always keep researching and stay up to date in relevant areas.
Before a project, research things you use regularly (see a boilerplate in the next point) to improve your toolkit. The better your foundations and the more you know about what's available, the more educated decisions you can make when choosing your technology stack. This is similar to the research after the project, but this one is focused on the asset pipeline and things you do before the project starts. After all, you want to start quickly and verify your previous decisions, you don't aim here to revolutionize your approach just before starting a new project — the revolution will come with the next project after you experiment with those new tools.
During the project, research the best tools for the job. For example, maybe moment.js is not the best choice in 2020 for a datetime library (hint: take a look at date-fns, luxor). You can make a lot of good decisions by choosing the best tool for the job. Check if there is a lighter version of select2 or if Choices can satisfy the requirements in a smaller footprint.
After the project, research broader topics to develop your universal knowledge, like software architecture, design patterns, new paradigms (or old ones, but implemented in nicer ways, that might make them more appropriate now than ever). This is the time where you can learn SVG, a little bit more on accessibility, end2end testing in TestCafe, and that maybe this new asset bundler esbuild is good for simple projects (hint: it is). Grow as a developer and broaden your horizons. It will pay off in all future projects. I learn those things after projects because projects are usually times of intense coding, and I'm tired after that. This kind of research always brings me peace and eases the tension.
3. Have an (good) asset pipeline
No matter what you think about modern JavaScript tooling, it helps a lot when it comes to performance. I consider the following features must-haves for any asset pipeline:
- JS dynamic import (code splitting) - allows you to load critical and non-critical code efficiently
- JS Tree-shaking - makes dependencies much smaller when imported using
import - CSS, JS minification
- Plugin architecture - in case you need to customize it further, add some processors
- Speed - especially dev builds have to be fast because it is not fun to wait while developing
To save time you should have a boilerplate that you can use to kick off every new project which encapsulates all the shared features you use in your projects. In my case, it is Webpack + TailwindCSS (see source code for webpack-tailwindcss-purgecss). As time goes by, you might modify it to adapt it to the new reality. This means that every new project you start will have a better default configuration. If you can choose between using a new great tool or the tool that you know well, I would personally choose to go with the one I know well and experiment with the new tool on the side because making a mistake in a client project might have bad technical and ethical consequences.
Having this foundation that you fall back onto is extremely important, freeing, and allows you to progress with the quality of your toolkit. You make some decisions once and forget about them for a long time, so your mind is free to solve another issue that may arise in that particular project.
I hope these tips will help you make your process more refined and predictable when it comes to starting, developing, and maintaining fast websites. Key takeaways: Develop good habits and slow down when a decision is important.
Read more
If you are interested in more performance oriented content, follow me and I promise to deliver original, or at least effective methods of improving your website.
Top comments (0)