Web Performance Cheat Sheet

My attempt to make a cheatsheet for Web Performance topic where I cover Web Vitals initiative metrics such as FCP, LCP, CLS, and FID.

What is Web Vitals?

Web Vitals is an initiative by Google that provides an ability to quantify the experience of the website and identify ways to improve it.

What is Core Web Vitals?

Core Web Vitals are a subset of Web Vitals and the metrics that included evolve over time. The current set of metrics focused on such aspects as loading, interactivity, and visual stability and includes LCP, FID, and CLS.

Types of metrics

  • First contentful paint (FCP) - Time from when the page starts loading to when any part of the page content is rendered.
  • Largest contentful paint (LCP) - Time from when the page starts loading to when the largest content
    element (text block, image) is rendered.
  • First Input Delay (FID) - Time from when a user starts interacting with a website to when
    the website is actually able to respond to that interaction.
  • Time to Interactive (TTI) - Time from when the page starts loading to when it’s visually rendered
    its initial scripts have loaded, and it’s capable of responding to user input quickly.
  • Total Blocking Time (TTB) - The total amount of time between FCP and TTI when the main
    thread was blocked for long enough to prevent input responsiveness.
  • Cumulative Layout Shift (CLS) - The cumulative score of all unexpected layout shifts
    since the page starts loading and while it’s visible.

How metrics are measured?

In the lab - using tools to simulate a page load in a consistent, controlled environment.

In the field - on real users actually loading and interacting with the page.

In general, we need both to ensure good performance.

Improving metrics

The rule of thumb to improve performance - do less stuff.

FCP

We need to make sure the content delivers fast. Consider each point of the following schema:

1
1. Server -> 2. Content -> 3. Internet -> User
  1. Server should be capable to process a request as quickly as possible, have stable quick network bandwidth.
  2. Content should be as small as possible and compressed by either Brotli or GZIP.
  3. A number of hops between Server and Client should be minimal. Using of CDN might help for multi-regional websites.

LCP

Again, it’s the time between page starts loading to when it’s “almost ready”, meaning the large content is rendered. To render content faster in a browser, we could do the following:

Defer resources until later

  • Use defer for scripts.
  • Put <script>s to the bottom of HTML.
  • Lazy-load images and iframes.

Images

  • Use images optimized for user screen size <img srcset="..."/>
  • Use WebP image format with fallback to png.

Reduce network overhead

  • Using HTTP/2 might help. Thanks to multiplexing, a server, and a browser could reuse a connection to transfer muplitple files in parallel, i.e. no need to send HTTP-Request (with all headers) for each file. As for cons, not all servers support it.
  • Caching. Headers like cache-control: max-age=600, expires: Wed, May 3 2098 or etag: somehash helps to avoid downloading of resources from the server and use it from the cache. Note: it works only for returning clients.
  • <link rel="preconnect" href="someresource"> makes the browser to resolve DNS to specified resource. It’s useful when we need some content from third party websites, e.g. Google Fonts.
  • <link rel="preload" href="icons.css"> makes the browser to fetch the specified resource before browser’s main rendering machinery kicks in. This ensures they are available earlier and are less likely to block the page’s render, improving performance.

CLS

  • When possible avoid inserting DOM elements that shift the layout.
  • Predefine width and height for images.
  • Use predefined sizes for lazy-loading content.

FID

Abstract one. The general advice is to do fewer things, i.e. load fewer scripts.