Stencilによる静的サイトの生成

高速でインタラクティブなWebサイトおよびWebアプリを構築するための最良の方法の1つは、サーバー側レンダリング（SSRと呼ばれる）またはクライアント側レンダリング（シングルページアプリまたはSPAと呼ばれる）の代わりに静的サイト生成を利用することです。

静的サイト生成（SSG）とは、サーバー要求時（SSR）またはクライアント実行時（SPA）ではなく、ビルド時（別名、事前レンダリング）にコンポーネントとルートを構築およびレンダリングすることを意味します。ルートはすでに事前にレンダリングされているため、ルートのすべてのコンテンツを検索エンジンとクライアントが すぐに 利用できるため、SEOとパフォーマンスが最大化されます。

静的サイト生成は、ページが静的である必要がある、および/または 静的である必要がある という意味ではありません。Stencilは、"ハイドレート (hydrate)"を利用して、実行時にクライアント側のコンポーネントを効率的にロードし、両方の長所を活用します。

例えば、このページを右クリックして、[ページソースの表示]オプションをクリックしてください。このページでは、最初のペイントに外部のJavaScriptファイルやCSSファイルは必要ありません。

静的サイト生成はコンポーネントを事前レンダリングするため、いくつかのトレードオフと留意事項がありますが、ほとんどのコンポーネントは、多くの変更を加えることなく簡単に事前レンダリングできます。

StencilはSSGを簡単にするので、アプリに組み込む方法を確認してください。

静的サイト生成の利点

Lighthouseのスコアが素晴らしい！！
Largest Contentful Paint (LCP)までの時間の短縮
より良いSearch Engine Optimization (SEO)
JavaScriptが無効なユーザーでも表示可能

Hydrateアプリのビルド: 事前レンダリングの最初のステップは、コンパイラーが「ハイドレート」アプリを生成することです。これは、Node.jsで使用される単一のディレクトリです。「ハイドレート」アプリは、 --prerender CLIフラグが指定されると自動的に生成され、デフォルトではアプリは「dist/hydrate」に保存されます。事前レンダリングでは内部でハイドレートアプリを使用しますが、下位レベルで直接使用することもできます。ハイドレートアプリについて学ぶ。

使用可能なCPUへのフォーク事前レンダリングタスク: Stencilは、Node.jsの子プロセスAPIを使用して、現在のマシンの各CPUへの事前レンダリングを効率的に分割できます。。コンパイラーは、マシン上の各CPUにタスクを実行することにより、事前レンダリング時間を大幅に短縮できます。

プリレンダーインデックス: コンパイラがビルドを完了し、使用可能な各CPUで子プロセスを作成した後、単一のベースURLまたは構成されたエントリURLから開始して、プリレンダーを開始します。ページの事前レンダリングが完了すると、構成済みの wwwディレクトリにindex.htmlファイルとして書き込まれます。

クロールアプリ: 各ページの事前レンダリング中に、Stencilはページ内で使用されるアンカー要素とURLも収集します。この情報を使用して、次にどのページを事前レンダリングする必要があるかをメインスレッドに通知できます。メインスレッドはすべてのURLの調整を担当し、すべてのページがクロールされて事前レンダリングされると、ジョブは終了します。

*静的ファイルを本番環境にデプロイ: すべてのページが事前にレンダリングされ、静的HTMLファイルとして書き込まれたため、 wwwディレクトリをサーバーにデプロイできるようになりました。事前レンダリングやサーバーサイドレンダリング（SSR）との大きな違いは、HTTPサーバーがサーバー上でHTMLを動的に生成するのではなく、静的なHTMLファイルを提供するだけであるということです。

静的HTML応答: 静的HTMLファイルがサーバーにデプロイされると、事前にレンダリングされた各ページの訪問者は、最初にインラインスタイルのHTMLを受け取り、JSやCSSをブロックしません。さらに、コンパイラは、訪問者がこのページに必要とする正確なモジュールをすでに認識しており、link modulepreloadを使用してモジュールを非同期的にプリロードします。。

クライアント側のハイドレーション: HTMLとインラインスタイルが最初のペイントをレンダリングした後、次のステップは、DOM内の同じノードがクライアント側のJavaScriptによってハイドレーションされることです。ページ内の各コンポーネントは、DOM構造で見つかった最初の順序を使用して非同期的にハイドレイトします。次に、各コンポーネントがゆっくりと水和すると、DOMにある既存のノードを再利用できます。

ツール

明示しておくと、Stencilは事前レンダリングに Puppeteerまたはjsdomを使用しません。 Puppeteerはエンドツーエンドに最適ですテストしますが、パフォーマンス上の理由から、数百または数千ページの大規模なWebサイトをすばやく生成することは理想的ではありません。さらに、 jsdomは単体テストによく使用されますが、私たちの経験では、非同期コンポーネントとそのグローバル環境の性質で使用することは困難です。

その代わりに、Stencilはウェブ標準に厳密に従った独自の内部DOM APIを使用していますが、プリレンダリング、静的サイト生成、サーバーサイドレンダリングのために最適化されています。このようにすることで、開発者は今まで慣れ親しんできた同じAPIを使用することができますが、それらはNodeJS環境でもシームレスに動作します。つまり、開発者はコンポーネントの構築方法を変える必要はなく、1つのタイプのコンポーネントを書くことだけに集中し、すでに知っている標準を使ってコーディングすることができるのです。繰り返しになりますが、開発者はプリレンダリングのための新しいAPIを学ぶ必要はありません。コンポーネントがすでに使用しているWeb APIと同じものです。

コンポーネント、マシン、環境ごとにパフォーマンスが異なるため、一貫したベンチマークを提供することは困難です。ただし、Ionicのドキュメントサイトには数百のページがあり、Stencilはサイト全体を数秒で事前レンダリングできることがわかっています。

Back