Preact vs React Islands Bundle Size

Astro's islands architecture already limits JavaScript to the components that need it, but each island still needs its framework runtime. For React islands that means React and ReactDOM — about 44 KB compressed — on every page with at least one island, before any component code. On a documentation site where a small feedback widget and a theme-aware code copy button appear on nearly every page, that runtime is most of the page's JavaScript. Preact implements the same component API in about a tenth of the size, and Astro supports it with a compat layer that lets many React components run unchanged.

This guide measures what switching React islands to Preact changes on a 410-page Astro site with four islands: bundle size per page, hydration time and INP, the compatibility problems found, and a rule for when the switch pays off. It is part of JavaScript Hydration & Partial Rendering.

Prerequisites

• An Astro site with React islands (@astrojs/react).
• A list of islands, the pages they appear on, and the third-party React libraries they import.
• Lighthouse and the rollup-plugin-visualizer treemap for measuring bundles, as in Code Splitting and Module Preload in Vite-Based SSGs.

The Islands

The feedback widget and copy buttons put React on nearly every page, and together their own code was 6 KB — the framework was seven times larger than the components.

Step 1: Switch the Integration

Replace the React integration with Preact and enable compat, so existing imports of react resolve to preact/compat:

// astro.config.mjs
import preact from '@astrojs/preact';
export default defineConfig({
  integrations: [preact({ compat: true })]
});

npm remove @astrojs/react react react-dom
npm install @astrojs/preact preact

If some islands must stay on React — because of incompatible libraries — Astro can run both integrations at once, with include patterns telling each which files it owns: preact({ compat: true, include: ['**/islands/light/*'] }) and react({ include: ['**/islands/react/*'] }). Pages then load whichever runtime their islands need.

Step 2: Fix Compatibility Problems

The feedback widget and copy buttons worked unchanged. The two larger islands surfaced the typical problems:

• react-hook-form worked through compat.
• @tanstack/react-query v5 relied on useSyncExternalStore, which preact/compat supports, and worked; an older v3 had failed on a missing unstable_batchedUpdates export.
• react-json-view-lite worked.
• A useId call generated IDs in a format that differed between server and client in an older Preact version, causing a hydration mismatch warning; Preact 10.19+ fixed it.
• Event naming. Preact uses native DOM events; a handler relying on React's synthetic onChange firing on every keystroke for a <select> needed onInput.

Two hours of work and one Preact upgrade made all four islands run on Preact. A Playwright run of the interactive flows, as in End-to-End Tests for Static Sites with Playwright, confirmed behaviour matched.

Step 3: Measure

Lighthouse mobile, median of five runs, and field data from RUM over two weeks:

The API explorer pages, heavier because of their libraries, went from 118 KB to 82 KB. LCP barely moved, as expected: the LCP element is static text rendered before any island. The gains were in main-thread time and therefore INP.

Why Smaller Runtimes Help INP, Not Just Bytes

It is tempting to treat this as a transfer-size optimization, and on fast connections the 36 KB difference downloads in a few milliseconds. The larger effect is on the main thread. Every byte of JavaScript must be parsed, compiled and executed, and on a mid-range Android phone that costs far more than downloading it. React's client runtime does substantial work at startup — setting up the scheduler, the reconciler and event delegation — before the first island hydrates. Preact's startup is a fraction of that. In the Performance panel under 4× CPU throttling, the React version showed a 96 ms task evaluating the vendor chunk right as the feedback widget scrolled into view; with Preact, the equivalent task was 24 ms. A reader who tapped a link or a code tab during that window waited for it, which is exactly what INP measures.

The effect compounds with how islands hydrate. client:visible islands hydrate when they scroll into view, often while the reader is scrolling and about to tap something; a shorter hydration task there matters more than one during initial load, when readers are still reading. On pages where the feedback widget hydrated near the end of an article, where readers typically tap "next page", the INP improvement at p75 was 41 ms, larger than the site-wide 32 ms.

Parse and compile costs also vary by device more than download costs do. In the field data, the INP improvement for readers on devices Chrome classified as low-end was 58 ms, nearly twice the average, because those devices spend the most time on script evaluation. Byte savings are a proxy; main-thread time on the slowest devices is the result that matters.

When the Switch Pays Off

The benefit depends on how often the framework is loaded compared with how much component code runs on top of it. A simple rule from this site and two others:

• Switch when small islands appear on most pages and the framework is several times larger than their code — the common case on documentation and content sites.
• Consider a split (Preact for small islands, React for one complex one) when a single rarely visited island needs libraries that only work with full React.
• Do not bother when islands appear only on a few pages, or when pages already load React for other reasons such as a React-based search UI.
• Consider no framework at all for the smallest islands. The copy buttons could equally be a 0.6 KB vanilla module or a web component, as in Replacing React Islands with Web Components; on a later iteration the team did exactly that, and the feedback widget became the only Preact island on most pages.

Measured Impact

Pitfalls & Rollback

• Assuming every React library works. Test each dependency; libraries using React internals may fail.
• Mixing integrations without include patterns. Astro cannot tell which framework owns a .jsx file.
• Synthetic event differences. onChange on inputs and selects behaves like the native event in Preact.
• Old Preact versions. Several compat gaps were fixed in 10.19+; start from a current version.
• Rollback: switching back is reinstalling @astrojs/react and removing the Preact integration; component code is unchanged.

Conclusion

When a static site's islands are small and appear on most pages, the React runtime is the largest thing they ship. Preact with compat runs the same components for about a fifth of the size, with a few hours of compatibility fixes. On this site it cut docs page JavaScript by 70% and moved field INP from 124 ms to 92 ms — and made it obvious which tiny islands did not need a framework at all.

FAQ

How much smaller is Preact than React?

Preact's core is about 4.5 KB compressed and preact/compat about 3 KB more, while React plus ReactDOM for the client is around 44 KB compressed. On the Astro site measured here, switching four islands from React to Preact reduced shared framework JavaScript from 44 KB to 8 KB.

Can I switch without rewriting components?

Often. Astro's Preact integration with compat enabled aliases react and react-dom to preact/compat, so most components and many libraries run unchanged. Libraries that depend on React internals, concurrent features or newer hooks may not work.

Does Preact hydrate faster?

Yes, mainly because there is less JavaScript to download, parse and execute before hydration starts. On a throttled mobile profile, hydration of the same island took 38 milliseconds with Preact against 71 with React, measured from script start to interactive.

When is switching not worth it?

When pages load React anyway for other reasons, when islands depend on libraries that need full React, or when there is only one small island on rare pages. The benefit is largest when a few simple islands appear on most pages.

Related

• Parent: JavaScript Hydration & Partial Rendering — choosing what to hydrate.
• Astro Islands vs Full Hydration Performance — islands compared with full hydration.
• Replacing React Islands with Web Components — removing the framework entirely.
• Breaking Up Long Tasks on Static Sites — INP beyond bundle size.
• Tracking Bundle Size per Pull Request — keeping the savings.