探客时代
Front-End Performance Checklist
The only Front-End Performance Checklist that runs faster than the others
README
Front-End Performance Checklist
🎮 The only Front-End Performance Checklist that runs faster than the others.
One simple rule: "Design and code with performance in mind"
How To Use • Contributing • Product Hunt
Other Checklists:
🗂 Front-End Checklist • 💎 Front-End Design Checklist
Introduction
Performance is a huge subject, but it's not always a "back-end" or an "admin" subject: it's a Front-End responsibility too. The Front-End Performance Checklist is an exhaustive list of elements you should check or at least be aware of, as a Front-End developer and apply to your project (personal and professional).
How to use?
For each rule, you will have a paragraph explaining why this rule is important and how you can fix it. For more deep information, you should find links that will point to 🛠 tools, 📖 articles or 📹 medias that can complete the checklist.
All items in the Front-End Performance Checklist are essentials to achieve the highest performance score but you would find an indicator to help you to eventually prioritised some rules amount others. There are 3 levels of priority:
![Low][low] means that the item has a low priority.
![Medium][medium] means that the item has a medium priority. You shouldn't avoid tackling that item.
![High][high] means that the item has a high priority. You can't avoid following that rule and implement the corrections recommended.
Performance tools
List of the tools you can use to test or monitor your website or application:
🛠 ☆ Dareboost: Website Speed Test and Website Analysis (use the coupon WPCDD20 for -20%)
🛠 Web.dev
🛠 Calibre
References
📖 [Front-End Performance Checklist 2021 [PDF, Apple Pages, MS Word]](https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/)
📖 [Designing for Performance Weighing Aesthetics and Speed - By Lara Callender Hogan [eBook, Print]](http://designingforperformance.com/index.html)
HTML
![html]
- [ ] Minified HTML: ![medium] The HTML code is minified, comments, white spaces and new lines are removed from production files.
Why:
> Removing all unnecessary spaces, comments and attributes will reduce the size of your HTML and speed up your site's page load times and obviously lighten the download for your user.
How:
> Most of the frameworks have plugins to facilitate the minification of the webpages. You can use a bunch of NPM modules that can do the job for you automatically.
- [ ] Place CSS tags always before JavaScript tags: ![high] Ensure that your CSS is always loaded before having JavaScript code.
- ``` html
- <script src="jquery.js"></script>
- <script src="foo.js"></script>
- <link rel="stylesheet" href="foo.css"/>
- <link rel="stylesheet" href="foo.css"/>
- <script src="jquery.js"></script>
- <script src="foo.js"></script>
- ```
Why:
> Having your CSS tags before any JavaScript enables better, parallel download which speed up browser rendering time.
How:
> ⁃ Ensure that `` and `` in a single line (minified if possible). Why:
> Inlining critical CSS help to speed up the rendering of the web pages reducing the number of requests to the server.
How:
> Generate the CSS critical with online tools or using a plugin like the one that Addy Osmani developed.
🛠 Critical by Addy Osmani on GitHub automates this.
📖 [Reduce the size of the above-the-fold content
](https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent)
Why:
> One of the first reason it's because it's a good practice to separate content from design. It also helps you have a more maintainable code and keep your site accessible. But regarding performance, it's simply because it decreases the file-size of your HTML pages and the load time.
How:
> Always use external stylesheets or embed CSS in your `` (and follow the others CSS performance rules)- [ ] Analyse stylesheets complexity: ![high] Analyzing your stylesheets can help you to flag issues, redundancies and duplicate CSS selectors.
Why:
> Sometimes you may have redundancies or validation errors in your CSS, analysing your CSS files and removed these complexities can help you to speed up your CSS files (because your browser will read them faster)
How:
> Your CSS should be organized, using a CSS preprocessor can help you with that. Some online tools listed below can also help you analysing and correct your code.
🛠 Project Wallace is like CSS Stats but stores stats over time so you can track your changes
Fonts
![fonts]
- [ ] Webfont formats: ![medium] You are using WOFF2 on your web project or application.
Why:
> According to Google, the WOFF 2.0 Web Font compression format offers 30% average gain over WOFF 1.0. It's then good to use WOFF 2.0, WOFF 1.0 as a fallback and TTF.
How:
> Check before buying your new font that the provider gives you the WOFF2 format. If you are using a free font, you can always use Font Squirrel to generate all the formats you need.
- [ ] Use preconnect to load your fonts faster: ![medium]
- ``` html
- <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
- ```
Why:
> When you arrived on a website, your device needs to find out where your site lives and which server it needs to connect with. Your browser had to contact a DNS server and wait for the lookup complete before fetching the resource (fonts, CSS files...). Prefetches and preconnects allow the browser to lookup the DNS information and start establishing a TCP connection to the server hosting the font file. This provides a performance boost because by the time the browser gets around to parsing the css file with the font information and discovering it needs to request a font file from the server, it will already have pre-resolved the DNS information and have an open connection to the server ready in its connection pool.
How:
> ⁃ Before prefetching your webfonts, use webpagetest to evaluate your website ⁃ Look for teal colored DNS lookups and note the host that are being requested
⁃ Prefetch your webfonts in your `` and add eventually these hostnames that you should prefetch too
- [ ] Webfont size: ![medium] Webfont sizes don't exceed 300kb (all variants included)
- [ ] Prevent Flash or Invisible Text: ![medium] Avoid transparent text until the Webfont is loaded
📖 [font-display for the Masses](https://css-tricks.com/font-display-masses/)
Images
![images]
[ ] Images optimization: ![high] Your images are optimized, compressed without direct impact to the end user.
Why:
> Optimized images load faster in your browser and consume less data.
How:
> ⁃ Try using CSS3 effects when it's possible (instead of a small image) ⁃ When it's possible, use fonts instead of text encoded in your images
⁃ Use SVG
⁃ Use a tool and specify a level compression under 85.
[ ] Images format: ![high] Choose your image format appropriately.
Why:
> To ensure that your images don't slow your website, choose the format that will correspond to your image. If it's a photo, JPEG is most of the time more appropriate than PNG or GIF. But don't forget to look a the nex-gen formats which can reduce the size of your files. Each image format has pros and cons, it's important to know these to make the best choice possible.
How:
> ⁃ Use [Lighthouse](https://developers.google.com/web/tools/lighthouse/) to identify which images can eventually use **next-gen formats** (like JPEG 2000m JPEG XR or WebP) ⁃ Compare different formats, sometimes using PNG8 is better than PNG16, sometimes it's not.
- [ ] Use vector image vs raster/bitmap: ![medium] Prefer using vector image rather than bitmap images (when possible).
Why:
> Vector images (SVG) tend to be smaller than images and SVG's are responsive and scale perfectly. These images can be animated and modified by CSS.
Why:
> If height and width are set, the space required for the image is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the image, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading (while the images load).
[ ] Avoid using Base64 images: ![medium] You could eventually convert tiny images to base64 but it's actually not the best practice.
[ ] Lazy loading: ![medium] Offscreen images are loaded lazily (A noscript fallback is always provided).
Why:
> It will improve the response time of the current page and then avoid loading unnecessary images that the user may not need.
How:
> ⁃ Use [Lighthouse](https://developers.google.com/web/tools/lighthouse/) to identify how many **images are offscreen**. ⁃ Use a JavaScript plugin like the following to lazyload your images. Make sure you target offscreen images only.
⁃ Also make sure to lazyload alternative images shown at mouseover or upon other user actions.
[ ] Responsive images: ![medium] Ensure to serve images that are close to your display size.
Why:
> Small devices don't need images bigger than their viewport. It's recommended to have multiple versions of one image on different sizes.
How:
> ⁃ Create different image sizes for the devices you want to target. ⁃ Use srcset and picture to deliver multiple variants of each image.
JavaScript
![javascript]
- [ ] JS Minification: ![high] All JavaScript files are minified, comments, white spaces and new lines are removed from production files (still valid if using HTTP/2).
Why:
> Removing all unnecessary spaces, comments and break will reduce the size of your JavaScript files and speed up your site's page load times and obviously lighten the download for your user.
How:
> ⁃ Use the tools suggested below to minify your files automatically before or during your build or your deployment.
Why:
> Placing JavaScript embedded code directly in your `` can slow down your page because it loads while the DOM is being built. The best option is to use external files with `async` or `defer` to avoid blocking the DOM. Another option is to place some scripts inside your ``. Most of the time analytics code or small script that need to load before the DOM gets to main processing. How:
> Ensure that all your files are loaded using `async` or `defer` and decide wisely the code that you will need to inject in your ``.[ ] Non-blocking JavaScript: ![high] JavaScript files are loaded asynchronously using async or deferred using defer attribute.
- ``` html
- <script defer src="foo.js"></script>
- <script async src="foo.js"></script>
- ```
Why:
> JavaScript blocks the normal parsing of the HTML document, so when the parser reaches a `