This handbook helps to quickly understand the topic and start improving performance. It contains a metrics glossary, a compilation of useful tools, and a catalog of necessary materials.
I really want to share proven knowledge to make the web even better and faster. Support and bookmark the project by giving it a star! ⭐
- Web Performance Handbook
How to view historical performance data of real users?
Allows viewing annual reports for websites based on Light House and CrUX (Chrome User Experience Report) metrics. Filters can also be set, such as internet connection speed, location, and device. Uses real user data. Very useful for observing trends and metrics specific to certain user types.
Collect metrics such as INP, LCP, CLS, FIP, FCP, and TTFB in real-time and easily view them in a popup. Enabling logging in options can assist in debugging INP.
Allows you to conduct Lighthouse performance tests remotely, in a more realistic environment. Can be used for taking more objective measurements, as computer powers vary among teammates. Especially, developers tend to have significantly more powerful computers than the general market. Also, for popular websites, it provides data from the CrUX report.
The same as previous, but on steroids. Allows you to set up a testing environment: location, browser, its available functionality, connection speed, etc. Can record a video of the loading process, providing more understandable and detailed reports on the webpage loading process and requests.
A tool designed for assessing the quality of a web page, focusing on core vitals metrics, SEO, and accessibility. It is built into Chrome DevTools and can be also used as a CLI tool, making it especially useful for measuring performance during CI processes. Additionally, it offers practical suggestions to enhance the quality and loading speed of the page.
Record and analyze the performance of a page. It allows you to see the loading process in detail, including the loading, scripting, rendering, and painting phases. It also provides a timeline of events, which can be used to understand what is happening under the hood. For instance, you can see how long the hydration takes.
Hint:
Enable the experimental "timeline-*" features in DevTools settings to see more information about events. It's especially
useful for React apps. By default, it's challenging to understand what's really happening because of tons of anonymous
events.
Allows you to store historical performance data and see differences between builds. It integrates with CI/CD processes.
A tool for monitoring web performance and Lighthouse metrics. It can be used to set up alerts for performance regressions.
React has a trick that allows you to disable hydration for a component. The server will render it once, then send an HTML that won't be hydrated. Perfect for static content.
<div suppressHydrationWarning dangerouslySetInnerHTML={{ __html: "" }}/>It's also available as part of an npm package: react-lazy-hydration
To improve LCP and reduce traffic volume, you can use image proxies or CDNs. They will reformat, resize, and optimize your images on the fly, and cache them immediately.
Possible solutions:
- Cloudflare Images
- UploadCare
- ImageProxy
- Implement manually: Good starting point.
Reduce the size of static files by 15-17% (the exact number is better to calculate using your own resources). The best results can be achieved using brotli with compression level 11. However, the compression time is longer than with gzip (level 9), so it's better to avoid using it on-the-fly and only use pre-compressed or cached versions.
Built elaborated report of your bundle. Separates scripts from initial loading and asynchronous loading.
Identifies why a package has been installed. Especially useful for transitive dependencies.
yarn why
pnpm whyconst mockEmptyModule = path.resolve('./mock-empty-module.js');
// ...
config.resolve.alias['reactstrap/lib/Carousel.js'] = mockEmptyModule;The key principle is to avoid including code in the initial load that can be downloaded later. Instead, download it when a user is about to view it in their viewport, during idle time, or at the start of an interaction.
For React, combine dynamic module import with Suspense.
If it's safe, align the minor versions of installed modules that are duplicated.
yarn dedupe
npm dedupe
pnpm dedupeAllows you to rename chunks, regroup, prefetch lazy chunks and more.
A tool for detecting unnecessary re-renders. It can be used to find components that are re-rendered too often. Write messages to the console.
Shows the time spent rendering each component and how many times it was rendered. To observe why it was rendered, enable the "Record why each component rendered while profiling" flag in the settings.
Provides a solid basis for understanding how a browser renders a document and what happens behind the scenes.
Reveals many subtleties and working practices about optimization that are not usually written about.
This is a list of the most common metrics which may appear in articles, DevTools, Lighthouse, and other various tools for working with web performance. Everything is sorted in the alphabetical order.
The factual data is primarily sourced from MDN, web.dev and w3c, however the short description has been rewritten and enhanced.
Cumulative Layout Shift
Measurement Unit: Score (lower is better)
Shows how often users experience unexpected changes in the layout. It measures the instability of elements and their overall impact. For example, the banner element changes its height during the loading process, which causes a shift in the elements below.
DOMContentLoaded
Measurement Unit: Milliseconds (ms)
Refers to the moment in a webpage's loading process when the DOM is completely parsed. And all deferred scripts have downloaded and executed. It doesn't wait for resources.
First Contentful Paint
Measurement Unit: Milliseconds (ms)
Measures the time it takes for first bit of any actual content on a page to become visible on the screen. This includes text, images, background images, SVG elements, and non-white canvas elements.
First Input Delay
Measurement Unit: Milliseconds (ms)
Measures the time it takes for the browser to respond to a user's first interaction. This interaction can include clicks, hovers, touches, and other user events.
First Paint
Measurement Unit: Milliseconds (ms)
Marks the first time the browser renders anything visually different from the default background color of the body.
Interaction to Next Paint
Measurement Unit: Milliseconds (ms)
Measures the time it takes for the browser to paint the next frame after a user interaction.
On Load
Measurement Unit: Milliseconds (ms)
Measures the time when the entire page and its resources are fully loaded. It includes all dependent resources: stylesheets, scripts, iframes, and images.
Largest Contentful Paint
Measurement Unit: Milliseconds (ms)
Measures the time when the largest content block is rendered in the user viewport. The content may include images, background images, SVG, video, and text.
Speed Index
Measurement Unit: Score (lower is better)
Measures how swiftly the contents of a page are visually populated. Technically, in a graph, it is represented by the area above the curve, which will approach 0 as the page loads faster.
Total Blocking Time
Measurement Unit: Milliseconds (ms)
Measures the time between FCP and TTI when the main thread was blocked for long enough to prevent input responsiveness. More specifically, it's the sum of the blocking time for each long task (>50 ms). For web frameworks, this time is usually consumed by virtual DOM renders and hydration.
Time to Interactive
Measurement Unit: Milliseconds (ms)
Measures the time when than at least for 5 seconds where weren't long tasks (>50ms) and no more than two in-flight network GET requests.
Time To First Byte
Measurement Unit: Milliseconds (ms)
Measures when the first byte of data from the web server reaches the browser.