Ivan Akulov

honestly the best thing about agents is they let you ship things you sat on for two years but never prioritized

@storyhb.com hey :) i’m a staff performance engineer at Framer. i have a quick q about automatic image preloading in React 19. (hopefully you’re the right person as you merged github.com/react/react/... – if not, sorry, just lmk who’s the best person to ask this at 🙏)

eg: - fetchpriority=low lowers the loading priority from medium to low (in Chromium). - loading=lazy makes the image lazy (duh). today, there’s no React primitive that you can use to tell React “just keep these images as-is, don’t change anything about them”. this feels like a weird API gap.

@storyhb.com hey :) i’m a staff performance engineer at Framer. i have a quick q about automatic image preloading in React 19. (hopefully you’re the right person as you merged github.com/react/react/... – if not, sorry, just lmk who’s the best person to ask this at 🙏)

common but surprisingly rarely mentioned react perf pitfall: 1) text changes its size when fonts load (duh, you see this every day). often it gets larger 2) lcp (= google’s loading speed metric) scans for the largest element on the page. but it scans only newly added elements. it doesn’t scan--

it doesn’t scan elements that were already there but got larger 3) when a react hydration mismatch happens, react removes all elements on the page and replaces them with (identically looking) new ones boom. text got larger + hydration mismatch = 💥

Possibly one of the most impressive Safari bugs I’ve run into lately: Going back (with a swipe) in *any* React app that uses Navigation API freezes the page for three seconds. What’s fun is the main thread is not frozen, only the rendered page is.

> in *any* React app The critical element here is a top-level wheel event listener, which React always installs. The video above actually doesn’t use React at all, it only has that event listener installed Reported here: bugs.webkit.org/show_bug.cg...

Doctor: Chrome DevTools throttling is real and can hurt you Chrome DevTools throttling: [proceeds to not be real]

Tomorrow, when you publish a Framer site, every page’s HTML will get 10-20% smaller:

Last week in Framer performance: the first view of unoptimized pages is now much faster, especially on large sites:

5) 2 weeks ago, we looked at these pages and realized we can make them faster. We still can’t optimize them – it’s too costly. But we can reuse something that other pages produce – for ~free. 6) What’s “something”? It’s the bundle (plus a few other things, like <link rel="modulepreload">s etc.).

Last week in Framer performance: the first view of unoptimized pages is now much faster, especially on large sites:

3) In October, we rewrote our optimization stack – and made it so that on publish, only the most visited pages are optimized. Less popular ones would get lazily handled after the first visit. (H/t our Piotr Krawiec, who single-handedly did the whole rewrite: www.framer.com/updates/dyn...)

Last week in Framer performance: the first view of unoptimized pages is now much faster, especially on large sites:

Yeah, Redux works great because it doesn’t import anything! Here’s a case when this breaks: 1) Add a random dependency in Redux that’s used in some random function:

Whereas if Redux *wasn’t* bundled, the bundler won’t even enter the file that imports fast-deep-equal. (This is thanks to `sideEffects: false` which Redux does.)

Yeah, Redux works great because it doesn’t import anything! Here’s a case when this breaks: 1) Add a random dependency in Redux that’s used in some random function:

spent the day shaking the tree, shook 1.5 MB

just why

Welp, turns out it’s not real. Just opening DevTools makes all timers 5-100× slower, due to the overhead of capturing stack traces. Even if you do nothing else (don’t record performance, etc)! Guess who accidentally spent a weekend optimizing this 😅 (h/t @paul.irish for explaining why)

Okay, so this is pretty wild: apparently, in Chromium, the deeper you are in the call stack, the slower your `setTimeout()` calls become? gist.github.com/iamakulov/85...

Why are native setTimeout and clearTimeout calls so expensive? Like, here it takes 1.5 ms. What’s the technical reason it’s so slow? Just 100-200 of those in a row (trivial if you’re mounting a bunch of React components that set timers) will easily block the page.

Neat lil learning from today’s @perfnow.nl (via Umar Hansa): You can now throttle individual requests in Chrome! Neat for experimenting with stuff like - lazy-loading: does the UI look okay if this chunk takes MUCH longer to arrive - resilience: what happens if this specific CDN is extremely slow