SvelteKit
Svelteでルーティング・サーバー処理・静的出力までを完結させるフレームワーク
分野「画面・フロントエンド」：利用者が見て、触る画面をつくる。ブラウザの中で動く部分。 分野の役割とつながりは分野の解説へ。
別名：Svelte Kit、kit.svelte.dev
できること
- ブラウザ向けの画面を作る ：操作できる Web 画面を作りたい
- 静的サイトを生成する ：ブログや資料サイトを作りたい
- HTTP API を公開する ：自分のデータや処理を他から呼ばせたい
SvelteKit ができないこと
- アダプタなしでのオンデマンドなサーバー側描画(デプロイ先ごとにadapter-node/adapter-cloudflare等の追加が必須)
- +page.server.js等のサーバー専用ロジックを含むページの完全な静的書き出し(adapter-staticは全ルートの事前レンダリング可能性かSPAフォールバックが前提)
- フォームアクション(actions)を持つページの事前レンダリング(POSTを受けるサーバーが必須なため)
- 事前レンダリング中のurl.searchParams(実行時のクエリパラメータ)へのアクセス
制約
先頭の行が、このツールで最も先に当たる制約。値はすべて出典の一次情報で確認したもの。
| 項目 | 値 | 影響 | 出典 | 検証日 |
|---|---|---|---|---|
| デプロイ先ごとのアダプタ選定 （主要制約） | ビルド出力をデプロイ環境向けに変換する「アダプタ」の指定がsvelte.config.jsで必須。公式にNode・Cloudflare・Netlify・Vercel・静的サイト(adapter-static)向けがある | オンデマンドのサーバー処理(Cookie読み書き、フォーム受信等)を使うページがあると、配置先に対応するアダプタを先に決めないとビルドが機能しない | svelte.dev | |
| 静的出力(adapter-static)の前提条件 | 全ページ・全エンドポイントが事前レンダリング可能であるか、SPAフォールバックを明示設定している必要がある。フォールバックは検索エンジン最適化とパフォーマンスへの悪影響が大きいと明記されている | サーバー専用ロジックを含むルートが1つでもあると、そのままでは静的サイトとして書き出せない。該当ルートを分離するか他のアダプタに切り替える | svelte.dev | |
| Node向けサーバーのリクエストボディ上限 | adapter-nodeのBODY_SIZE_LIMIT既定値は512kb | ファイルアップロードなど大きめのリクエストボディを扱うには環境変数で明示的に引き上げる必要がある | svelte.dev | |
| フォームアクションと事前レンダリングの排他性 | actions(フォーム送信処理)を持つページはprerender対象にできない。POSTリクエストを処理するサーバーが必須なため | 静的サイト中心の構成でフォームを使うと、そのページだけサーバーが必要になり完全な静的配信が崩れる | svelte.dev | |
| 動作に必要なNode.jsバージョン | @sveltejs/kit の engines 指定は node >=18.13 | 古いLTS(18.13未満)やCI環境ではインストール・ビルドが失敗する | github.com |
典型的な落とし穴
- 各ページのprerender/ssr/csr設定を理解せずに使うと、静的化したいページにサーバー依存のコードが混入してビルドが失敗する
- アダプタを決めずに開発を進め、終盤でCookie認証やフォーム処理を足すと、対応アダプタの選定からやり直しになる
- SPAフォールバックを安易に使うと、初期表示の遅さとSEOの悪化が本番で露見する
- load関数とページオプションの継承関係(+layout.jsとの併用)を誤解し、意図しないルートまで事前レンダリング対象/非対象になる
コスト
- 課金モデル
- 無料
- 跳ねる条件
MIT Licenseで無償。費用は配置先のホスティング(Vercel、Cloudflare、Node環境のサーバー等)側で発生する
- 出典
- github.com 検証
代替手段と差分
| 代替 | 何が違うか |
|---|---|
| Next.js | Next.jsは React ベースで Server Actions・ISR 等の機能が厚く、Vercel との統合が深い。SvelteKit は Svelte ベースで出力ランタイムが軽量。React エコシステムに乗るなら Next.js、軽さと書きやすさを優先するなら SvelteKit |
| Astro | Astro は既定で JavaScript を出さない文書中心の静的サイト生成に特化し、複数フレームワークを島として混在できる。SvelteKit は Svelte 単体でログイン後の操作画面のようなアプリ的な用途まで一貫して作る |
| React | React は画面を作るライブラリそのもので、ルーティングやサーバー処理は別途組み合わせが必要。SvelteKit はルーティング・データ取得・サーバー処理・静的出力までを1つのフレームワークとして提供する |
選定判断
ルーティング・データ取得・フォーム処理・静的出力までを1つのフレームワークで完結させたいプロジェクトでは第一候補。React の資産に乗る必要がある場合は Next.js、文書中心で操作の少ないサイトは Astro を検討する
Svelte をコンパイラとして使い、ファイルベースのルーティング、サーバー側のデータ取得(load 関数)、フォーム処理(actions)、静的サイト生成までを1つのフレームワークにまとめたもの。出力する JavaScript が少なく、Svelte 自体の学習コストの低さを引き継いでいる。
利用者が最初に当たる制約はアダプタの選定である。オンデマンドのサーバー処理を使うページが1つでもあると、Node・Cloudflare・Vercel など配置先に対応したアダプタが必要になり、逆に全ページが事前レンダリング可能でなければ完全な静的サイト(adapter-static)としては書き出せない。配置先を後回しにして開発を進めると、この境界で手戻りが起きやすい。