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.
Ivan Akulov
@iamakulov.com
Web perf engineer @ Framer. Prev. web perf consultant (Google, Appsmith, Toggl, etc). Getting React interactions 2-4x faster. GDE. He/him 🏳️🌈
TIL GTM has a History Change trigger, but this trigger doesn’t fire when you navigate via the new Navigation API :( There goes my dream of making all Framer sites use navigation.navigate() instead of history.pushState()
If you throttle the network in DevTools you can't always trust the metrics. @iamakulov.com explains why in his new article. 3perf.com/blog/chrome-...
Chrome DevTools Throttling Is Not Accurate
Chrome DevTools slows down requests, not packets. This means its throttling is often off where it matters.
3perf.com
Doctor: Chrome DevTools throttling is real and can hurt you Chrome DevTools throttling: [proceeds to not be real]
My Replay time-travel-based React+Redux perf reports experiments are coming together! Just nailed sourcemapped component + selector identities, and I've got accurate timing details on dispatches + renders from a Replay DevTools E2E recording! Early perf report example attached.
A week-ish later - it's working! Rebuilt my React+Redux dispatch+render perf POC on top of Replay's current infra. Currently extracting dispatch+render timings and selector calls . Just raw data atm, but now I can build meaningful visualizations / perf analysis with this! time travel's awesome!
Something I worked on (with a few other wonderful folks) for the past few weeks :) www.framer.com/llm
the chart that I feel perhaps the proudest of is this framer’s lcp (aka page loading time), across all sites, going lower and lower day by day, free for all framer customers lots of work by our infra/canvas teams, @kurtextrem.de, and yours truly <3
next.js (pages router) loads data for pages you navigate to, but never releases it, whoops: github.com/vercel/next...
ah yes it’s my favorite “iphone safari wraps every phone number with <a> → react has a hydration mismatch → it remounts the full dom → all images on the page flash, but only on iphone” type of day
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:
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:
I'll say that I do pre-bundle the Redux libs, and so far it's seemed to work fine as far as I can tell.
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)
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.
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.
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.
Belated hi from @perfnow.nl! Come talk to us (me & @kurtextrem.de) about React performance, Framer sites, LCP/INP and more :D
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
This lil boy (www.framer.com/updates/cms...) actually took multiple weeks of full-time work! That’s because we didn’t only fix copy-paste papercuts, we also took an opportunity to improve Framer’s text editing architecture. Story time!
til oxlint does some insane tricks (custom js ast interface that understands rust memory layout!) to make js plugins fast github.com/oxc-project...
something very cool to see: Chrome recently shipped automatic <link rel="prefetch"> for all links in viewport you could do it previously with libs like Quicklink, but it’s super cool to see this implemented natively (it’s off by default, enabled with one html tag)
soon in @Framer.com: much better ⌘C ⌘V with google docs, notion, craft, and every other editor out there (my lil non-performance side project)
⚡ Lighthouse (incorrectly) punishes preloading If you’re like me, you probably struggled with Lighthouse scores at least once. “I already optimized everything; why is my score still yellow?” Often, the cause is there’s more to optimize. But sometimes, it’s Lighthouse itself.
📝 Wrote about that one time I was doing performance work and ran into an eval()-based JS minifier from 2004. (Also, it’s compatible with ES2024, guess what) 3perf.com/blog/packer/
Introducing @Framer.com Code Boundaries. No more optimization errors, no more blank pages, and no more searching for broken Components. (Or: how we went down the rabbit hole of React error handling for a month 🧵)