次世代JavaScriptフレームワーク：QwikとSolidJS

要点 — この記事でいう「次世代」は、公式な分類ではなく Qwik と SolidJS をまとめるための呼び方です。両者は異なる仕組みでJavaScriptの起動処理を減らします。読み込み時に実行するJSが少なければ、ページは高速で応答しやすくなり、Core Web Vitalsにも有利です。ただし、コンテンツのクロール可能性や良好なスコアを保証するものではありません。実際に選ぶメタフレームワークのレンダリング方式で結果が決まります。

この記事でいう「次世代」とは

React、Vue、Angularなど多くのフレームワークは、ページのかなりの部分をブラウザで組み立てます。サーバーが完成済みのHTMLを返しても、通常はJavaScriptをブラウザでもう一度実行し、ボタンやメニューを動かすためのハイドレーションが必要です。ユーザーが操作しようとする瞬間にCPUを消費するため、この処理はページが重く感じられる大きな原因になります。

「次世代」は標準化されたWebプラットフォーム上の分類ではありません。ここでは、このコストをそれぞれ独自の仕組みで正面から減らそうとする2つのプロジェクトを指します。

• Qwik — 完成済みHTMLを送り、ハイドレーションではなく**再開（resumption）**します。小さなブートストラップスクリプトは読み込み時に動きますが、操作に必要なコードは実際にクリックされた時点で取得します。
• SolidJS — 完成済みHTMLを送り、ハイドレーションも行いますが、その仕組みが軽量で効率的なため処理量が大幅に減ります。

どちらも変化の速いプロジェクトです。Qwikは現在v2ベータ版で、SolidStartの文書にもベータと記載されています。以下の既定値や挙動は恒久的なものではなく、対象バージョンに限った説明として扱ってください。

SEOで実際に変わること

互いに独立した2つの事実があります。

1. コンテンツがHTMLに入るかは、フレームワークそのものではなく、選択したレンダリング方式で決まります。 Qwikの QwikCity とSolidJSの SolidStart は、ルートをサーバーレンダリングまたは静的生成し、テキストとリンクをHTMLに含められます。一方、SolidStartは純粋なクライアントサイドレンダリングにも対応し、その場合は一般的なSPAと同じ空のシェルになります。方式を誤れば「次世代」という名前はクロールに何の利点も与えません。一般的な仕組みは JavaScript SEO を参照してください。
2. 実行するJavaScriptが少なければCore Web Vitalsに役立ちますが、保証はありません。 実際のINPとTBTは、アプリのコード、第三者スクリプト、サーバー応答時間、端末条件にも左右されます。Core Web Vitalsはランキング 要因なので、推測せずフィールドデータで測定してください。

混同してはいけないこと

QwikとSolidJSをまとめて「再開可能なフレームワーク」と呼ぶのは誤りです。再開可能性はQwikの仕組みです。 SolidJSは再開せず、効率よくハイドレーションします。この違いを押さえれば、以降の説明が分かりやすくなります。

再開とハイドレーション、シグナルと仮想DOMの違い、React・Vue・Angularと比べた性能やSEOを詳しく知りたい場合は、Advancedタブへ進んでください。

要点 — 「次世代フレームワーク」は標準分類ではなく、この記事が Qwik と SolidJS をまとめるために使う編集上の呼称です。両者は異なる仕組みでブラウザのJavaScript実行コストを減らします。Qwik は再開可能性を採用し、リスナー、コンポーネント境界、状態をサーバーでHTMLに直列化します。ブラウザは全面的なハイドレーションを再生せず、必要な処理だけを再開します。ただし小さな Qwikloader は読み込み時に動き、操作時にハンドラーコードを遅延取得するため、JavaScriptが文字どおりゼロになるわけではありません。SolidJS はシグナルと仮想DOMを使わない細粒度リアクティビティにより更新範囲を限定しますが、再開ではなくハイドレーションを行います。リアクティビティとメタフレームワークのレンダリング方式は別の問題です。QwikCity と SolidStart はサーバーレンダリングHTMLを出せますが、SolidStartは純粋なCSRにも対応し、ルーターやメタデータライブラリを標準では同梱しません。クロール、インデックス、実測Core Web Vitalsは実際の方式と実装で決まり、フレームワークは保証しません。

両者が解決しようとする根本原因

JavaScript SEOで扱う「Googleがコンテンツを見られるか」は、SSR・SSG・CSRというレンダリング方式の問題です。QwikCityとSolidStartはサーバーレンダリングや静的生成に対応しますが、強制はしません。CSRを選べば基盤が何であれ空シェルのSPAになります。QwikとSolidJSが直接変えるのは、もう一方の問題、つまりHTML到着後に実行されるJavaScriptのコストです。

一般的なSSR＋ハイドレーション構成では、サーバーが完成済みHTMLを送り、初回描画とクローラーには有利です。しかしその後、フレームワークはコンポーネントコードを取得し、イベントハンドラーを結び付けて内部状態を再構築するため、ブラウザで再実行します。 ユーザーには完成して見えても操作できず、メインスレッドが塞がるため、このハイドレーション処理はラボの Total Blocking Time（TBT） とフィールドの Interaction to Next Paint（INP） を悪化させる大きな要因です。

QwikとSolidJSはいずれも、この処理を縮小または回避するために作られました。ただし経路は異なります。

Qwik：再開可能性（ハイドレーションはしないが、JSがゼロでもない）

Qwikの中心的な発想は再開可能性です。現在v2ベータ版のQwikはここで扱うリアクティビティ基盤で、QwikCityは後述する別のメタフレームワーク層です。QwikはサーバーでHTMLを生成し、処理を続けるために必要な状態、イベントリスナー、コンポーネントツリー、実行位置をHTMLへ直接直列化します。 ブラウザでコンポーネントを再実行して起動するのではなく、サーバーが止めた位置から再開します。

これはハイドレーションとは本質的に異なりますが、JavaScriptがゼロという意味ではありません。Qwikの文書では、圧縮後約1kb、モバイルで5ms未満に実行される小さな Qwikloader が、ページ読み込みのたびに動くとされています。役割は次のとおりです。

• 対話要素ごとではなく、単一のグローバルイベントリスナーを登録する。
• HTMLに書き込まれた on:click="./chunk.js#handler_symbol" 形式の属性（QRL、Qwik Resource Locator）を読む。
• イベント発生時に対応するQRLを解決し、該当ハンドラーのチャンクだけを遅延取得して実行する。

実務上の結果は次のとおりです。

• 起動時のJSは小さく、ほぼ一定ですが、ゼロではありません。 Qwikloader自体のコストはアプリ規模に応じて増えず、アプリ全体のハイドレーションもありません。ただしQwikloaderは実際にJavaScriptを実行します。「読み込み時JSゼロ」ではなく、「アプリ規模に比例するハイドレーションの代わりに、小さく一定規模のブートストラップを使う」と表現してください。
• ハンドラー単位の遅延読み込み。 アプリコードは実際に操作が起きた時点で読み込まれます。これがQwik作者のいう「HTML-first」です。
• QwikCity は、ファイルベースのルーティング、データローダー、アクション、エンドポイントを提供するQwikのメタフレームワークです。再開可能性だけでは、ルートのステータスコード、メタデータ、サーバーレンダリングの有無は決まりません。QwikCityのルーティングとレンダリング設定で決まります。

実務で再開可能性が破綻する箇所

Qwikの現在の直列化・状態管理文書によると、採用前に理解すべき制約があります。

• 直列化の境界。 $(...) 境界内のコードが捕捉できるのは、プリミティブ、const に束縛された直列化可能なデータ、PromiseなどQwikが対応する一部の組み込み型です。独自クラスのインスタンスなど未対応の値は静的解析を通っても、Qwikが直列化する実行時に失敗します。本番まで表面化しない可能性があるためテストが必要です。
• noSerialize() の値は再開後に残りません。 明示的に直列化対象外とした値は、SSR/SSG状態からクライアントが再開すると undefined になります。通常は useVisibleTask$() 内でクライアント側の再初期化が必要です。
• useVisibleTask$ は早期実行されるブラウザ専用の回避策です。 Qwik自身も最後の手段としています。初回描画後にブラウザだけで動き、“eagerly executes code on the client” (翻訳) 「クライアントでコードを即時実行します」。既定ではIntersection Observerにより可視時に実行されますが、{ strategy: 'document-ready' } を指定すると読み込み直後に動きます。多用すると、再開可能性が避けようとする起動コストを再導入します。

SEOの観点では、QwikCityルートの初期HTMLにコンテンツと <a href> リンクが含まれるかは、レンダリング方式とルーティングの問題です。再開可能性だけでは保証されないため、フレームワーク名ではなく実際の応答を確認してください。Googleが必要とする内容はクロールを参照してください。現実的な利点は実行時側にあり、起動JavaScriptがメインスレッドを塞ぐ量を減らせます。これはCore Web Vitalsの一因ですが、特定のINPやTBTを保証しません。

SolidJS：細粒度リアクティビティ（効率的なハイドレーションであり、再開ではない）

SolidJSは別の角度から同じコストを減らします。Solidというリアクティビティエンジンと、SolidStartというメタフレームワークは別物です。Solidの核はシグナルに基づく細粒度リアクティビティで、仮想DOMを使いません。

• 再レンダリングではなくシグナル。 Reactでは状態変更時にコンポーネント関数を再実行し、仮想DOMの差分を調べます。Solidではコンポーネント関数は一度だけ実行され、createSignal のgetter/setterと createEffect などの購読者が依存関係を直接追跡します。シグナルが変わると購読するコードだけが再実行され、コンポーネント再実行も仮想DOM差分もありません。そのため更新量の多いjs-framework-benchmarkで上位に入りますが、数値はバージョンごとに変わるので現行結果を直接確認してください。
• SolidJSはハイドレーションを行い、再開可能なフレームワークではありません。 サーバーレンダラーがHTMLを生成し、クライアントがそれをハイドレーションします。Qwikの再開とは異なる仕組みです。細粒度リアクティビティと仮想DOMを使わない設計により再構築量は少なくなりますが、実際のコストはルートが送る対話コード量に依存します。「SolidJSは再開可能」と説明しないでください。
• SolidStart はルーティング、サーバー関数、デプロイ用プリセットを提供するメタフレームワークです。現在の文書（v1.0、ベータ表記、2026-04-28更新）は、CSR、SSR（同期・非同期・ストリーミング）、SSG の3方式を示しています。リアクティビティはどの方式でも同じですが、初期HTMLにコンテンツが入るかは方式で決まります。また、SolidStartはルーターやメタデータライブラリを標準同梱しないため、別途追加が必要です。

SEOでは、SolidStartルートのコンテンツとリンクが初期HTMLに入るかは3方式の選択で決まります。CSRだけなら一般的なSPAと同じ空シェルです。SSRまたはSSGなら JavaScript SEO が求めるようにコンテンツをHTMLへ入れられます。小さなランタイムと細粒度更新はハイドレーションの処理量を減らしますが、それだけでTBTやINPの値は決まりません。

違いを端的に整理する

この違いが記事全体の正確性を支えるため、用語を厳密に使ってください。

• Qwik＝再開可能性。 全面ハイドレーションは行いません。小さくほぼ一定規模のQwikloaderは読み込み時に動き、アプリコードは操作時に遅延取得されます。サーバーで直列化した状態から再開します。
• SolidJS＝細粒度リアクティビティ＋ハイドレーション。 仮想DOMを使わず、シグナルが依存関係を追跡しますが、ハイドレーションは行います。再開可能性ではありません。

どちらも典型的な仮想DOM＋全面ハイドレーション構成よりブラウザのJavaScript処理を減らしますが、仕組みは異なり、JavaScriptを完全にはなくしません。「再開可能性＝JSゼロ」と考えること、SolidJSを再開可能と呼ぶことが、この組み合わせで最も多い誤解です。

隣接する比較対象：Astroのアイランド

同じ議論に登場する Astroのアイランドアーキテクチャ は、第3の仕組みです。Astroは既定で通常のサーバーレンダリングHTMLを送り、クライアントディレクティブを使って特定コンポーネントだけを「アイランド」としてハイドレーションします。ページの大半はコンポーネントJavaScriptを送りません。対話が必要な範囲を考える比較には有用ですが、Qwikの再開でもSolidの細粒度リアクティビティによるハイドレーションでもなく、静的ページの一部だけをハイドレーションする方式です。Qwikの文書もこの理由から再開可能性と部分ハイドレーションを区別しています。

既存フレームワークとの比較

既存フレームワークが既定でSEOに弱いわけではありません。適切なレンダリング方式なら、どのメタフレームワークもクローラーが必要とするコンテンツをHTMLに入れられます。これは JavaScript SEO の中心的な論点で、SolidStartとQwikCityも同じです。表の違いはブラウザ起動コストの仕組みであり、結果の保証ではありません。選択だけで決めつけず、実際のルートでTBTとINPを測ってください。

React、Vue、Angularも、シグナルや軽量なハイドレーションへ進んでいます（Angular Signals、React Server Components、Vue Vapor modeなど）。バージョンやロードマップはすぐ変わるため、具体的な機能を引用する前に各フレームワークの現行文書を確認してください。

自分のルートで検証する方法

特定ルートの答えをフレームワークの評判だけで決めず、ルートごとに確認します。

• ステータスコードと初期HTML — ブラウザが描画したDOMではなくURLを直接取得し、コンテンツ、リンク、メタデータが含まれるか確認する。
• ストリーミング出力 — ストリーミング方式なら、読み込み状態のシェルだけでなく全文が届くか確認する。
• メタデータとリンク — title、meta description、canonical、<a href> の遷移先を確認する。再開可能性も細粒度リアクティビティも自動管理しない。
• 直列化状態のサイズ（Qwik） — ハイドレーションを避けても、大きな状態はHTML容量を増やす。
• 初期ローダー／ランタイムJS — 文書の主張ではなく、読み込み時にQwikloaderやSolidランタイムが実際に何をするか測る。
• プリフェッチと操作時リクエスト — クリック時と事前読み込み時の通信をネットワークパネルで区別する。
• ブラウザ専用タスク — useVisibleTask$ などが毎回早期実行されていないか確認する。
• JavaScript失敗・遮断時の挙動 — 利用可能な状態へ劣化するか、完全に壊れるか確認する。
• 代表的なクローラーの描画結果 — View Sourceだけでなく、Search ConsoleのURL検査などで描画後にしか現れない内容も確認する。

これはJavaScriptで描画するサイトすべてに必要な検証です。Googleの一般的な処理はレンダリングを参照してください。

次に読むもの

各フレームワークには個別の詳細ガイドがあります。

• Qwik SEO — 実務での再開可能性、QwikCityのルーティングとSSR、メタデータ、useDocumentHead、遅延読み込み境界、フィールドCWVへの影響。
• SolidJS SEO — シグナルと細粒度リアクティビティ、SolidStartのSSRとストリーミング、再開可能ではない理由、metaタグ管理、ベンチマークの読み方。

どちらも JavaScript SEO クラスターに属し、React、Vue、Angular、Next.js、Nuxt、Svelte、Astroのガイドと並びます。指標は Core Web Vitals、Googleから見た描画内容はレンダリングを参照してください。

AIによる要約

Advanced版の要点を短くまとめます。

• 「次世代」はこの記事独自の編集上の呼称で、QwikとSolidJSを指します。標準分類ではなく、両者は異なる仕組みでブラウザのJavaScript実行コストを減らします。Qwikはv2ベータ、SolidStart文書もベータ表記で2026-04-28更新のため、詳細はバージョン限定です。
• Qwik＝再開可能性であり、JavaScriptゼロではありません。サーバーでリスナー、境界、状態をHTMLへ直列化し、ブラウザはハイドレーションではなく再開します。約1kbでモバイル5ms未満と説明される Qwikloader がグローバルリスナーを登録し、操作時にQRLのハンドラーを読み込みます。$ 境界の未対応値は実行時に失敗し、noSerialize() 値は再開後 undefined になり、useVisibleTask$ の多用は起動コストを戻します。QwikCity は別のルーティング層です。
• SolidJS＝細粒度リアクティビティで、再開可能ではありません。シグナルと仮想DOMなしの設計で更新を限定しますが、ハイドレーションします。SolidStart はCSR、同期・非同期・ストリーミングSSR、SSGを選べる別のメタフレームワークで、ルーターやメタデータライブラリは標準同梱しません。
• クロール可能性、メタデータ、ステータスコードは方式とルーティングの問題です。CSRなら空シェル、SSR/SSGならコンテンツをHTMLに入れられます。実際の応答を確認してください。
• Core Web Vitalsや順位を保証する仕組みはありません。 起動JSはINPとTBTの一因ですが、アプリコード、第三者処理、サーバー、端末も実測値を決めます。CrUXやSearch Consoleのフィールドデータで検証します。
• React・Vue・Angularとの比較： 適切な方式なら既存フレームワークもクローラー向けにSSRできます。違いは起動JSの仕組みで、主流側もシグナル、RSC、Vapor modeなど近い発想を取り入れています。
• Astroのアイランドは第3の別方式です。既定はサーバーHTMLで、必要なアイランドだけをクライアントで動かします。

公式ドキュメント

各フレームワーク自身が公開する一次資料です。

Qwik（現在v2ベータ。既定値を引用する前にバージョンを確認）

• Qwikドキュメント — 公式文書の入口。
• Think Qwik / Resumable — リスナー、ツリー、状態の直列化を含む、再開可能性とハイドレーションの違い。
• Qwikloader — 読み込み時に動くブートストラップ。グローバルリスナー登録、QRL解決、ハンドラー遅延読み込み。
• Serialization and Serialization Boundaries — $ 境界と、捕捉値を直列化できない場合の実行時失敗。
• State / noSerialize — 直列化しない値が再開後 undefined になる理由。
• Tasks and Lifecycle — useTask$ と useVisibleTask$ の実行・可視性の違い。
• QwikCity概要 — ルーティング、ローダー、アクション、エンドポイントを提供するメタフレームワーク。
• useDocumentHead / DocumentHead — SEO用のtitleとmetaタグ管理。

SolidJS（SolidStart文書はベータ表記、2026-04-28更新。既定値を引用する前に確認）

• SolidJSドキュメント — 公式文書の入口。
• Reactivity / Signals — 細粒度リアクティビティ、シグナル、購読者。
• SolidStart概要 — レンダリング方式と、ルーター／メタデータライブラリを標準同梱しない設計。
• SolidStartのレンダリング方式 — CSR、同期・非同期・ストリーミングSSR、SSGの選択肢。

比較境界

• Astro — Islands architecture — 既定のサーバーHTMLと任意のクライアントアイランド。再開可能性やSolidのハイドレーションとは異なる第3の仕組み。

Google検索／ベンチマーク／背景

• JavaScript SEOの基本を理解する — 取得、レンダリング、インデックス登録を別工程として説明するGoogle公式資料。
• js-framework-benchmark — 広く参照される横断ベンチマーク。固定値ではなく現行結果を確認してください。

情報源からの引用

各フレームワークチームによる公式な説明です。公開前には、引用文を現在の文書と照合してください。

Qwik — 再開可能性

• Qwikは、再開可能性によって “instant-on applications” (翻訳) 「即時起動するアプリケーション」を提供するフレームワークだと説明し、ハイドレーションと対比しています。アプリは “continue execution in the browser from where the server left off,” (翻訳) 「サーバーが停止した位置からブラウザで実行を続ける」ため、対話可能にする目的で “download and execute the application” (翻訳) 「アプリケーションをダウンロードして実行する」必要がないとしています。 Resumable concept
• Qwikは “HTML-first” (翻訳) 「HTML優先」を掲げ、JavaScriptを “only when needed,” (翻訳) 「必要なときだけ」、大きな起動バンドルではなく個別の操作単位で遅延取得すると説明します。 Think Qwik

SolidJS — 細粒度リアクティビティ

• SolidJSは、仮想DOMを使わない細粒度リアクティビティと説明しています。コンポーネントは “run once” (翻訳) 「一度だけ実行」され、シグナルは “only the parts of the DOM that depend on them.” (翻訳) 「依存しているDOM部分だけ」を更新します。 Intro to reactivity
• SolidStartは “renders on the server” (翻訳) 「サーバーでレンダリングする」フレームワークとして紹介され、クライアントでハイドレーションします。文書が利点として示すのはハイドレーションの不在ではなく、その効率です。 SolidStart

次世代フレームワークを選定・監査するチェックリスト

QwikまたはSolidJSをSEO用途で採用・監査する前に確認します。

• メタフレームワークが実際に使うレンダリング方式を確認した（SolidStart：CSR／SSR／SSG、QwikCity：サーバー／静的）。サーバーレンダリングが既定だと決めつけていない。
• ページのソースを表示またはURLを直接取得し、実際のコンテンツと <a href> リンクが生HTMLにあり、空の <div id="app"> だけではない。
• Search ConsoleのURL検査で描画後HTMLにもコンテンツがあり、JS挿入の noindex がない。
• titleとmetaタグをQwikの useDocumentHead／DocumentHead、またはSolidStartへ明示追加したルーター／メタデータライブラリで設定し、クライアント側だけに置いていない。
• Core Web VitalsをラボだけでなくCrUX／Search Consoleのフィールドデータで測った。仕組みが数値を保証すると考えていない。
• ルーティングが実際のナビゲーションまたはHistory APIを使い、各ルートにクロール可能なURLと固有のサーバーHTMLがある。
• SolidJSを「再開可能」と説明・設定していない。SolidJSはハイドレーションし、再開するのはQwikだけ。
• Qwikを「JavaScriptゼロ」と説明していない。Qwikloaderは読み込み時に動くため、実行内容と useVisibleTask$ 呼び出しを確認した。
• Qwikの $ 境界で捕捉する値の直列化をテストし、noSerialize() 値には明示的なクライアント再初期化がある。
• 少量でもGoogleが取得できるよう、JavaScriptとCSSを robots.txt で遮断していない。
• React／Vue／Angularよりコミュニティと既製統合が小さく、両方の文書が現在ベータ表記であるというエコシステム上のトレードオフを理解した。

次世代JavaScriptを評価するための枠組み

クロール可能性と実行時コストを分ける

実装を独立した2軸で評価します。

1. 文書の完全性： 各公開ルートがコンテンツ、リンク、メタデータをHTMLで返すか。QwikCityまたはSolidStartのSSR／SSGなら実現できますが、CSRではできません。
2. 起動コスト： 操作可能になるまでにJavaScriptをどれだけ実行するか。Qwikは直列化状態から再開しますがQwikloaderは動きます。Solidは細粒度リアクティビティでハイドレーションします。

高速なクライアントランタイムでも空の文書は直せず、完全なHTMLでも良好な応答性は保証されません。フレームワークの評判ではなく、実際にデプロイしたビルドのルートごとに両方を測定してください。

仕組みを見分けるテスト

アーキテクチャ比較では正確な用語を使います。

• Qwik： 再開可能性。全面ハイドレーションはなく、小さくほぼ一定規模のQwikloaderが読み込み時に動き、アプリコードは操作境界で取得されます。
• SolidJS： シグナル、仮想DOMなし、対象を絞った更新。SolidStartはサーバー出力をハイドレーションします。再開可能性ではなく、CSR／SSR／SSGの選択はリアクティビティと別です。
• 既存メタフレームワーク： 通常はハイドレーションを行いますが、サーバーコンポーネント、ストリーミング、部分起動など同じ方向へ近づく選択肢もあります。

一般的な「JavaScriptゼロ」「クロール保証」というラベルではなく、実際の配信方式、エコシステム、チームの制約で選んでください。

次世代フレームワーク早見表

2つの仕組み（混同しない）

SEO上の各結果を決めるもの（保証ではない）

よくある誤解

• ❌ 「SolidJSは再開可能」→ SolidJSはハイドレーションします。再開するのはQwikだけです。
• ❌ 「QwikはJavaScriptをまったく実行しない」→ Qwikloader が読み込み時に動き、操作時にハンドラーコードを遅延取得します。小さく一定規模ですが、ゼロではありません。
• ❌ 「次世代フレームワークはReactで解決できないクロール問題を直す」→ 適切な方式ならReact＋Next.jsもSSRできます。違いはクロール可能性ではなく起動JavaScriptのコストです。
• ❌ 「QwikCity／SolidStartなら必ず内容豊富なHTMLになる」→ SSR／SSGの場合だけです。純粋なCSRにも対応します。

理解度チェック：次世代JavaScriptフレームワーク

再開可能性、細粒度リアクティビティ、SEOとの関係を確認する5問です。それぞれ回答を選び、解説を確認してください。

参考資料

関連する私の記事

• JavaScript SEO完全ガイド — レンダリング、DOMの同等性、JS生成コンテンツのインデックス登録を扱う基礎ガイド。
• Core Web Vitals完全ガイド — INP、LCP、CLSが測る内容とSEO上の位置付け。次世代フレームワークが改善対象とする指標。
• テクニカルSEO初心者ガイド — フレームワーク選択とレンダリングを全体像の中で理解するための資料。

業界の参考資料

• Qwik — Resumable vs. Hydration — 再開可能性とハイドレーションの違いを説明する一次資料。
• SolidJS — Intro to Reactivity — シグナルと細粒度リアクティビティの公式説明。
• web.dev — Rendering on the Web — SSR、ハイドレーション、そのトレードオフを整理したChromeチームの資料。
• js-framework-benchmark（現行結果） — 更新処理でSolidJSとReactなどを比較できる継続的ベンチマーク。
• The Cost of JavaScript（Addy Osmani） — JavaScriptの配信・実行コストが性能上のボトルネックになる理由。
• r/TechSEO — フレームワークのレンダリングとインデックス問題を議論するコミュニティ。

変更履歴