├── CONTRIBUTING.md ├── LICENSE └── README.md /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## The goal 2 | 3 | The goal of this repo is to gather common techniques used when developing a web application to improve its performance. 4 | 5 | ## The rules 6 | 7 | When adding a practice to this checklist, the following rules should be applied: 8 | 9 | - Of course the practice should be only about performance. 10 | - Redundancy should be avoided, so prefer modifying an existing practice over duplicating if you want to add information. 11 | - The practices should be commonly accepted as good practices; obscure hacks should be avoided. 12 | - The practices should be concise but easy to understand; if possible add a link to some documentation on it. 13 | - If there is no mainstream alternative, a link to a tool can be added to a practice if it can help realizing it. 14 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2017 Antares Tupin 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Web Application Performance Checklist 2 | 3 | [![Awesome Checklist](https://img.shields.io/badge/Awesome-Checklist-blue.svg)](http://checklist.yingjiehu.com/) 4 | 5 | Performance is crucial in today's web applications. A slow app feels buggy to the users and make them flee it. 6 | 7 | Although performance is such an important topic, there are so many optimization vectors that it's easy to forget some of them. 8 | The intent of this checklist is to gather performance practices to apply when developing a web application. 9 | 10 | Contributions and stars are welcome 🙏 11 | 12 | While you apply these practices, you should always keep the following rules in mind: 13 | 14 | - Don't optimize too early 15 | - Don't let performance ruin productivity 16 | - Always check an optimization is efficient by measuring performance before and after it 17 | 18 | 19 | ## Table of Contents 20 | 21 | - [Set your objectives](#set-your-objectives) 22 | - [Think about performance when building your tech stack](#think-about-performance-when-building-your-tech-stack) 23 | - [Frontend](#frontend-1) 24 | - [Backend](#backend-1) 25 | - [Database](#database-1) 26 | - [Network and Infrastructure](#network-and-infrastructure) 27 | - [Measuring](#measuring) 28 | - [Misc](#misc) 29 | - [Specialized checklists](#specialized-checklists) 30 | 31 | 32 | ## Set your objectives 33 | 34 | - [ ] Define the **performance metrics and objectives** that are important to your business 35 | - The [RAIL model](https://developers.google.com/web/fundamentals/performance/rail) is generally a good model to start with. 36 | - If speed is an advantage you want to have against competitors, know that users usually will feel you are faster if you are at least 20% faster than them. 37 | - [ ] Plan out a **loading sequence**; this way you can define early what is really important in your content, what to load first and what to load later 38 | - [ ] Make a **performance budget** 39 | - The [performance budget calculator](http://www.performancebudget.io) is useful to estimate your budget depending on the performance you want to obtain. [This one](https://codepen.io/bradfrost/full/EPQVBp) is nice too. 40 | - Remember that this budget takes compression in account. 41 | - Currently the recommended budget is [max. 170kb gzipped, 130kb if JS heavy](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/), but it really depends mostly on your user-centric objectives 42 | 43 | ## Think about performance when building your tech stack 44 | 45 | Before beginning to build your app, you should have some preparation in order to ease your work on performance later. 46 | 47 | ### Frontend 48 | 49 | - [ ] If choosing between SPA frameworks, **take in account features like server side rendering**; these features will be hard to add later 50 | - [ ] Take in account **how much every library / framework will take on your performance budget**; don't use too much of them 51 | - [Bundlephobia](https://bundlephobia.com) can help you estimate the size of a new dependency. 52 | - [ ] **Make sure you need custom fonts** before using them 53 | - [This article](https://hackernoon.com/web-fonts-when-you-need-them-when-you-dont-a3b4b39fe0ae) can help you 54 | - [ ] Consider technologies like **[AMP](https://www.ampproject.org/fr/)** and **[Instant Articles](https://instantarticles.fb.com/)**, but be aware of their pros and cons 55 | - Keep also in mind these solutions are not mandatory to obtain correct performances. 56 | 57 | ### Backend 58 | 59 | - [ ] When choosing a web framework / library / language, take in account the following points: 60 | - How **fast** is the library / underlying language (but be aware that benchmarks are usually biased)? 61 | - How easy will it be to handle **concurrency**? 62 | - Does it allow an **efficient resources management**, e.g. using a connections pool or an event loop? 63 | 64 | ### Database 65 | 66 | - [ ] Make sure you **use the right DBMS** for your needs 67 | - Usually a relational database will cover most needs, but in some cases a NoSQL database may be a better fit. 68 | - If hesitating between NoSQL solutions, [this comparison](https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis) may help you. 69 | 70 | 71 | ## Frontend 72 | 73 | ### Optimize images 74 | 75 | Images represent in average ~60% of a page's weight, thus it's an important part to optimize. 76 | 77 | - [ ] Use **WebP compression** format for browsers that accept it 78 | - [ ] Use **responsive images** with `img`'s' `srcset` and `size` attributes 79 | - [ ] **Optimize** manually **important images** or script their optimization 80 | - [ ] **Lazy load** images 81 | - [ ] Replacing animated **gifs by videos** can reduce their size dramatically (details [here](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/replace-animated-gifs-with-video/)) 82 | 83 | ### Reduce code size 84 | 85 | - [ ] **Minimize** the source code 86 | - [ ] Use **tree shaking** (e.g. with [webpack](https://webpack.js.org/)) to remove unused code 87 | - [ ] If your bundled code file is too big, use **code splitting** to load only what's needed first and lazy load the rest 88 | - [ ] Serving **ES2015 code to browsers supporting it** and ES5 code to browsers that don't, using `type="module"` and `nomodule`, can improve the bundle size and parsing time (details [here](https://philipwalton.com/articles/deploying-es2015-code-in-production-today/)) 89 | 90 | ### Reduce number of requests 91 | 92 | - [ ] Replace third parties components (like sharing buttons, maps...) by **static components** 93 | - Tools like the [Simple sharing buttons generator](https://simplesharingbuttons.com) can help you. 94 | - [ ] Cache requests client side using **service workers** 95 | - [ ] Bundle common images using **CSS sprites** 96 | 97 | ### Prepare next requests 98 | 99 | You can use prefetching to prepare the browser to next requests and make them faster or even instant. [This article](https://css-tricks.com/prefetching-preloading-prebrowsing/) is a few old but explains well the following techniques. 100 | 101 | - [ ] Use **dns-prefetch** to resolve the domain of services you may need 102 | - [ ] Use **preconnect** to do DNS lookup, TCP handshake and TLS negociation with services you know you will need soon 103 | - [ ] Use **prefetch** to request specific resources that are likely to be needed soon, like images and scripts 104 | - This technique makes an especially good combination with lazy loading. 105 | - [ ] Use **preload** to request specific resources that will be needed in the current page, e.g. `