---

目次

1. 序文
2. はじめに
3. 使用例
4. メリットとデメリット
5. レンダリング戦略
6. プロジェクトのセットアップ
7. プロジェクトの構(gòu)造

---

序文

[トップに戻る↑]

このチュートリアルでは、SvelteKit 2 を徹底的に調(diào)査し、そのすべての側(cè)面を詳しく説明します。このチュートリアルを効果的に進(jìn)めるには、Svelte フレームワークに精通している必要があります。さらに、フロントエンド フレームワークとメタ フレームワークの経験があると、提示された概念をより深く理解するのに役立ちます。

---

導(dǎo)入

[トップに戻る↑]

SvelteKit は、開発者のエクスペリエンスを向上させ、Web アプリケーションの構(gòu)築プロセスを簡素化することに重點を置いた軽量フレームワークです。サーバーサイド レンダリング (SSR)、靜的サイト、シングル ページ アプリケーション (SPA)、ファイルベースのルーティング、効率的なコード分割などの機(jī)能が提供され、すべてパフォーマンスを向上させるように設(shè)計されています。 Svelte フレームワークの機(jī)能を拡張することにより、SvelteKit は Web 開発用の追加ツールと機(jī)能を?qū)毪筏蓼埂?Svelte の公式拡張機(jī)能として、実稼働対応のアプリケーションを作成するための完全なソリューションを提供します。さらに、SvelteKit は、高速開発サーバーおよびビルド ツールである Vite を活用し、ホット モジュール交換用の Svelte プラグインを統(tǒng)合します。これにより、コードが変更されるたびにブラウザでリアルタイムの更新が可能になり、開発速度が向上し、よりスムーズなコーディング エクスペリエンスが実現(xiàn)します。

---

使用例

[トップに戻る↑]

SvelteKit は、さまざまな種類のアプリケーションに柔軟性を提供します。サーバーサイド レンダリング (SSR)、ファイルベースのルーティング、靜的サイト生成 (SSG) のサポートなどの機(jī)能により、動的な単一ページ アプリケーション、コンテンツ豊富な Web サイト、電子商取引プラットフォーム、共同アプリケーション。サーバーとクライアントのコンポーネントを統(tǒng)合するフルスタック アプリケーションの開発、SEO に配慮した迅速なコンテンツ配信を備えたブログの作成、ユーザー エクスペリエンス向上のための電子商取引プラットフォームの最適化、またはリアルタイムのデータ更新を備えた共同アプリケーションの構(gòu)築など。 , SvelteKit は、プロジェクトの要件を満たすために不可欠な機(jī)能を提供します。

---

メリットとデメリット

[トップに戻る↑]

SvelteKit を使用する主な利點は次のとおりです。

パフォーマンス: SvelteKit は、迅速な初期コンテンツ読み込みのために SSR を?qū)g裝することにより、Svelte のパフォーマンス上の利點を活用します。初期ロード後はクライアント側(cè)の操作にスムーズに移行し、アプリケーションがインタラクティブで応答性の高いものになります。 SSR とクライアント側(cè)のハイドレーションのこの組み合わせにより、優(yōu)れたユーザー エクスペリエンスが保証されます。さらに、SvelteKit は遅延読み込みを通じてバンドル サイズを最適化することでパフォーマンスを向上させ、全體的な効率に貢獻(xiàn)します。
サーバー側(cè)レンダリング: SvelteKit の組み込み SSR 機(jī)能は、ユーザー エクスペリエンスを向上させる上で重要な役割を果たします。 SvelteKit はサーバー側(cè)でページをレンダリングすることで、初期コンテンツの読み込みを高速化します。これは待ち?xí)r間を短縮し、ユーザーに情報への即時アクセスを提供するために不可欠です。さらに、SSR はコンテンツを検索エンジンで見つけやすくすることで SEO の向上に貢獻(xiàn)し、最終的に可視性とオーガニック トラフィックを向上させます。
クライアント側(cè)ハイドレーション: SvelteKit の重要な機(jī)能の 1 つは、SSR からクライアント側(cè)のインタラクティブ性へのスムーズな移行 (クライアント側(cè)ハイドレーションと呼ばれます) です。この移行は、応答性の高いユーザー エクスペリエンスを維持するために不可欠です。 SvelteKit は、クライアント側(cè)でアプリケーションをリハイドレートすることにより、ユーザーがコンテンツを動的に操作できるようにし、より魅力的でインタラクティブなエクスペリエンスを作成します。 SSR からクライアント側(cè)の対話性へのこのスムーズな移行は、最適で応答性の高いアプリケーションをユーザーに提供するための基礎(chǔ)となります。
サーバー側(cè)のプリレンダリング: プリレンダリングは、頻繁に変更されないコンテンツの靜的 HTML ページを作成することでパフォーマンスを向上させます。これにより、初期コンテンツの読み込みが速くなります。 SvelteKit はプリレンダリングを使用して、ユーザーが動的レンダリングを待たずに意味のあるコンテンツに迅速にアクセスできるようにします。これにより、よりスムーズで応答性の高いユーザー エクスペリエンスが実現(xiàn)します。また、事前レンダリングされたページは、検索エンジンに簡単にクロール可能でインデックス可能な靜的 HTML コンテンツを提供することで SEO を向上させ、可視性と検索エンジンのランキングを向上させることができます。さらに、プリレンダリングは靜的ページを提供することでコンテンツ配信を最適化し、サーバー側(cè)の処理を削減し、アプリケーションの全體的な効率を向上させます。
ルーティングとレイアウト: SvelteKit は、ページ全體でのルートと共有構(gòu)造の管理を簡素化する統(tǒng)合ルーティング システムとレイアウトを提供します。ルーティング システムを使用すると、開発者はアプリケーションの URL がアプリケーションのさまざまなビューやコンポーネントにどのように対応するかを定義できます。これにより、ページ間を移動するプロセスが簡素化され、アプリケーションに一貫した構(gòu)造が提供されます。さらに、SvelteKit のレイアウトを使用すると、開発者はアプリケーションのさまざまなセクション用のテンプレートを作成し、さまざまなページにわたって統(tǒng)一されたデザインとユーザー エクスペリエンスを促進(jìn)できます。
エコシステムの互換性:SvelteKit は、確立された Svelte エコシステムを利用すると同時に、Web アプリケーション開発用に設(shè)計された特殊な機(jī)能も導(dǎo)入します。このエコシステム內(nèi)では、簡単にアクセスできる UI コンポーネント用の Flowbite や効率的なコンポーネント テスト用の Svelte Testing Library などのライブラリを使用できます。

留意すべき考慮事項は次のとおりです:

成熟度の制限: 比較的新しいフレームワークである SvelteKit は、より確立されたフレームワークと比較してコミュニティが小さく、利用できるリソースが少なくなります。これにより、広範(fàn)なドキュメントやコミュニティ サポートを見つける際に困難が生じる可能性があります。
學(xué)習(xí)曲線: SvelteKit は Web アプリケーション開発用に設(shè)計された追加機(jī)能を?qū)毪工毪长趣?Svelte の概念を拡張しますが、開発者、特に Svelte エコシステムを初めて使用する開発者にとっては、より困難な學(xué)習(xí)曲線につながる可能性があります。 Svelte の詳細(xì)を理解し、SvelteKit の獨(dú)自のワークフローに適応するには、フレームワークを完全に理解するために追加の時間と労力が必要になる場合があります。

---

レンダリング戦略

[トップに戻る↑]

Web アプリケーションのレンダリングには、サーバー側(cè)レンダリング (SSR) と クライアント側(cè)レンダリング (CSR) という 2 つの主なアプローチがあります。 SSR では、サーバー上でアプリケーションをレンダリングし、事前にレンダリングされた HTML をクライアントに送信します。これにより、初期読み込み時間と検索エンジン最適化 (SEO) が向上します。 SSR では、サーバーはレンダリングと初期狀態(tài)管理の両方を処理します。一方、CSR には、JavaScript を使用してクライアント側(cè)でアプリケーションをレンダリングすることが含まれます。これにより、アプリケーションはサーバーに追加のリクエストを行わずにユーザーの対話に応答できるため、より動的でインタラクティブなエクスペリエンスが可能になります。ただし、CSR は適切に実裝されていない場合、初期読み込み時間が遅くなり、SEO の問題が発生する可能性があります。一部のコンポーネントがブラウザ固有の機(jī)能に依存している場合、SSR に適していない可能性があることに注意してください。このような場合、CSR が優(yōu)先される選択肢となる可能性があります。

SSR と CSR の間のギャップを埋めるために、水分補(bǔ)給と呼ばれる概念が使用されます。ハイドレーションは、サーバーから送信された事前レンダリングされた HTML を取得し、クライアント側(cè)でイベント リスナーと対話機(jī)能をそれにアタッチするプロセスです。これにより、アプリケーションはサーバーに追加のリクエストを行うことなく、完全に対話型になることができます。ハイドレーションは、初期の靜的な HTML から動的なクライアント側(cè)アプリケーションに移行するための重要なステップです。

プリレンダリングは、CSR と SSR の側(cè)面を組み合わせた別の手法です。ビルド プロセス中に、SSR などの靜的 HTML ページが生成されます。ただし、サーバーが後続のインタラクティブ性を処理する SSR とは異なり、プリレンダリングでは、すでにインタラクティブな HTML が生成されます。これは、生成された HTML には、サーバーへの追加のリクエストに依存せずにユーザー操作を処理するために必要な JavaScript コードが含まれていることを意味します。プリレンダリングは、インタラクティブ性を維持しながら、プリレンダリングされた HTML の利點を提供します。 靜的サイト生成 (SSG) に適用して、すべてのページが事前にレンダリングされる Web サイトを構(gòu)築できます。

要約すると、CSR ではブラウザが JavaScript を使用して HTML コンテンツを生成し、その結(jié)果、ブラウザがページを動的に構(gòu)築している間にサーバーは最小限の HTML ファイルを送信します。一方、SSR とプリレンダリングでは、サーバー上で HTML が作成され、完全にレンダリングされたページがクライアントに配信されます。 SSR とプリレンダリングは両方とも、クライアントに到達(dá)する前に HTML を生成しますが、実行方法が異なります。プリレンダリングはビルド時に行われ、ルートごとに靜的 HTML ページが生成されます。つまり、リクエストごとにサーバーでレンダリングすることなく、コンテンツを靜的ファイルとして提供できるようになります。ただし、SSR は実行時に行われ、サーバーが各リクエストに応じて HTML を生成するため、動的なコンテンツが可能になります。プリレンダリングは靜的コンテンツの作成に焦點を當(dāng)てますが、ハイドレーションは主に SSR に適用され、そのコンテンツにインタラクティブ性を追加する技術(shù)です。

Svelte は、コンポーネントが開発中にコンパイルされるため、通常は CSR フレームワークとして分類されます。このコンパイルされたコードは、アプリケーションの実行時にブラウザーでコンポーネントを直接レンダリングします。一方、SvelteKit は SSR と CSR の両方をサポートします。これにより、プロジェクトの要件に最適なレンダリング戦略を選択できます。さらに、SvelteKit はプリレンダリングをサポートしています。ビルド プロセス中に、SSR と同様に靜的な HTML ページが生成されます。ただし、サーバーが後続のインタラクティブ性を処理する SSR とは異なり、プリレンダリングでは、すでにインタラクティブな HTML が生成されます。これは、生成された HTML には、サーバーへの追加のリクエストに依存せずにユーザー操作を処理するために必要な JavaScript コードが含まれていることを意味します。プリレンダリングは、インタラクティブ性を維持しながら、プリレンダリングされた HTML の利點を提供します。 靜的サイト生成 (SSG) に適用して、すべてのページが事前にレンダリングされる Web サイトを構(gòu)築できます。

---

プロジェクトのセットアップ

[トップに戻る↑]

---

プロジェクトの構(gòu)造

[トップに戻る↑]

---

以上がSvelteKit ゼロからマスタリーまでの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。