Preactとは？Reactとの違いと採用判断を実装目線で解説【2026年8月版】

Preactは、Reactとほぼ同じ書き味を保ったまま、コアをgzip後3kB前後に抑えたUIライブラリです。npm registryで2026年8月1日に確認した最新版は10.29.7（公開2026年7月8日）で、次期メジャーの11系はbetaタグの11.0.0-beta.2に留まっていました。この記事では3kBという数値の内訳、合成イベントを持たないことから生じる書き換え箇所、preact/compatでReact資産を移す手順、signalsとフックの責務分担、そして受託開発で採用してよい案件と見送る案件の線引きまでを扱います。バンドルサイズの1桁削減を狙う場面で、どこまでReactの書き方が通用するかが判断の軸になります。

まとめ：Preactを採用してよい条件と見送るべき案件の線引き

結論から示します。Preactを採る価値があるのは、配信バイト数が体験や計測値に直結する画面、具体的には外部サイトへ埋め込むウィジェット、単発のキャンペーンページ、通信環境の悪い現場で使う入力端末向け画面です。React本体とReactDOMを合わせた40kB前後（gzip後）が3kB前後に置き換わるため、初回描画までの転送量の差がそのまま効きます。

逆に見送るべき案件もはっきりしています。React Server Componentsを前提とした構成、React Nativeとコンポーネントを共有する計画、社内に大量のReact向け社内ライブラリが既にある環境。この3つに当たる場合、preact/compatで吸収しきれない差分の調査に時間が溶け、削減した37kBに見合いません。バージョンは10.29系を選び、11系のベータは検証環境に留める。以降の章では、この判断を支える実装差分と数値を順に見ていきます。

Preactの定義とReactサブセットとしての立ち位置・3kB構成の中身

PreactはReactのフォークではなく、同じコンポーネントモデルと仮想DOMの考え方を独自に実装し直したライブラリです。APIの形はReactに寄せてありますが、内部の作りは別物になります。

gzip後3kB前後というサイズの内訳とReact本体との差

Preactが3kBを名乗れるのは、Reactが内部に抱えている機能の一部を最初から持たないためです。代表格が後述する合成イベントシステムで、Preactはブラウザ標準のaddEventListenerをそのまま呼びます。スケジューラやプロファイラ向けの計装も本体には含みません。React（react）とReactDOM（react-dom）を合わせた配信サイズはgzip後でおよそ40kBなので、単純な差は37kB前後です。ここにpreact/compatを足すと差は縮みますが、それでも二桁kBの削減が残ります。

npm実測で見る10.29系の現在地とbeta・legacyタグの扱い

バージョンの現在地を数字で押さえておきます。2026年8月1日時点のnpm registryでは、latestタグが10.29.7（2026年7月8日公開）、betaタグが11.0.0-beta.2、legacyタグが8.5.3でした。10.29.2が2026年5月17日、10.29.5と10.29.6が7月7日と、パッチの間隔は数週間から1日単位まで幅があります。実務では10.29系をキャレット指定で追う運用が現実的で、legacyの8系は2017年前後のプロジェクトを触るとき以外に選ぶ理由がありません。

仮想DOMを保ちながらDOM APIへ直結させた設計の考え方

Preactは仮想DOMそのものは捨てていません。差分計算を行い、必要な箇所だけ実DOMへ反映する流れはReactと同じです。違うのは抽象化の層の厚みで、イベントも属性もブラウザのAPIへ素直に渡す設計です。この設計のおかげで、DOMを直接触る既存スクリプトやWeb Componentsとの同居が素直に進みます。同じ「軽量」を名乗るライブラリでも、仮想DOMを持たずHTML属性で状態を書くAlpine.jsの18ディレクティブによる実装とは設計の出発点が異なり、コンポーネント分割の粒度も変わります。

ReactとPreactの実装差分｜イベント・属性・非対応APIの具体

移行コストの実体は、この章に挙げる差分の数で決まります。公式ガイド「Differences to React」に明記されている項目を、書き換えが発生する順に並べます。

合成イベント非搭載によるonInputとonDblClickへの書き換え

PreactはReactの合成イベント（Synthetic Events）を実装していません。公式ガイドの表現では、ブラウザ標準のaddEventListenerでハンドラを登録します。実装上の影響が最も大きいのはフォームで、ReactのonChangeに相当するものはonInputになります。ダブルクリックもonDoubleClickではなくonDblClickです。さらにPortalを越えてイベントがバブリングしない点も明記されており、モーダル内のクリックを外側で拾う設計を持ち込むと動きません。preact/compatを噛ませればonChangeは内部でonInputへ変換されますが、Portal越しのバブリングは別問題として残ります。

classとclassNameの併用可否とSVG属性をそのまま書ける利点

属性の扱いはPreactのほうが緩く、classとclassNameのどちらも受け付ける仕様です。SVGについては公式ガイドが「属性を書かれたとおりに適用する」と述べており、デザイナーから受け取ったSVGをキャメルケースへ直さずに貼れます。stroke-widthやfill-ruleをそのまま置けるため、アイコンを大量に扱う画面では効果が明確です。ただしReactへ戻す可能性がある資産では、あえてclassNameとキャメルケースで書き揃えておくほうが後の手戻りが減ります。

Preact本体が持たない機能と互換レイヤで補える範囲の対応表

本体だけで足りるか、compatが要るかを事前に仕分けておくと見積りがぶれません。主要な項目を整理します。

表の最終行だけは差分ではなく、Reactから来た人が驚く箇所として挙げました。contextTypesの宣言が要らないのは、getChildContextが生んだ値を全コンポーネントが受け取る仕様のためです。

preact/compatによるReact資産の移行手順とエイリアス設定

既存のReactコードを動かす場合、コードを書き換えるのではなく解決先を差し替えます。公式ドキュメントはcompatを「Reactとの100%互換を目指すPreactの薄い層」と説明しています。

Viteとwebpackで解決先を差し替える手順と検証の順番

導入は次の順で進めると戻しやすくなります。

1. preactと互換層のパッケージを追加し、reactとreact-domは削除せず残す
2. ビルド設定のresolve.aliasで、reactの解決先をpreact/compatへ向ける
3. TypeScriptのpathsにも同じ対応を書き、型解決をビルドと揃える
4. フォーム、モーダル、外部UIライブラリの3系統を先に手動確認する
5. 問題が出た画面だけaliasから除外し、Reactのまま残すか書き換えるかを判断する

aliasを戻せば元のReactビルドに復帰できるため、いきなり全画面を切り替えず、ルーティング単位で試すのが安全です。

React資産の移行で詰まりやすいテスト系パッケージと型定義のずれ

詰まる箇所には傾向があります。react-dom/test-utilsやReactの内部構造に触れるテストユーティリティ、Reactのバージョン判定で分岐する外部UIライブラリ、そして@types/reactを前提に型付けされた社内コンポーネントの3つです。特にReact 19で追加されたAPIに依存したコードは互換層の守備範囲外に落ちやすく、レンダリングの前段でエラーになります。React19で追加された機能の一覧を先に照らし、依存している新APIを洗い出してから移行判断に入ると空振りが減ります。

React資産の移行を進める損益分岐と途中で引き返すべき判定条件

判断の目安を数字で置きます。aliasを当てて主要3系統の確認が半日で終わるなら進めてよい。逆に、外部UIライブラリの差し替え検討が発生した時点で引き返すべきです。UIライブラリ1本の置き換えは、削減できる37kBに対して数人日を要することが多く、割に合いません。既存コードが少ない新規開発なら、最初からPreactで書き始めるほうが移行作業そのものを消せます。

@preact/signalsとフックの使い分け｜状態管理の実装判断

状態管理には、Reactと同じフックに加えてsignalsという選択肢があります。どちらか一方に寄せる必要はありません。

signalsパッケージの公開状況と再描画範囲が変わる仕組みの違い

npm registryで2026年8月1日に確認したところ、@preact/signalsの最新版は2.10.1（2026年7月31日公開）でした。signalsは値の読み取りを追跡し、その値を実際に使っている箇所だけを更新する仕組みです。コンポーネント全体を再実行するフックの再描画とは、更新の粒度が違います。依存追跡を意図的に外すuntrackedや、派生値を作るcomputedの挙動は、untrackedとcomputedシグナルの使い分けで他フレームワークの実装と並べて整理しています。

signalsを入れる場面とフックのままで足りる場面の線引き

signalsを入れる価値があるのは、1秒間に何度も値が変わる表示、たとえばリアルタイム集計やカーソル追従、進捗バーを持つ画面です。逆に、フォーム入力と送信が中心の管理画面ではuseStateで十分で、signalsを足すとレビュー時の読解コストだけが増えます。3kBを選んだプロジェクトに、追加の依存を無条件で足すのは筋が通りません。判断は画面ごとに分けるのが現実的です。

Preactが向く案件と外れる案件｜受託開発での採用条件の線引き

ここからは、実際に見積りを立てる側の視点で判断を言い切ります。技術的に動くかどうかと、案件として採るべきかは別の問題です。

Preactを採用してよい案件の条件と配信サイズ削減が効く画面の共通点

採用してよいのは、次の条件に当てはまる案件です。第一に、第三者サイトへ埋め込むウィジェットのように、こちらが配信するJavaScriptの量に制約がある場合。第二に、島単位でUIを差し込む構成をとる場合で、Deno FreshのアイランドアーキテクチャのようにPreactを前提とするフレームワークを採るときは選択自体が済んでいます。第三に、通信が細い現場端末向けの画面。いずれも「初回に送るバイト数」が体験に直結する点が共通します。

Preact採用を見送る案件の条件と保守で破綻しやすい構成の共通型

見送るべき構成も明示します。React Server Componentsを使う前提の設計、React Nativeとコンポーネントを共有する計画、Reactのバージョンを厳密に前提とした有償UIコンポーネントを組み込む案件。この3つでPreactを押し通すと、互換層の穴を塞ぐ改修が積み上がり、削減した数十kBの価値を人件費が上回ります。「軽いから」だけを根拠に選ぶ判断は、ここで破綻します。React本体でよい場面のほうが依然として多い、というのが実務上の結論です。

開発見積りと保守計画で織り込むべき互換レイヤの継続運用コスト

互換層を挟む構成は、保守フェーズで固有の作業を生みます。Reactの新バージョンが出るたびに互換層の追随状況を確認する手間、ライブラリ更新時に本体とcompatのどちらの問題かを切り分ける手間です。この工数を見積りへ最初から織り込んでおくと、後の追加請求をめぐる衝突を避けられます。フロントエンドの構成選定から保守までを含めて外部に任せる前提であれば、業務用・Webアプリ開発の受託のように、技術選定の根拠と運用体制をセットで提示できる相手を選ぶと判断がぶれません。

Preact 11ベータの現状と本番開発で10.29系を選ぶべき理由

次期メジャーの扱いも、選定時に必ず聞かれる論点です。数字で状態を確認しておきます。

11.0.0-beta.2の到達点と本番投入を見送る判断の根拠

2026年8月1日時点で、npmのbetaタグが指すのは11.0.0-beta.2です。latestタグは10.29.7のままで、11系はまだ安定版として配布されていません。ベータの版番号が2に留まる段階では、破壊的変更の追加余地が残ります。受託案件で納品する構成に選ぶ理由は、現時点では見当たりません。検証環境で挙動を見ておく価値はありますが、本番の依存に入れる判断は保留にします。

10.29系で開発しながら11系への移行余地を残す実装規約と書き方

将来の移行を軽くする書き方は決まっています。preact/compat経由の呼び出しを一箇所にまとめ、独自のラッパーコンポーネントを挟んでおく。加えて、レンダリング方式の選択を本体のコードから切り離しておくと、後から構成を差し替えやすくなります。SSR・CSR・SSGの違いと使い分けを踏まえ、どの方式で配信するかを先に固めてからライブラリを選ぶ順序にすると、メジャーアップデートの影響範囲が読めます。

よくある質問

Preactの採用検討でよく挙がる質問に、実装と判断の両面から答えます。

PreactはReactの完全な代替として全面採用できますか？

全面採用が成立する条件は限定的です。Preact単体ではReactの合成イベントやPropTypes、Children APIを持たず、preact/compatを噛ませても100%互換は「目指す」水準です。新規開発でReact専用の外部ライブラリに依存しない構成なら全面採用できます。既存のReactアプリを丸ごと置き換える場合は、外部UIライブラリとテストユーティリティの2点を先に検証し、通らなければ画面単位の部分適用に留めるのが安全です。

Preactの3kBという数値には何が含まれていますか？

3kB前後という数値はPreactコアをgzip圧縮した状態を指します。互換層のpreact/compatや、@preact/signalsなどの追加パッケージは含まれません。ReactとReactDOMを合わせたgzip後およそ40kBと比較した差が37kB前後で、compatを足すとこの差は縮みます。実際の削減量はビルド構成で変わるため、導入前後でバンドル解析ツールの出力を比較して確認してください。

Next.jsやReact Server ComponentsはPreactで動きますか？

React Server Componentsを前提とする構成はPreactの守備範囲外と考えてください。サーバー側でコンポーネントを実行しシリアライズする仕組みはReact本体と密結合しており、互換層で吸収できる範囲を超えます。サーバーレンダリングを含む構成でPreactを使うなら、Deno FreshやAstroのようにPreactを前提に設計されたフレームワークを選ぶほうが破綻しません。

PreactとAlpine.jsはどちらを選ぶべきですか？

判断軸は「コンポーネントを組み立てるか、既存HTMLへ振る舞いを足すか」です。JSXでUIを分割し、状態を持つ画面を作るならPreactが適任です。サーバーが返すHTMLに対して開閉やタブ切り替えを足すだけなら、Alpine.jsのほうが記述量が少なく済みます。Reactの経験者が多いチームではPreactのほうが学習コストが低く、テンプレート中心の運用チームでは逆になります。

Preact 11の安定版が出るまで採用を待つべきですか？

待つ必要はありません。2026年8月1日時点で10.29.7がlatestとして配布されており、パッチも継続的に出ています。11系はbetaタグの11.0.0-beta.2の段階で、安定版の時期は確定していません。今作るなら10.29系で進め、compat経由の呼び出しを一箇所へ集めておくことで、11系が安定した後の移行作業を小さくできます。

関連記事

• Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク：Preactを前提に設計されたフレームワーク側の解説です
• Alpine.jsとは？18ディレクティブの実装とCSP対応・採用判断：仮想DOMを持たない軽量フロントとの比較検討に使えます
• SPAとは？フロントエンド技術の全体像・フレームワーク・将来性：Preactが置かれている技術地図を俯瞰できます
• ReactとVue3の違いを比較｜どっちを選ぶべきか：React系以外を含めた選定の物差しを揃えられます
• Viteを使ったReactプロジェクトのセットアップ方法：エイリアス設定を試す土台となるビルド構成の解説です