The other day, I realized that web performance is an enormous topic covering so very much — from minimizing assets to using certain file formats, it can be an awful lot to keep in mind while building a website. It’s certainly far too much for me to remember!
So I made a web performance checklist. It’s a Notion doc that I can fork and use to mark completed items whenever I start a new project. It also contains a bunch of links for references.

This doc is still a work in progress. Any recommendations or links?Feel free to suggest something in the comments below!
Awesome list! thank you for sharing! Just spotted: perhaps you meant “transform” instead of “position” in “avoid animating styles other than:” ?
Web performance is such a complex topic these days with so many aspects to balance that it is an interesting challenge to cover it in 30-something bullet points.
If there was just one thing to add, however, I’d suggest to include HTML performance optimization and the removal of optional markup for production (optional tags, quotes that aren’t needed, likewise no attribute-value pairs that refer to defaults). I have at some point provided an overview, however there may be other documents that could also add the necessary detail.
Since this is about css, would you be adding anything about scalability or alternative images for different screen sizes?
Thanks for sharing the Web performance checklist. Probably, it’s a much essential checklist that any developer needs to check on time-time. Even by 1 second if you are able to reduce loading time. It has a huge effect on the visitor’s first impression.
Uhh, looks good! If possible i would switch to the openlitespeed webserver. With litespeed nearly everything of the things above is included.
Remove un-used CSS. Its something that alwayw happens. We add new components or remove some old ones, we switch something but we dont touch the CSS. After some time the CSS files start gaining weight and that weight gets translated in slow loading times.
Also use webm videos if possible (dont actually know if they are completely supported from modern browsers).
Put CSS and JS linking/imports in the correct place. Dont mix them up or you might end up having some strange layout show up.
It’s a fantastic checklist, I’m working on it too!
Another tool that I like for testing is https://tools.pingdom.com/
Each programming language has best practices also in terms of optimization, for example for CSS we have to use efficient selectors, in PHP and SQL we have to do efficient database queries and in all languages we must avoid redundancies. 3 interesting resources below:
https://10up.github.io/Engineering-Best-Practices/css/#performance
https://10up.github.io/Engineering-Best-Practices/javascript/#performance
https://10up.github.io/Engineering-Best-Practices/php/#performance
Concatenate assets is still a good practice for improving PageSpeed scoring but I don’t know how useful it actually is with HTTP / 2 and parallel requests. For example it’s not good if the only .css and .js file is in the , the best would be to put these files in the footer and only the critical css in the head.
Obviously the best thing would be to load in each page only the css and the javascript used in that page, obvious but not so simple when we working with CMS like wordpress and a lot of plugins! In WordPress for example there are specific functions and conditions to register/deregister style and scripts in different pages, archives or posts, only where we need them.
I know that checklist is trying to be a one-size-fits all, and I know it’s maybe contraversial, but if I’m using HTTP/2 I might not rush reduce all my HTTP calls and concatenate all my files. That can result in large single files that contain the CSS/JS for components that aren’t used on my current page. Since HTTP/2 multiplexing makes better use of the limited number of connections, it may be faster to only to the multiple individual scripts/files actually needed for your page.
Worth testing, and it very much depends on how many components in total your system uses vs how many are needed for any one page. I have seen a speed benefit to this on very large systems, and I’ve seen smaller sites that were quicker with concatenated CSS/JS files.
I would also add the list “Asynchronous loading of JavaScript” (which isn’t render blocking), and use the ‘Preconnect’ resource hint for opening connections to other domains. Many of our customers us GTM to add a gazillion analytics scripts after page-load, and being able to have the TLS connection ready before GTM requests the scripts can save hundreds of milliseconds.
On a related note, I can’t agree with “Avoid multiple analytics scripts” strongly enough! Many of our customers performance issues can be traced back to GTM loading a gazillion analytics scripts…