Smaller, Leaner, Faster, Stronger: Dynamic’s New JS Client Cuts Package Size by 85%

Over the past few months, we’ve been working on making our auth and wallet libraries leaner and more flexible for developers. This latest comparison between our React SDK and the new client library highlights the progress we’ve made: the client library is ~85% smaller, which translates into noticeably faster page loads, lower bandwidth usage, and simpler caching behavior for end-users who expect fast, responsive performance.

It’s worth noting, though, that the React SDK remains the fastest way to get started and is ideal for teams who want prebuilt components out of the box. The client SDK is better suited for teams prioritizing performance or fully custom UI experiences.

Here’s What We Tested

To understand the impact of these improvements, we ran a side-by-side evaluation of two packages that solve the same auth and wallet problem through different approaches. The production release was @dynamic-labs/[email protected] and the alpha release was @dynamic-labs-sdk/[email protected]. The React SDK ships full UI components and utilities, while the client SDK focuses on core logic without UI, which lets product teams compose their own interfaces.

Performance by the Numbers: Our Findings

Size and dependency count set the stage for performance. The current React SDK measures 2.0 MB minified and 468 KB gzipped, while the new client SDK measures 348 KB minified and 52 KB gzipped, a reduction of ~89%. Direct dependencies drop from 24 to 7, which is a 70 percent reduction. This wasn’t just a lucky outcome. We intentionally designed the client SDK to minimize bundle weight and dependencies while keeping the core logic intact.

Here’s an easy way to picture it: The React SDK is like showing up with a moving van, you’ve got every piece of furniture, tools, and extras packed inside, whether you need them or not. The client SDK is the lightweight backpack, bringing only the essentials, easy to carry, and fast to unpack.

Here are the detailed results:

• Bundle size and dependencies: Minified sizes are 2,010 KB versus 348 KB, gzipped sizes are 480 KB versus 54 KB, and direct dependencies are 24 versus 7.
• Package type and peers: The React SDK is a UI-forward React package with React and React DOM as peer dependencies, while the client package is a core library with no peer dependencies.
  
  

Why Developers Should Care

• Faster initial page loads: Shrinking the gzipped download by nearly 90% was one of our primary goals, so your UI can become interactive as quickly as possible.
• Lower bandwidth across visits: By designing a smaller artifact, we reduce transfer costs for users and make repeat visits noticeably faster, even when caches partially expire.
• Better mobile experience: We optimized for low payloads to support users on flaky networks and older devices where CPU and memory constraints amplify bundle weight.
• Simpler caching strategies: The leaner core was built with long-term caching in mind, so unrelated updates don’t invalidate large chunks of your app.
  
  

What’s in Each Package and How They Compare

The size gap comes from what each package is designed to deliver. Here’s how we structured them:

@dynamic-labs/[email protected]

• Type: Full React SDK with built-in UI components.
• Bundle Size: 2.0 MB minified / 468 KB gzipped.
• Dependencies: Includes formik, react-focus-lock, react-i18next and i18next, yup, qrcode, country-list, phone input components, and several internal @dynamic-labs packages.
• File Breakdown:
  
  • ESM sources: 16 KB (3 KB gzipped)
  • CJS sources: 24 KB (4 KB gzipped)

@dynamic-labs-sdk/[email protected]

• Type: Headless core client library (no UI components).
• Bundle Size: 348 KB minified / 52 KB gzipped.
• Dependencies: Includes @dynamic-labs/sdk-api-core, @simplewebauthn/browser, zod, eventemitter3, and buffer utilities.
• File Breakdown:
  
  • ESM sources: 124 KB (27 KB gzipped)
  • CJS sources: 136 KB (28 KB gzipped)
    
    

An Overview of Dependency Reductions

• Direct dependencies: The client package cuts direct dependencies by about 70 percent, which reduces supply-chain risk and reduces surface area.
• React specificity: The client package removes React-specific peers entirely, which helps in non-React frameworks and mixed stacks.
• Form and i18n libraries: The client package excludes form libraries such as formik and yup and internationalization systems such as i18next and react-i18next, which removes weight that custom UIs may not need.
• UI utilities: The client package omits utilities like qrcode, country-list, and phone input components, which keeps the core focused on authentication.
  
  

Tree Shaking: Analysis, Results, and Why It Matters

Tree shaking effectiveness depends on export structure and module boundaries. The React core package uses a single barrel file with 200+ named exports, ships ESM with a CJS fallback, does not declare sideEffects, and centralizes imports in a monolithic index. This makes dead-code elimination difficult.

Tree shaking was another area we specifically targeted. The client package was designed with granular entry points and side-effect-free modules so bundlers can drop unused code.

Here are the results from our analysis:

• React SDK (minimal import): 1.76 MB minified / 431 KB gzipped — most of the 2 MB bundle still ends up in production.
• Client SDK (minimal import): 61 KB minified / 20 KB gzipped — a dramatic reduction, showing strong dead-code elimination.
• Client SDK (/core import): 56 KB minified / 18 KB gzipped — even leaner for the same capability.

The React SDK does not tree shake effectively. Even small imports bring along most of the codebase. The client package solves this by letting bundlers retain only what your app actually calls. This means smaller production builds, faster initial loads, and lower long-term bandwidth costs.

Choosing the Right Package for Your App

Both SDKs reflect our commitment to serving different developer needs. The React SDK remains the fastest way to get started, while the client SDK gives teams a leaner, more customizable foundation for performance-critical apps or fully bespoke authentication flows.

Here’s how to decide:

• Standard React builds: Use @dynamic-labs/sdk-react-core when you want prebuilt components and the fastest path to production with familiar React patterns.
• Custom UI builds: Choose @dynamic-labs-sdk/client when you plan to design your own authentication flows and want a bundle that’s roughly 83% smaller minified than the React SDK.
• Non-React frameworks: Use the client package in Vue, Svelte, vanilla JS, or mixed stacks where React peers aren’t a fit.
• Performance-critical apps: Go with the client package when first-load speed matters most, as its gzipped download is about 89% smaller, leading to faster page loads and better experiences on mobile and slow networks.
  
  

Quick Start Paths

• React path for speed: npm install @dynamic-labs/sdk-react-core for ready-to-use components that match common authentication flows.
• Headless path for control: npm install @dynamic-labs-sdk/client to build custom UIs with the smallest possible runtime footprint.

Both paths are actively supported and part of our ongoing effort to make Dynamic as flexible and performant as possible.