Browserslist-rs Gets Major Refactor, Cutting Binary Size by Over 1MB

The Rust implementation of Browserslist, the browser compatibility engine that powers much of the modern frontend toolchain, just received a major internal refactor. A newly merged pull request restructures how browser and feature data is stored in browserslist-rs, replacing most dynamic runtime data with statically embedded structures.

The result is a significant reduction in memory usage and binary size, including over 1MB saved in WebAssembly builds, with performance improvements that benefit tools like SWC, Rspack, Turbopack, and LightningCSS.

What is Browserslist?#

While you may not interact with it directly, your frontend stack almost certainly does. Browserslist sees over 60 million weekly downloads on npm and is embedded into most modern frameworks. Browserslist defines which browsers your code should support, using a simple query language like:

> 0.5%, last 2 versions, not dead

This config influences a huge swath of the frontend ecosystem:

• Autoprefixer for CSS prefixes
• Babel for JavaScript transpilation
• Stylelint, ESLint, and LightningCSS for feature support
• Webpack, Rspack, and Parcel for output targeting
• Frameworks like React, Next.js, and Vue rely on it out of the box

Browserslist is one of the most widely embedded tools in modern JavaScript development, and like many core infrastructure projects, it's now being reimagined in Rust for better performance and efficiency.

The Rust Implementation: browserslist-rs#

To support Rust-based build tools, the community maintains browserslist-rs, a native port of the JavaScript version. It replicates the core query evaluation logic but with much better performance and memory handling.

It’s already in wide use, with over 3.8 million downloads on crates.io across 30 published versions. The crate powers tools like SWC, Rspack, Turbopack, and LightningCSS, and is used in both native and WebAssembly builds.

The Refactor: Static Data for Performance and Binary Size Reduction#

The recently merged PR #32 overhauls how compatibility data is stored with goal of eliminating runtime overhead by embedding vendor and feature data directly into the compiled binary.

Key changes include:

• Embedding browser and feature data as static Rust slices
• Replacing JSON parsing and LazyLock structures
• Introducing PooledStr to reduce string duplication
• Using binary search instead of hash maps for lookups
• Bit-packing version strings for compact memory layout

While two small legacy LazyLock structures remain, the vast majority of the data is now statically compiled.

Benchmark Impact

The refactor delivers measurable benefits across native and WASM targets:

• 🔻 1.64MB smaller binary for Rspack
• 🧊 ~1MB reduction in WebAssembly builds, from 4.5MB to 3.5MB in release mode, according to benchmarks shared by the PR author
• 📉 Lower memory footprint
• ⚡ Query performance remained stable for common browser queries, with slightly higher lookup times for complex feature checks

These savings are especially impactful for tools shipping to constrained environments like CI containers, edge runtimes, or WebAssembly.

JavaScript Tooling Is Moving to Rust#

Browserslist' Rust implementation is part of a broader trend in the frontend ecosystem: moving performance-critical tooling out of JavaScript and into Rust.

Notable examples:

• SWC: Rust-based alternative to Babel, used by Next.js
• Turbopack: Rust-native bundler, successor to Webpack
• LightningCSS: Fast CSS parser and transformer used in Parcel
• Biome: Rust rewrite of Rome, a formatter/linter suite
• Parcel 2: Includes Rust-native components for key transforms
• Rolldown: A Rust port of Rollup for faster bundling
• Rspack: A Rust-based bundler compatible with Webpack's ecosystem
• oxc: A collection of Rust-based JavaScript tools including parser, linter, and formatter

Rust’s memory safety, predictable performance, and excellent compile-to-WASM story make it an increasingly attractive foundation for frontend infrastructure.

This refactor of browserslist-rs is a clear example of how deep, foundational engineering can ripple across the frontend toolchain. By eliminating most runtime data and switching to static, compile-time structures, the project has dramatically reduced its binary size and improved runtime efficiency, all while preserving compatibility with the widely used Browserslist query language.

As Rust-based tools continue to gain traction, optimizations like this will help make them not just faster, but leaner and more scalable as well.