Skip to content

πŸ“– Selected and essential information on web performance collected in one place.

License

Notifications You must be signed in to change notification settings

Danilqa/web-performance-handbook

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

18 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Web Performance Handbook

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! ⭐

Table of Contents


Tools

Global Stats

Browser market share worldwide. This allows you to see device and browser usage in specific regions.

link

Treo β€” Site Speed

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.

link

Web Vitals (extension)

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.

link

PageSpeed Insights

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.

link

WebPageTest

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.

link

Lighthouse

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.

DevTools Performance (with experimental features)

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.


Monitoring

LHCI Server (open-source)

Allows you to store historical performance data and see differences between builds. It integrates with CI/CD processes.

GitHub link

DebugBear (paid)

A tool for monitoring web performance and Lighthouse metrics. It can be used to set up alerts for performance regressions.

link


Optimizing Hydration

Disable Hydration

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

Server Components

more them


Optimizing Page Load Speed

Image Proxy: Use avif / webp / progressive jpeg

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:

  1. Cloudflare Images
  2. UploadCare
  3. ImageProxy
  4. Implement manually: Good starting point.

Data Compression with brotli

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.

Comparison table


Optimizing Bundle

Tools to Analyze

Statoscope

Built elaborated report of your bundle. Separates scripts from initial loading and asynchronous loading.

Github Link

Bundle Analyzer

Github Link

Why?

Identifies why a package has been installed. Especially useful for transitive dependencies.

yarn why
pnpm why

Webpack Alias: Remove 3-rd Party Code from Bundle

const mockEmptyModule = path.resolve('./mock-empty-module.js');
// ...
config.resolve.alias['reactstrap/lib/Carousel.js'] = mockEmptyModule;

Lazy Code Loading: On Viewport, on Interaction

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.

real world example

Deduplication

If it's safe, align the minor versions of installed modules that are duplicated.

yarn dedupe
npm dedupe
pnpm dedupe

Webpack: Magic Comments on Imports

Allows you to rename chunks, regroup, prefetch lazy chunks and more.

link


React Tools

Why Did You Render

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.

link

React DevTools Profiler

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.

link


Learning Resources

Browser Rendering Optimization Course

Provides a solid basis for understanding how a browser renders a document and what happens behind the scenes.

link

Web App Performance Course

Reveals many subtleties and working practices about optimization that are not usually written about.

link


Metrics

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.

CLS

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.

more details

DCL

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.

more details

FCP

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.

more details

FID

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.

more details

FP

First Paint

Measurement Unit: Milliseconds (ms)

Marks the first time the browser renders anything visually different from the default background color of the body.

INP

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.

more details

L

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.

more details

LCP

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.

more details

SI

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.

more details

TBT

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.

more details

TTI

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.

more details

TTFB

Time To First Byte

Measurement Unit: Milliseconds (ms)

Measures when the first byte of data from the web server reaches the browser.

more details

About

πŸ“– Selected and essential information on web performance collected in one place.

Topics

Resources

License

Stars

Watchers

Forks