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
- HTML
- CSS
- Fonts
- Images
- JavaScript
- Server (in progress)
- JS Frameworks (in progress)
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 exhausted 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).
For each rule, you will have a paragraph explaining why this rule is importante 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 is 3 levels of priority / impact:
means that the item has a low priority and impact on your project.
means that the item has a medium priority and impact on your project. You shouldn't avoid tackling that item.
means that the item has a high priority and impact on your project. You can't avoid following that rules and do the corrections appropriates.
List of the tools you can use to test or monitor your website or application:
- 🛠 WebPagetest - Website Performance and Optimization Test
- 🛠 ☆ Dareboost: Website Speed Test and Website Analysis (use the coupon WPCDD20 for -20%)
- 🛠 GTmetrix | Website Speed and Performance Optimization
- 🛠 PageSpeed Insights
- 📖 Pagespeed - The tool and optimization guide
- 📖 Make the Web Faster | Google Developers
- 📖 Sitespeed.io - Welcome to the wonderful world of Web Performance
- 📖 The Cost Of JavaScript - YouTube
- 📖 Get Started With Analyzing Runtime Performance | Google Developers
- 📖 State of the Web | 2018_01_01
- 📖 Page Weight Doesn't Matter
-
Minified HTML:
Why:
Removing all unnecessary spaces, comments and break 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.
-
Remove unnecessary comments:
Why:
Comments are not really useful for the user then should be removed from production files. One case where you want to keep comments could be if you need to keep the origin for a library.
How:
⁃ Most of the time, comments can be removed using an HTML minify plugin.
-
Remove unnecessary attributes:
type="text/javascript"ortype="text/css"anymore and should be removed.<!-- Before HTML5 --> <script type="text/javascript"> // Javascript code </script> <!-- Today --> <script> // Javascript code </script>
Why:
Type attributes are not necessary as HTML5 implies text/css and text/javascript as defaults. Unused code should be removed when not used by your website or app as they add more weight to your pages.
How:
⁃ Ensure that all your
<link>and<script>tags don't have any type attribute. -
Place CSS tags always before JavaScript tags:
<!-- Not recommended --> <script src="jquery.js"></script> <script src="foo.js"></script> <link rel="stylesheet" href="foo.css"/> <!-- Recommended --> <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
<link>and<style>in your<head>are always before your<script>. -
Minimize the number of iframes:
-
Minification:
Why:
When CSS files are minified, the content is loaded faster and less data are send to the client. It's important to always minified CSS files in production. It is beneficial for the user as it is for any business who wants to lower bandwidth costs and lower resource usage.
How:
⁃ Use tools to minify your files automatically before or during your build or your deployment.
-
Concatenation:
<!-- Not recommended --> <script src="foo.js"></script> <script src="ajax.js"></script> <!-- Recommended --> <script src="combined.js"></script>
Why:
If you are still using HTTP/1, you may need to still concatenate your files, it's less true if your server use HTTP/2 (tests should be made).
How:
⁃ Use online tool or any plugin before or during your build or your deployment to concatenate your files. ⁃ Ensure, of course, that concatenation does not break your project.
-
Non-blocking:
<link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="global.min.css"></noscript>
Why:
CSS files can block the page load and delay the rendering of your page. Using
preloadcan actually load the CSS files before the browser starts showing the content of the page.How:
⁃ You need to add the
relattribute with thepreloadvalue and addas="style"on the<link>element. -
Length of CSS classes:
Why:
Even performance impacts can be disputable, taking a decision on a naming strategy regarding your project can have a substantial impact on the maintainability of your stylesheets. If you are using BEM, in some cases, you can ended up with classes having more characters than need. It's always important to choose wisely your names and namespaces.
How:
⁃ Setting a limit in terms of number of characters could be interesting for some people, but ensuring that you broke down your website in components can help to reduce the amount of classes (and declarations) and the length of your classes.
-
Unused CSS:
Why:
Removing unused CSS selectors can reduce the size of your files and then speed up the load of your assets.
How:
⁃
⚠️ Always check if the framework CSS you want to use don't already has a reset / normalize code included. Sometimes you may not need everything that is inside your reset / normalize file.
-
CSS Critical:
<style></style>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.
-
Embedded or inline CSS:
<body>(Not valid for HTTP/2)Why:
One of the first reason it's because it's a good practice to separate content from design. It also help you have a more maintainable code and keep your site accessible. But regarding performance, it's simply because it decrease the file-size of your HTML pages and the load time.
How:
⁃ Always use external stylesheets or embed CSS in your
<head>(and follow the others CSS performance rules) -
Analyse stylesheets complexity:
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 above can also help you analysing and correct your code.
-
Webfont formats:
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
preconnectto load your fonts faster:<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Why:
When you arrived on a website, your device needs to find out where you site live 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 ressource (fonts, CSS files...). Prefetches and preconnects allow the browser
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
<head>and add eventually these hostnames that you should prefetch too. -
Webfont size:
-
Images optimization:
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:
Why:
To ensure that your images don't slow your website, choose the format that will
How:
⁃ Use 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:
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.
-
Images dimensions:
widthandheightattributes on<img>if the final rendered image size is known.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:
-
Lazy loading:
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 to identify how many images are offscreen. ⁃ Use a JavaScript plugin like to lazyload your images.
-
Responsive images:
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
srcsetandpictureto deliver multiple variants of each image.
-
JS Minification:
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.
-
No JavaScript inside:
<head>or at the end of your page (before</body>).Why:
Placing JavaScript embedded code directly in your
<body>can slow down your page because it loads while the DOM is being built. The best option is to use external files withasyncordeferto avoid blocking the DOM. Another option is to place some scripts inside your<head>. 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
asyncordeferand decide wisely the code that you will need to inject in your<head>. -
Non-blocking JavaScript:
asyncor deferred usingdeferattribute.<!-- Defer Attribute --> <script defer src="foo.js"> <!-- Async Attribute --> <script async src="foo.js">
Why:
JavaScript blocks the normal parsing of the HTML document, so when the parser reaches a
<script>tag (particularly is inside the<head>), it stops to fech and run it. Addingasyncordeferare highly recommended if your scripts are placed in the top of your page but less valuable if just before your</body>tag. But it's a good practice to always use these attributes to avoid any performance issue.How:
⁃ Add
async(if the script don't rely on other scripts) ordefer(if the script relies upon or relied upon by an async script) as an attribute to your script tag. ⁃ If your have small scripts, maybe use inline script place above async scripts. -
Optimized and updated JS libraries:
Why:
Most of the time, new versions come with optimization and security fix. You should use the most optimized code to speed up your project and ensure that you'll not slow down your website or app without outdated plugin.
How:
⁃ If your project use NPM packages, npm-check is a pretty interesting library to upgrade / update your librairies.
-
Check dependencies size limit:
Why:
You may be tempted to use one of the 745 000 packages you can find on npm, but you need to choose the best package for your needs. For example, MomentJS is an awesome library but with a lot of methods you may never use, that's why Day.js was created. It's just 2kB vs 16.4kB gz for Moment.
How:
⁃ Always compare and choose the best and lighter library for your needs. You can also use tools like npm trends to compare NPM package downloads counts or Bundlephobia to know the size of your dependencies.
-
JavaScript Profiling:
Why:
JavaScript complexity can slow down runtime performance. Identifing these possible issues are essential to offer the smoothest user experience.
How:
⁃ Use the Timeline tool in the Chrome Developer Tool to evaluate scripts events and found the one that may take too much time.
-
Webpage size < 1500 KB:
Why:
Ideally you should try to target < 500 KB but the state of web shows that the median of Kilobytes is around 1500 KB (even on mobile). Depending your target users, connexion, devices, it's important to reduce as much as possible your total Kilobytes to have the best user experience possible.
How:
⁃ All the rules inside the Front-End Performance Checklist will help you to reduce as much as possible your resources and your code.
-
Page load times < 3 seconds:
Why:
Faster your website or app is, less you have probability of bounce increases, in other terms you have less chances to lose your user or future client. Enough researches on the subject prove that point.
How:
⁃ Use online tools like Page Speed Insight or WebPageTest to analyze what could be slowing you down and use the Front-End Performance Checklist to improve your load times.
-
Time To First Byte < 1.3 seconds:
-
Cookie size:
Why:
cookies is exchanged in the HTTP headers between web servers and browsers. It's important to keep the size of cookies as low as possible to minimize the impact on the user's response time.
How:
⁃ Eliminate unnecessary cookies
-
Minimizing HTTP requests:
-
Use a CDN to deliver your assets:
- 📖 10 Tips to Optimize CDN Performance - CDN Planet
- 📖 HTTP Caching | Web Fundamentals | Google Developers
-
Serve files from the same protocol:
-
Serve reachable files:
-
Set HTTP cache headers properly:
-
GZIP compression is enable:
- 📖 Optimizing Performance - React
- 📖 React image manipulation | Cloudinary
- 📖 Debugging React performance with React 16 and Chrome Devtools.
The Front-End Performance Checklist wants to also be available in other languages! Don't hesitate to submit your contribution!
Open an issue or a pull request to suggest changes or additions.
If you have any question or suggestion, don't hesitate to use Gitter or Twitter:
Build with ❤️ by David Dias at @influitive 🇨🇦
This project exists thanks to all the people who contribute. [Contribute].
All icons are provided by Icons8