Svelte入門：SvelteKitでのページオプション -Vol.1-

よっしー

こんにちは。よっしーです(^^)

今日は、SvelteKitでのページオプションについて解説しています。

背景
SvelteKitでのページオプションについて
1. ハイドレーションとは
プリレンダ
おわりに

背景

SvelteKitでのページオプションについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。

SvelteKitでのページオプションについて

SvelteKitは基本的に、コンポーネントをまずサーバー上でレンダリング（またはプリレンダリング）し、HTMLとしてクライアントに送信します。その後、ブラウザ上で再度レンダリングして、「ハイドレーション」と呼ばれるプロセスで対話性を持たせます。そのため、コンポーネントが両方の環境で動作することを確認する必要があります。その後、SvelteKitは後続のナビゲーションを制御する「ルーター」を初期化します。

これらの動作は、+page.jsや+page.server.jsからオプションをエクスポートすることで、ページごとに制御できます。また、共有の+layout.jsや+layout.server.jsを使用して、ページのグループに対して制御することもできます。アプリ全体に対するオプションを定義するには、ルートレイアウトからエクスポートします。

これらのオプションをアプリの異なる領域で組み合わせることができます。例えば、マーケティングページをプリレンダリングして最高速度を実現し、動的ページをサーバーレンダリングしてSEOとアクセシビリティを確保し、管理セクションをクライアントのみでレンダリングしてSPAにすることができます。これにより、SvelteKitは非常に多用途になります。

ハイドレーションとは

ハイドレーション（Hydration）は、Webアプリケーション開発、特にサーバーサイドレンダリング（SSR）を使用するフレームワークにおいて重要な概念です。以下にハイドレーションの概要を説明します：

定義：
ハイドレーションとは、サーバーでレンダリングされたHTMLを、クライアント側（ブラウザ）で完全に機能するインタラクティブなアプリケーションに変換するプロセスです。
プロセス：

まず、サーバーがHTMLを生成し、クライアントに送信します。
クライアントがこのHTMLを受け取り、表示します。
その後、JavaScriptがロードされ、既存のHTML構造に「ハイドレート」（水分を与える）します。
このプロセスで、静的なHTMLが動的で対話可能なアプリケーションになります。

目的：

初期ページロードを高速化します（サーバーレンダリングのおかげで）。
SEOを改善します（検索エンジンが静的HTMLを読み取れるため）。
ユーザーエクスペリエンスを向上させます（ページが素早く表示され、その後インタラクティブになるため）。

メリット：

初期ページロードが速い。
SEOに有利。
プログレッシブエンハンスメントを可能にする。

注意点：

サーバーとクライアントの両方で動作するコードを書く必要がある。
ハイドレーションそのものにも多少の時間がかかる。

ハイドレーションは、モダンなWeb開発、特にSvelteKitのようなフレームワークにおいて、パフォーマンスとユーザーエクスペリエンスを最適化するための重要な技術です。

プリレンダ

おそらく、アプリの少なくとも一部のルートは、ビルド時に生成される単純な HTML ファイルとして表すことができます。これらのルートは事前にレンダリングできます。

// +page.js/+page.server.js/+server.js
export const prerender = true;

あるいは、ルート +layout.js または +layout.server.js で import const prerender = true を設定し、事前レンダリング不可として明示的にマークされているページを除くすべてを事前レンダリングすることもできます。

// +page.js/+page.server.js/+server.js
export const prerender = false;

prerender = true を設定したルートは、動的SSR（サーバーサイドレンダリング）用のマニフェストから除外されます。これにより、サーバー（またはサーバーレス/エッジ関数）のサイズが小さくなります。

しかし、ルートをプリレンダリングしつつ、マニフェストにも含めたい場合があります。例えば：

/blog/[slug] のようなルート
最新または人気のコンテンツはプリレンダリングしたい
ロングテール（あまりアクセスされないコンテンツ）はサーバーレンダリングしたい

このような場合のために、’auto’ という第三のオプションがあります。

このアプローチにより、プリレンダリングとサーバーレンダリングを柔軟に組み合わせることができ、パフォーマンスと動的コンテンツの両立が可能になります。

// +page.js/+page.server.js/+server.js
export const prerender = 'auto';

アプリ全体がプリレンダリングに適している場合は、adapter-static を使用できます。これにより、静的 Web サーバーでの使用に適したファイルが出力されます。

プリレンダラーの動作：
- アプリのルートから開始し、プリレンダリング可能なページや+server.jsルートのファイルを生成します。
- 各ページ内の<a>要素をスキャンし、プリレンダリングの候補となる他のページを見つけます。
プリレンダリング対象の指定：
- 通常、どのページをプリレンダリングするか明示的に指定する必要はありません。
- 必要な場合は、以下の方法で指定できます： a) config.kit.prerender.entriesを使用 b) 動的ルートからentries関数をエクスポート
プリレンダリング中の環境変数：
- $app/environmentからインポートしたbuildingの値がtrueになります。