Thread by @Phacks

Thread Time !

👇Web Performance metrics explained in a single tweet each 👇

I noticed recently that many colleagues are not familiar with most of the Web Performance metrics. It can feel overwhelming as there are A LOT; their key differences might be difficult to catch (FP vs. FCP vs. FMP, TTI vs. FID?), and deciding which one(s) to monitor is hard.

In the next tweets, I’ll try my best to explain the most prominent metrics in a single tweet each that read as follow:

Metric Name
⚙️ What does it measure?
👩‍💻 What’s the impact on your users?
⚛️ Is it useful for my technical stack?

Let’s get started!

Load Time
⚙️ Triggered when network is quiet and page is fully loaded
👩‍💻 Everything is loaded, including under-the-fold content & third party scripts (analytics, etc…)
⚛️ Considered deprecated today — doesn’t really reflect how modern websites (like SPAs) work or the actual UX

SpeedIndex
⚙️ Measure how fast pixels of the page reach their final position
👩‍💻 Focused on what the user sees first. Penalizes websites where elements jump around while loading
⚛️ Waaay better than Load Time. Relevant for all websites. Crucial for SEO

Time To First Byte
⚙️ The time it takes for the browser to receive the first byte from the server, usually HTML
👩‍💻 Not visible by the user
⚛️ Particularly relevant for Server Rendered (Django) or Server-Side Rendered (NextJS) websites, where most computations happen server-side

First Paint & First Contentful Paint
⚙️ FP is the time it takes for the first pixel to be drawn on the screen. FCP represents the first painting of a DOM element (text, image…)
👩‍💻 The screen is not blank anymore.
⚛️ Server-rendered and SSR websites where the HTML is big

First Meaningful Paint
⚙️ The “hero” element of the page (a big element at the top center) is visible
👩‍💻 The purpose of the user’s visit to the website is visible (tweet, video…)
⚛️ All stacks. The “meaningful” element can be specified manually by using Custom Metrics

Time To Interactive
⚙️ (Roughly) the time where CPU computations and network requests are few and far between
👩‍💻 Approximates the moment where users can reliably interact without lag or jank
⚛️ A must-have for SPAs (React, Vue…), although not a silver-bullet as it’s an estimate

First Input Delay
⚙️ Similar to (but not exactly like) TTI, measures the time between the first user interaction and the page updating accordingly. Measured on PageSpeed Insights
👩‍💻 When users click on something, the page responds quickly
⚛️ Useful for SPAs, complements the TTI

Lighthouse Score
⚙️ Aggregates many of the previous metrics, simulates middle-end device & poor network conditions. Measured via Dev Tools or web.dev/fast
👩‍💻 The page overall feels fast even on 3G / your old neighbor’s desktop
⚛️ Useful for all websites

Critical Path Resource Size / Bundle Size
⚙️ Measures how many bytes of resources / JS the user needs for the page to be usable
👩‍💻 A high size means poor performance & lagginess on low-end devices and slow networks
⚛️ Critical for SPAs, set up a Performance Budget to keep track

That’s all, folks! Should you want to dig deeper, I recommend the following:
- WebPageTest : webpagetest.org
- Rendering on the Web: developers.google.com/web/updates/20…
- User Centric Performance Metrics: developers.google.com/web/fundamenta…
- Performance Budgets 101: web.dev/fast/performan…

And I’d also like to thank the many Web Performance peeps in here for teaching me many of that stuff, and I highly encourage you to follow them: @hdjirdeh @borisschapira @theystolemynick @patmeenan @addyosmani @WalterStephanie @csswizardry