💨 📨 🤡 静的サイトジェネレータの速度比較 👩🏼‍🚀 👍🏾 👩🏽‍✈️

静的Webサイトのジェネレーターは多数あります（Static Site Generator、SSG）。どちらを選ぶか決めるのはとても難しいです。（人気のある）SSGをナビゲートするのに役立つ多くの役立つ記事があります。確かに、そのような資料を読んでも、魔法のように、上記の決定を簡単に行うことはできません。

私はSSGを選ぶのに忙しい人たちを助けることに決めました。私の同僚は、静的サイトジェネレータを見つけるのに役立つ質問のリストをまとめました。このリストに添付されているのは、人気のあるSSGの要約です。さまざまなSSGが実際にどのように機能するかについての評価が欠けているだけです。

すべてのSSGは、その動作方法によって統合されています。つまり、一部のデータを入力として受け入れ、このデータをテンプレートエンジンに渡します。出力はHTMLファイルです。このプロセスは、一般にプロジェクトの構築と呼ばれます。

さまざまなSSGの比較可能なパフォーマンスデータを取得するには、考慮すべき多くのニュアンスがあります。プロジェクトの特徴、組み立てを遅くしたり速くしたりする要因に注意を払う必要があります。ここから、人気のあるSSGのパフォーマンスの調査が始まります。

そうは言っても、私たちの目標は最速のSSGを見つけることだけではありません。「最速」であるという評判は、Hugoですでに定着しています。つまり、プロジェクトのWebサイトには、Hugoが世界最速のWebサイト構築フレームワークであると書かれています。そしてそれは意味します-それがそうであるように。

この記事では、人気のあるSSGのパフォーマンスを比較します。つまり、プロジェクトのビルド時間について話しているのです。しかし、ここで最も重要なことは、特定の機器が特定の結果を示す理由の詳細な分析です。プロジェクトのビルド時間以外に関係なく、「最も速いSSG」を選択するか、すぐに「最も遅い」SSGを放棄するのは間違いです。これがなぜそうなのかについて話しましょう。

テスト

SSGテストプロセスは、いくつかの人気のあるプロジェクトを調査し、単純なデータ形式の処理を調査することから始めるように設計されています。これは、より静的なサイトジェネレータの調査を構築し、この調査をより複雑なデータ形式で拡張するための基礎です。この調査には現在、6つの人気のあるSSGが含まれています。

それらのそれぞれを研究するとき、以下のアプローチと以下の条件が適用されます：

各テスト（プロジェクトビルドプロセス）のデータソースは、ランダムに生成されたヘッダー（「フロントマター」と呼ばれる）とドキュメント本文（3段落のテキスト）を含むマークダウンファイルです。
ドキュメントに画像はありません。
テストは同じコンピューターで複数回実行されます。これにより、テストから得られた特定の値は、相対的な結果の比較よりも重要性が低くなります。
出力は、HTMLページのプレーンテキストです。データ処理は、調査対象の各SSGのスタートガイドに記載されている標準設定を使用して実行されます。
« ». Markdown-.

これらのテストは、パフォーマンステスト（ベンチマーク）と見なされます。単純なマークダウンファイルを使用するため、スタイルが設定されていないHTMLコードになります。

言い換えれば、出力は、技術的な観点から、本番環境に展開できるWebサイトです。ただし、これは実際のSSGシナリオの実装ではありません。実際の状況を再現しようとするのではなく、調査中のフレームワークを比較するための基盤を取得したいと考えています。上記のツールを使用して実際のサイトを作成する場合、SSGはより複雑なデータとさまざまな設定で動作し、プロジェクトのビルド時間に影響します（これにより通常ビルドが遅くなります）。

たとえば、テストと実際のSSGのユースケースの違いの1つは、コールドビルドプロセスを調べているという事実です。実際には、物事は少し異なります。たとえば、プロジェクトにSSGのデータソースである10,000個のマークダウンファイルが含まれていて、Gatsbyを使用してプロジェクトをビルドする場合、Gatsbyキャッシュが使用されます。そして、これにより、組み立て時間が大幅に（ほぼ半分に）短縮されます。

インクリメンタルビルドについても同じことが言えます。これは、インクリメンタルビルドを実行するときに変更されたファイルのみが処理されるという意味で、ホットビルドとコールドビルドを比較することと関係があります。これらのテストでは、増分ビルドについては検討していません。将来的には、この研究がこの方向に拡大される可能性は十分にあります。

さまざまなレベルのSSG

調査を開始する前に、実際には2つのフレーバーのSSG、2つのレベルの静的サイトジェネレーターがあるという事実を見てみましょう。それらを「基本」と「高度」と呼びましょう。

基本的なジェネレーター（それほど単純ではありませんが）は、実際には、データを受け入れてHTMLを出力するコマンドラインツール（コマンドラインインターフェイス、CLI）です。多くの場合、それらの機能は、追加のリソースを処理する方向に拡張するのに役立ちます（ここではこれを行いません）。
高度なジェネレーターは、静的サイトの作成に加えて、いくつかの追加機能を提供します。これらは、たとえば、ページのサーバー側レンダリング、サーバーレス機能、さまざまなWebフレームワークとの統合です。これらは通常、インストール直後に、基本ジェネレーターよりも動的な機能をユーザーに提供するように構成されます。

このテストでは、各レベルの3つのジェネレーターを特別に選択しました。基本的なものには、Eleventy、Hugo、Jekyllが含まれます。他の3つのジェネレーターは、フロントエンドフレームワークに基づいています。これらのSSGには、さまざまな追加ツールが含まれています。GatsbyとNextはReactに基づいていますが、NuxtはVueに基づいています。

基本的なジェネレータ	高度なジェネレータ
11	ギャツビー
ヒューゴ	次
ジキル	Nuxt

仮説と仮定

私たちの研究に科学的手法を適用することを提案します。科学は非常にエキサイティングです（そして大きな利益になる可能性があります）。

私の仮説は、SSGが高度な場合、基本的なジェネレーターよりも実行速度が遅くなることを意味します。高度なSSGの作業には、基本的なSSGの作業よりも多くのメカニズムが関与しているため、これは調査結果に反映されると確信しています。その結果、調査に基づいて、基本的なジェネレーターと高度なジェネレーターを明確に2つのグループに分類できる可能性が非常に高くなります。同時に、基本的なジェネレーターは高度なジェネレーターよりも高速に動作します。

▍基本的なSSG：ビルド速度のファイル数への高速かつ線形依存性

HugoとEleventyは、小さなデータセットを非常に迅速に処理します。これらは（比較的）GoとNode.jsによってそれぞれ作成された単純なプロセスです。彼らのテスト結果はこれを反映しているはずです。これらのSSGは両方とも、ファイルの数が増えるにつれて遅くなりますが、リーダーであり続けることを期待しています。同時に、負荷が増加する11は、組み立て時間の変化のダイナミクスを示す可能性があります。これは、Hugoよりも線形から大きく外れています。これは、Goのパフォーマンスが一般的にNode.jsのパフォーマンスよりも優れているという事実の単純な結果である可能性があります。

▍高度なSSG：ビルドの開始が遅く、その後の速度が上がりますが、それほど深刻ではありません

高度なSSG、またはある種のWebフレームワークに関連付けられているものは、開始が遅く、目立ちます。単一ファイルのテストでは、基本的なフレームワークと高度なフレームワークの違いが非常に重要になると思います。基本的なものの場合は数ミリ秒、高度なものの場合はGatsby、Next、Nuxtの場合は数秒になります。

Webフレームワークに基づくSSGは、Webpackを使用します。これにより、実行時にシステムに追加の負荷がかかります。同時に、この追加の負荷は、処理されるデータの量に依存しません。しかし、私たち自身も、より高度なツールを使用してこれに同意しています（これについては以下で詳しく説明します）。

そして、何千ものファイルを処理することになると、基本的なジェネレーターグループと高度なジェネレーターグループの間のギャップが狭くなると思います。ただし、同時に、高度なSSGは依然として基本的なSSGよりも大幅に遅れています。

高度なジェネレーターのグループについて話す場合、それらの中で最も速いのはギャツビーだと思います。速度を落とす可能性のあるサーバー側のレンダリングコンポーネントがないため、そう思います。しかし、これは私の内面の感情を反映したものにすぎません。おそらく、NextおよびNuxtサーバーのレンダリングは、使用されない場合でもプロジェクトのビルド時間にまったく影響を与えないレベルに最適化されています。NuxtはNextよりも速いと思います。私は、VueがReactよりも「軽い」という事実に基づいてこの仮定をします。

▍ジキルは基本的なSSGの珍しい代表です

Rubyプラットフォームは、パフォーマンスが低いことで有名です。時間の経過とともに最適化され、高速になりますが、Goは言うまでもなく、Node.jsほど高速になるとは思いません。しかし同時に、JekyllはWebフレームワークに関連する追加の負担を負いません。

テストの開始時に、少数のファイルを処理するとき、Jekyllは高速を示すと思います。おそらく11と同じくらい背が高い。しかし、何千ものファイルの処理を調べると、パフォーマンスが低下します。 Jekyllが調査した6つのSSGの中で最も遅い理由は他にもあるように思われます。これをテストするために、さまざまなサイズ（最大100,000）のファイルのセットに対するジェネレーターのパフォーマンスを調べます。

以下は私の仮定を示すグラフです。

さまざまなSSG

の作業速度の依存性に関する仮定Y軸はプロジェクトのビルド時間を表し、X軸はファイルの数を表します。次は緑、Nuxtは黄色、Gatsbyはピンク、Jekyllは青、11はターコイズ、Hugoはオレンジで示されています。すべての行は、ファイル数の増加に伴うプロジェクトビルド時間の増加を反映しています。同時に、ジキルに対応する線が最大の傾斜角を持っています。

結果

これが、これから説明する結果を生成するコードです。また、相対的なテスト結果をまとめたページも作成しました。

テストを実行するための条件を見つけるために何度も試みた後、3つの異なるデータセットを使用して各テストを10回実行することにしました。

ベースデータセット（ベース）。これは1つのファイルです。その処理により、SSGが作業の準備をするために必要な時間を見積もることができます。これは、SSGの起動にかかる時間です。処理されるファイルの数に関係なく、基本と呼ぶことができます。
「スモールサイト」（スモールサイト）のセット。1から1024までのファイルセットのアセンブリを調べます。新しいテストパスはそれぞれ、2倍の数のファイルを使用して実行されます（ファイルの処理時間がファイル数の増加に比例して増加するかどうかを簡単に確認できるようにするため）。
「大規模サイト」（大規模サイト）のセット。ここでは、ファイルの数が1000から64000に変更され、新しいテストを実行するたびに2倍になります。最初は128000ファイルにしたかったのですが、いくつかのフレームワークでボトルネックに遭遇しました。その結果、大規模なサイトを処理する際に調査対象のSSGがどのように動作するかを調べるには、64,000ファイルで十分であることが判明しました。

これが私が得た結果です。

基本データセット

小規模サイトのデータセット

大規模サイトのデータセット

結果の要約

結果のいくつかは私を驚かせました、しかしいくつかは私が期待した通りであることがわかりました。一般的な調査結果は次のとおりです。

予想通り、最速のSSGはHugoでした。これは、すべてのサイズのファイルのセットでうまく機能します。しかし、Baseデータセットであっても、他のジェネレーターが少なくともそれに近づくとは思っていませんでした（線形の動作を示すとは思っていませんでしたが、以下で詳しく説明します）。
スモールサイトセットからのファイルの処理を示すグラフでは、基本と高度の両方のSSGがまったく異なります。これは予想されていた。ただし、Nextが32000ファイルのセットでJekyllよりも高速であり、64000ファイルでJekyllとEleventyの両方をバイパスすることは予想外でした。また、驚くべきことに、JekyllはEleventyより64,000ファイル高速です。
SSG . Next, , , . Hugo , — - .
, Gatsby , , . , .
, , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .

これはどういう意味ですか？

これらのSSGの作成者、およびそれらをサポートする人々と調査結果を共有したとき、詳細には触れないにしても、同じメッセージを彼らから受け取りました。これらのメッセージが一種の「平均的な」メッセージに縮小されると、次のようになります。

プロジェクトの構築により多くの時間を費やすジェネレーターは、より多くの問題を解決する必要があるため、このように機能します。これらは開発者により多くのオプションを提供しますが、より高速なツール（つまり、「基本」）は主にテンプレートをHTMLファイルに変換することに関係しています。

私はそれに同意します。

一言で言えば、Jamstackサイトのスケーリングは非常に難しいことがわかりました。

プロジェクトが成長し発展している開発者が直面する困難は、それぞれの特定のプロジェクトの特性によって異なります。これをサポートするデータはありません。はい、各プロジェクトは何らかの形でユニークであるため、ここにいることはできません。

しかし、それはすべて、開発者の個人的な好み、サイトを構築する時間と、彼が作成する準備ができているSSGでの作業の利便性との間の妥協点に帰着します。

たとえば、画像でいっぱいの大規模なサイトを作成し、Gatsbyの使用を計画している場合、このサイトの構築には長い時間がかかるという事実に備える必要があります。しかし、その見返りとして、プラグインの巨大なエコシステムと、堅牢でよく整理されたコンポーネントベースのWebサイトを構築するための基盤が得られます。同じプロジェクトでJekyllを使用する場合、プロジェクトでの作業の有効性を確保するために、プロジェクトを適切に整理された状態に保つために、より多くの努力を払う必要があります。そして、サイトの組み立てが速くなります。

職場では、私は通常Gatsbyでサイトを構築します（または、プロジェクトの動的な対話性の必要なレベルに応じて、Nextを使用します）。 Gatsbyと協力して、膨大な数のコンポーネントに基づく多くの画像を含む高度にカスタマイズ可能なWebサイトをすばやく構築するためのフレームワークを作成しました。これらのサイトのサイズが大きくなるにつれて、それらを構築するのにますます時間がかかり、私たちは創造性を発揮し始めました。これは、マイクロフロントエンド、メインビルドシステムの外部での画像処理、コンテンツプレビュー、およびその他の多くの最適化の実装に関するものです。

独自のプロジェクトで私は通常Eleventyを使用します。通常、私だけがそのようなプロジェクトのコードを書きます、私のニーズはかなり控えめです（私は自分自身を自分の良いクライアントとして認識しています）。ビルド結果をより適切に制御できるため、クライアント側の高い生産性を実現できます。そして、これは私にとって重要です。

その結果、SSGの選択は、「速い」と「遅い」の間の選択だけではありません。特定のプロジェクトに最適なツールの選択であり、その結果は、これらの結果を待つために経過する時間を正当化します。

結果

実際、私が言ったことはほんの始まりに過ぎません。私の仕事の目標は、人気のあるSSGによって作成されたプロジェクトの相対的なビルド時間をすべて測定できるベースを作成することです。

静的サイトジェネレーターの提案されたテストプロセスに矛盾を見つけましたか？テスト手順を改善する方法は？裁判を現実に近づける方法は？画像処理を別のコンピューターに転送する必要がありますか？SSGを気にかけているすべての人に参加してもらい、これらの質問や他の多くの質問に対する答えを見つけるのを手伝ってください。

どの静的サイトジェネレータを使用していますか？

静的サイトジェネレータの速度比較

テスト