Ivan Akulov

Story behind the improvement:

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

7) So now, when a site is published, it remains unoptimized only for seconds. Once bundling for top pages completes, every other page on the site starts using that bundle (+ modulepreloads, etc)!

It’s still not as fast as optimized pages – not until the 1st visit – but it’s much faster than before.

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.).

4) This made optimization much faster! But this also meant a very small % of visitors would hit pages that are not bundled and not SSR-ed.

Framer Updates — Dynamic Optimization Introducing Dynamic Optimization, an all-new way of optimizing your published websites. All sites now optimize in seconds, even large ones. And adding pages has no impact on optimization time. Pages are now optimized on first visit, and we cache the result until the next publish. Your most visited pages are pre-optimized on publish, ensuring consistent performance and full visibility into any issue. This makes Framer’s very best feature, instant publishing, even better. We’re rolling this out gradually throughout October 2025. Publishing, even faster. Only in Framer.

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...)

1) Framer sites are fully capable React apps

2) We used to SSR every page of every site on publish. As Framer grew, in 2025, this stopped scaling (a bundling + SSR + data injection pass, which we call “optimization”, would take minutes on large sites)

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

Responded! bsky.app/profile/did:...

And learned that this doesn’t happen with every dep, only with some of them :D

(Is it a bad taste to quote-reply on bluesky btw? I haven’t posted much in a while lol, might’ve missed the memo)

This doesn’t happen with every package btw.

This happens with fast-deep-equal because it’s 1) written in CommonJS (so it’s not tree-shakable) and 2) doesn’t have `sideEffects: false` (so the bundler cannot ignore the package if its imports aren’t used).

But most packages have one of those :(

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.)

2) Make an index.js that imports and uses a completely different function:

import { compose } from "redux";
console.log(compose);

3) Bundle

4) Boom – fast-deep-equal is bundled, even though it’s not used

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:

- esm > cjs modules (bundlers still don’t shake cjs well/at all)
- sideEffects: false ftw
- don’t bundle a library into a single file for npm. kills shakeability

spent the day shaking the tree, shook 1.5 MB

General philosophy and vision · Issue #13 · tc39/proposal-bigint-math Original post Spinning this out of #8 (comment) and #9 (comment). There are two dueling philosophies we could take for this proposal. “BigInts and Numbers should always be interchangeable by defaul...

Turns out this is why! github.com/tc39/proposa...

just why

Using PerformanceObserver or manual timers/logs, I guess :D

Logging into the console while it’s closed still works

(But yup, somewhat annoying 🙈)

So turns out none of this was real

(which was pretty hard to tell because the only way to tell was to close DevTools lol)

Benchmark: codepen.io/iamakulov/pe.... Try with DevTools open vs closed – especially with call stack depth 1000.

(“1000 levels deep” might seem like a lot, but it’s pretty realistic with React’s recursivelyTraversePassiveMountEffects. That’s how I ran into it – in TanStack Query!)

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)

this needs to nerdsnipe someone from Chromium to investigate this :P

In the app I spotted this issue in (a typical complex React app), these setTimeouts were ~1500 calls down the `recursivelyTraversePassiveMountEffects` stack

Okay, I noticed that I cannot repro these slow setTimeouts outside of React / TanStack Query.

So I tried to profile this, and apparently setTimeout calls are much (10×) slower if you do them deep within a call stack (eg React’s recursivelyTraversePassiveMountEffects)? bsky.app/profile/did:...

setTimeout calls also become 2× slower if you have previously set ~750 timers (doesn’t matter whether they already fired):

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...

hahaha, full circle :D

I might publish the impl I posted in that issue as an npm package!

(Question prompted by spending an hour to implement userland setTimeout batching :D)

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.