My primary use case: drop a webpack stats file → see why exactly that specific huge file is bundled.
4) web-vitals-report.web.app builds a Core Web Vitals report based on your Google Analytics data (but you need to send CWV data into GA explicitly).
Haven’t had a chance to use it yet (don’t collect CWV data with GA), but should be a great helpful tool for some clients.
5) Also, datastudiohelp.com/core-web-vital… explains how to get a Core Web Vitals report in Google Data Studio. (It’s actually quick! Just clone a template and change the url.)
Unlike with the previous tool, you don’t need to collect any data yourself! The report uses CrUX data.
6) usehooks.com/useWhyDidYouUp… is a React hook that prints why a specific component rerendered. Just copy and paste it! Perfect for debugging runtime performance of a single component 💅
7) meowni.ca/font-style-mat… (yet another tool by @notwaldorf!) lets you find a fallback font that matches your custom font as closely as possible.
If you ever had a high CLS score because the layout jumped after a custom font loaded, this is for you.
(Oh, and shameless plug: in addition to these tools above, I also have a GitHub list with 50+ webpack performance tools and plugins: github.com/iamakulov/awes…)
8) glyphhanger, which makes fonts smaller by removing any characters your page doesn’t need (and more). And it’s a one-line command!
How I typically test performance (a thread for a client who asked about this):
1️⃣ When I’m optimizing Core Web Vitals, I typically focus on LCP and CLS. LCP is roughly “how quickly the page renders”, CLS is “how much the page jumps during loading”.
I don’t normally focus on FID because it’s almost always green (but that will change next year).
2️⃣ When I’m profiling LCP, I like to work through WebPageTest.org (WPT).
Why WPT:
• Their network throttling is more accurate than Chrome’s (github.com/GoogleChrome/l…)
• And their CPU throttling is stable (vs. my laptop which can be faster or slower)
Ever read an article that says “setTimeout(..., 0) fires not in 0 ms but in 4”? This is no longer true – at least not in Chrome and Safari, and not since a few months ago.
But getting there was a bit of a bumpy road.
1) The HTML spec tells that `setTimeout()` calls nested 5+ levels deep must be throttled to 4 ms. This prevents poorly written sites from over-consuming CPU.
(Note the word “nested” – unnested `setTimeout()`s were never intended to be throttled! But we’ll get to that in a bit.)
Browsers generally adhere to this spec.
However, in 2022, Chromium noticed that bumping the nesting limit from 5 to just 7 improves the Speedometer score by 10%. chromestatus.com/feature/571069…
Gah I’m really excited about <Suspense> and hydration in React 18.
With React 16-17, `.hydrate()` is often the most expensive JS call in the whole app. You start hydrating the app – and the page freezes for, like, a second:
In React 18, `.hydrate()` is still expensive by default.
But! If you wrap parts of the app (or the whole app) with <Suspense>, React will take these parts – and instead of hydrating them in one go, will hydrate them in chunks, 5-10 ms at a time:
Under the hood, React uses performance.now() and isInputPending() APIs to check how long rendering takes. If rendering takes more than 5-50 ms, or if isInputPending() returns `true`, React pauses rendering and yields to the browser.
Spotify is an Electron app, meaning we can use Chrome DevTools to profile it. To enable Chrome DevTools in Spotify, I install `spicetify` and run `spicetify enable-devtools`.
Yay!
Now, let’s go to Chrome DevTools → Performance → Record, switch between playlists a couple times, and stop the recording. This is what we’ll get ↓
One of the reasons your Lighthouse score might be bad is third parties.
Many (not all, though!) third parties execute a lot of JavaScript. This blocks the main thread & worsens your JS-related Lighthouse metrics (TTI/TBT).
Here’re several ways to optimize them – a thread ⬇️
1) Check if all third parties are needed
Sometimes, we add an analytics script, experiment with it, and then forget to remove it.
Go to DevTools → Network, filter away your domain, then go over “Domains” and see if there’s anything you (or the marketing team) don’t recognize.
2) Use a timer
Some third-parties can be delayed without hurting the business. Eg marketing is often fine with delaying Facebook Pixel – they don’t care about retargeting to users that spent less than 10s on the site.
In this case, just tune the script code to use a timer: