Back when we posted the update, we knew it wasn’t just a swap of tooling; it was a strategic move to gain finer control over how we optimize Framer sites. Specifically how we bundle and optimize JavaScript assets. The results have been immediate and impactful, particularly in improving the Core Web Vital Largest Contentful Paint (LCP), used by Google as ranking factor. Also, reducing how much JavaScript your visitors have to download speeds up the time until your website becomes fully interactive.

Furthermore, it laid the groundwork for more enhancements. One such feature shipped end of November: We’re now using a Rolldown-exclusive technology called “native MagicString“, which uses highly optimized Rust code to transform JavaScript code. This allows us to further improve the loading performance of CMS pages, by transforming JavaScript on-the-fly (via so called ‘AST transforms’) in an incredibly fast way. More improvements that are unlocked by Rolldown are on our roadmap for 2026.

All of this is a direct result of a cooperation with the company behind Rolldown, called VoidZero, where we’ve guided key implementations that unlock chunking improvements (we’ll go into what ‘chunking’ is below). Rolldown even matches and at times outperforms esbuild’s bundling speed, while providing all of those new capabilities. This means, Framer sites still publish very fast, all while we’re optimizing them to become faster and faster for visitors.

We’re also proud that these innovations aren’t just available to us. Rolldown is open-source, so they benefit every other Rolldown and Vite user, making the web faster for millions of developers and websites.

If you prefer to hear more about technical insights, I’ve held a talk about it at the ViteConf 2025 – watch the video here.

The Results: Measurable LCP and JS Size Improvements

Let’s start with the numbers. Most important to us, are metrics that directly impact user experience and are recognized as key performance indicators by Google.

Largest Contentful Paint (LCP)

For LCP, we measure at the 75th percentile (p75), a standard Google uses for its ranking factors. The improvements are most dramatic for larger sites, where our optimizations have had the greatest impact:

• For very large websites (JS bundles >2MB), we saw an average LCP improvement of 41%*.

• For medium-sized websites (JS 1–2MB), the average LCP improved by 4%*.

• Across all Framer websites, we measured an 11%* drop in p90 LCP since starting the rollout. 

Improving the 90th percentile is notoriously difficult, because mostly older devices and slow Android phones fall into that category — so a double-digit improvement across the board is a result we're proud of.

JavaScript Size

A primary driver of these LCP gains is a massive reduction in JavaScript size. This means faster downloads and less work for the browser's CPU. We've recorded huge drops in both pre- and post-compression JS sizes (with/without Brotli or Gzip): median improvement of 36% (fewer bytes to download).

Factor 1: Granular Control Over JavaScript Chunking

Another significant advantage of Rolldown is the ability to finely tune our chunking strategy, a level of control we didn't have with our previous bundler, esbuild. Research from Google has shown there’s a “sweet spot” for the number of parallel requests a browser should handle, suggesting around 25 chunks is optimal for the best caching and loading performance.

Our old setup could generate nearly 100 chunks on large sites. With Rolldown, we've brought our numbers much closer to this ideal target:

As you can see, even large sites are now close to the sweet spot, and we plan to continue tweaking our configuration to optimize this further.

So, why does optimal chunking matter so much?

• Reduced Browser Overhead: Fewer JS modules lead to less Inter–Process Communication (IPC) overhead between the browser’s renderer (Blink) and its JS engine (V8) — see Chromium’s study.

• Reduced Network Overhead: While modern protocols like HTTP/3 (used by all Framer sites) are efficient, larger files compress better and reduce the cumulative overhead of request/response headers.

Experts like Harry Roberts have noted the continued importance of bundling even with HTTP/2+. In some cases, loading many small files from the browser cache can even be slower than a single, larger file from the network.

Factor 2: A Faster, More Efficient Bundling Engine

The second major factor is the raw efficiency of the new toolchain. Rolldown is powered by oxc-minify, which consistently outperforms esbuild in both minification speed and final asset size (benchmark). This plays a role in the significant JS size reductions mentioned earlier.

Additionally, our bundles are now much more efficiently split. For example, the code of our internal library, React, and our high-performance Animation library Motion are now split into three separate and consistent bundles. That means, if one of them updates, the others stay untouched — maximizing caching efficiency.

Both changes mean returning visitors have to download less JS when you to updates to your site. A smaller JavaScript footprint means less data congestion on the network and less CPU time spent on parsing and compilation, especially on lower-end devices.

Outlook: More improvements to come

Next to those immediate improvements, the switch to Rolldown gives us a better foundation for the future. This means we can now tweak and evolve the bundling strategy as web standards and best practices change. Like mentioned in the beginning, we already have plans for 2026:

1. Even faster publishing times for Framer users

2. Further reduce the amount of JavaScript Framer site visitors have to download

3. Boost the performance of our canvas

We hope the insights and the results made you as excited as us. Stay tuned for more updates in the future.