/posts/customers-plaid.md
For more details on the PLAID developer experience team’s Rolldown implementation, see the blog post on PLAID's website.
TL;DR:
- PLAID’s server-side bundling dropped 97% during benchmarking after switching from
Rollup + TersertoRolldown + Oxc-minify - Rollup’s single-threaded JS architecture was limiting performance and improvement attempts like caching were ineffective
- Rolldown’s Rust architecture directly addressed Rollup’s constraints by enabling parallel processing and accelerating bundler operation
- Average production wait times decreased from 5-20 seconds to 200ms
PLAID, Inc. is a Japan-based company that developed KARTE, a customer experience (CX) platform. It enables businesses to create web campaigns, personalize communications, and improve overall customer experience.
KARTE features a no-code editor called “Flex Editor”, which lets the campaign manager customize pop-up campaigns on their website without coding. Pop-up changes are stored in the database and deployed to the campaign manager’s website. The latest pop-up version is loaded when a user visits the website.
The challenge: Slow server-side bundling
The Flex Editor’s biggest issue was performance. The same Rollup-powered compiler bundles the pop-up code in two separate cases:
- When the campaign manager made changes in the Flex Editor
- When the campaign manager deployed changes to their website
The PLAID developer experience team made client-side bundling optimizations to the Rollup-powered compiler for a snappy Flex Editor preview experience. However, the same optimizations could not be used for the pop-up’s server-side bundling because of different requirements. For example, Flex Editor client-side bundling had minification disabled because the code was already on the client.
The Rollup-powered compiler could take 5 - 20 seconds to server-side bundle before deploying the pop-up code. In other words, the campaign manager might be watching a deploying spinner for up to 20 seconds while their changes deploy! A big difference from Core Web Vitals recommended <200ms interaction delays.
The solution: Rolldown’s Rust architecture
The PLAID developer experience team first tried caching to improve Rollup’s performance. Rollup’s moduleParsed hook was used to cache the AST each time a module was fully parsed. However, response times remained 5 - 20 seconds even with caching. It turns out campaign managers were frequently clicking save or using the Ctrl+S shortcut, which starts the server-side bundling process and bypasses the cached AST.
Another solution was needed. Rollup’s single-threaded JavaScript architecture was the performance bottleneck. The bundler was not designed with parallel bundling in mind. CPU-intensive operations, like minification, further degraded performance.
The PLAID developer experience team started exploring alternatives to Rollup for server-side bundling. Rolldown emerged as a possible solution because it specifically addressed Rollup’s performance challenges. Rolldown’s Rust architecture enables parallel processing and accelerates bundler operations like parsing JavaScript/TypeScript and removing dead code.
"I verified Rolldown’s bundling behavior in my OSS projects, confirming proper operation and faster bundling than Rollup"
Kazupon, Engineer, PLAID
For most projects, migrating from Rollup to Rolldown is a straightforward, drop-in replacement. Rolldown maintains API compatibility with the major existing Rollup plugins for easy migration. However, KARTE uses the same Rollup-powered compiler for both the client and server. They wanted to keep Rollup for the client-side bundling and continue to use a single source, avoiding code complexity and higher maintenance load.
The team accomplished this with a plugin that replaces import { rollup } from 'rollup' with import { rolldown as rollup } from 'rolldown' based on the environment. The custom switching logic eliminated the need for Rolldown-specific code in the compiler and worked because of Rolldown’s compatibility with Rollup.
The results: 97% faster build times
After switching from Rollup to Rolldown, the build times improved dramatically. Switching from Rollup + Terser to Rolldown + Oxc-minify dropped the average build time from 1150ms to 40ms, or a 97% decrease, during benchmarking.
However, the size of the bundle increased when using Rolldown + Oxc-minify. The team had to consider trade-offs. Their primary goal was to improve user experience. Even though the bundle would be slightly larger, the improved speed and reduced infrastructure costs drove the decision to adopt Rolldown.
The results were consistent in production. The previous 5 to 20 second waiting time dropped to less than 200ms, which complies with Core Web Vitals recommended 200ms interaction delays.
Next steps
Rolldown is in beta, and the PLAID developer experience team continues to monitor its progress and make updates. Improvements to Rolldown + Oxc-minify have already been made, which reduced bundle sizes.
In addition to using Rolldown in their compiler, the PLAID developer experience team replaced Vite with Rolldown-Vite in the Flex Editor project. Frontend build time got 16x faster!
