部 III 章 14

Jamstack

公開日：2025/07/04

Web Almanacのキャラクターが、前面にスクリプトの印がついた大きなガスボンベを使ってウェブページを膨らませているヒーローイメージ。

Mike Neumegen によって書かれた。

Thom Krupa によってレビュ。

Estela Franco による分析。

David Large 編集。

Sakae Kotaro によって翻訳された。

導入

Jamstackを覚えていますか？この言葉自体はもはや広く使われなくなりましたが、その中心的な概念は依然として重要です。

Jamstackの核心は、可能な限りページをプリレンダリングすることを推進する配信アーキテクチャです。2024年のWeb Almanac Jamstackの章では、今日一般的に使用されている3つの主要な配信アーキテクチャについて探ります：

プリレンダリング: 事前にページをビルドし、静的ファイルとして提供します。
ハイブリッド: インクリメンタル静的再生成（ISR）やエッジファンクションのような技術を使い、静的なページと動的なページを混在させ、両者の境界を曖昧にします。
動的: リクエストごとにサーバーでページが生成されます。

ウェブサイトが静的であればあるほど、より速く、スケーラブルで、安全で、環境に優しくなる傾向があるため、静的ファーストのアプローチを取ることが一般的になってきました。プリレンダリング、ハイブリッド、そして動的なアプローチは、ウェブ開発者のツールキットにおける貴重なツールであり、それぞれ異なる状況に適しています。これらのカテゴリがどのように進化しているか見ていきましょう。

データセットの定義

では、サイトがどの配信アプローチを取っているかをどう判断するのでしょうか？理想的には、すべてのサイトをきちんと分類できる明確な目印があればよいのですが、残念ながらそのような目印はなく、それがこれらのアーキテクチャについて報告する上でもっとも大きな課題の1つとなっています。

以前のJamstack Web Almanacの章では、2つのアプローチが取られてきました：

検出可能な静的サイトジェネレータを持つウェブサイトに焦点を当てる。これにより、対象のサイトが的を絞った技術を使用していると確信できるため、正確な状況を把握できました。問題は、多くの静的サイトジェネレータがデフォルトでフィンガープリントを残さないため、データセットがNext.jsやNuxtのようなフレームワークに偏ってしまうことです。さらに問題を複雑にしているのは、これらの重いJavaScriptフレームワークはページのプリレンダリングと動的レンダリングの両方が可能であるため、どちらのカテゴリに入れるべきかという点です。
2022年のJamstackの章で開拓された2番目のアプローチでは、Largest Contentful Paint、Cumulative Layout Shift、そしてキャッシングのしきい値を用いてデータセットを構築しました。このアプローチは、明確な静的サイトジェネレータのフィンガープリントを持たないプリレンダリングされたサイトをより多く含めることで、データセットを広げます。欠点は、フロントエンドのパフォーマンスに焦点を当てることで、プリレンダリングの定義が曖昧になることです。プリレンダリングはしばしば配信速度を向上させますが、私たちの見解では、その範囲はそこまでです。LCPの高速化のような配信後の事象は、嬉しい副産物です。

どちらのアプローチにも長所があります。最初のアプローチはプリレンダリングされたサイトを明確に定義するデータを使い、2番目のアプローチは指標に依存します。今年は、両方の長所を活かすために、スコアリングシステムを組み合わせています。このスコアリングシステムは、サイトがプリレンダリングされているかどうかの信頼度を反映するために開発しました。11tyで生成されたり、GitHub Pagesでホストされているような強力な指標は100ポイントを獲得し、Time to First Byte（TTFB）が速いといったよりソフトなシグナルは、この場合は50ポイントといった低いポイントを受け取ります。

次に、ポイントを合計し、以下のいずれかのカテゴリに入れます：

プリレンダリング

サイトが100ポイント以上を獲得した場合、それをプリレンダリングと呼びます。これは、サイトが静的に生成されているか、分離されていることを示す複数の兆候があることを意味します。これは高い基準であり、2024年の全サイトの約0.5%を含みます。

ハイブリッド

サイトが50から99ポイントの間でスコアを獲得した場合、それをハイブリッドカテゴリに入れます。これらは静的かもしれないが、私たちが判断するのに十分なフィンガープリントがないウェブサイト、あるいは純粋に静的ではないが、いくつかのアプローチや哲学を共有しているウェブサイトです。たとえば、NetlifyでホストされているNuxtサイトや、TTFBが速いGatsbyサイトなどです。ハイブリッドはより緩やかなカテゴリですが、それでも2024年のデータセットの約5%を占める高い基準です。

動的

50ポイント未満のスコアのものはすべて動的カテゴリに分類されます。これらのサイトは、サーバーサイドレンダリングに依存しているか、他のカテゴリに入れるのに十分なフィンガープリントがありません。動的はウェブの大部分を占め、データセットの約94.5%を占めます。

スコアリング

スコアリングの仕組みについて詳しく見ていきましょう。

検出可能な静的サイトジェネレータ

これは非常に大きな手がかりです。SSGに基づいて、ウェブサイトがプリレンダリングされている可能性がどれくらいあるかをスコアで示すことができます。これらはおおよその目安なので、Next.jsサイトの30%が純粋に静的であると断言することはできませんが、他のデータポイントと組み合わせることで、確信を持つことができる1つのデータポイントです。

SSG	ポイント
Astro	50
Bridgetown	100
Docusarus	100
Eleventy	100
Gatsby	30
Gridsome	100
Hexo	100
Hugo	100
Jekyll	100
Mintlify	70
Next.js	30
Nextra	70
Nuxt	30
Octopress	100
Pelican	100
Retype	100
Scully	70
VuePress	100

図14.1. SSGポイント分布。

ホスティングプロバイダ

GitHub Pagesは静的コンテンツしか提供できないため、そのプラットフォームでホストされていれば、プリレンダリングされているに違いないとわかります。NetlifyとVercelはどちらも多くの静的ウェブサイトを持っていますが、動的な機能も備えています。スコアリングではこれを考慮に入れようとしました。

ホスティングプロバイダ	ポイント
GitHub Pages	100
Netlify	30
Tiiny Host	100
Vercel	30

図14.2. ホスティングプロバイダのポイント分布。

TTFB

Time to First Byte は、サーバーがブラウザに何かを返すまでにかかった時間です。この指標を使う背後にある考え方は、サーバーが行うべきことが静的ファイルを返すだけならTTFBは非常に速くなるのに対し、サーバーがページを生成するために動的な処理を行う必要がある場合は時間がかかるというものです。もちろん、サーバーがページを生成するのに時間をかけている間に何かを送信すればTTFBはごまかせますが、だからこそ良好なTTFBには100ではなく50のスコアを与えています。

サーバー応答時間	ポイント
800ms以下	50
800msより大きくかつ 1800ms以下	25
1800ms以上	0

図14.3. サーバー応答時間のポイント分布。

キャッシング

キャッシングは、サイトがどれほど静的であるかを把握するのに良い指標となります。サイトが積極的なキャッシングヘッダーを使用している場合、サーバーが最小限の作業しか行っていないことを強く示唆しており、これは非常に静的らしいと感じられます。一方、長くてもそれほど積極的でないヘッダーを持つサイトは、依然として静的なアプローチを示唆していますが、確実性は低くなります。

キャッシュヘッダー	ポイント
`max-age`が2週間以上かつ再検証を必要としない。	100
`max-age`が2週間以上かつ再検証を必要とする。	50

図14.4. キャッシュヘッダーのポイント分布。

ETag

ETagは、ブラウザがリソースが最後に取得されてから変更されたかどうかを確認できるようにすることで、キャッシュの検証を助けます。サーバーが毎回コンテンツを再生成する代わりにキャッシュされたコンテンツに依存していることを示しているため、これは静的なアプローチへの小さな後押しと見ています。

Etag	ポイント
ETagが存在する	10
ETagがない	0

図14.5. Etagポイント分布。

Set-Cookieヘッダーは、動的な振る舞いを示唆します。通常、これはサーバーがセッションなどを処理していることを意味し、コンテンツが純粋に静的ではないことを示唆します。

Set Cookie	ポイント
Set-Cookieが存在する	-10
Set-Cookieがない	0

図14.6. Set Cookieポイント分布。

データセットの制限事項

このセグメンテーションは難しいということを改めて強調しておきます。これらは利用可能なデータに基づく大まかな推定であり、一部の誤分類は避けられません。また、このスコアリング方法を用いたのは今年が初めてであり、今後数年で改良できるものです。

これを最小限に抑えるため、プリレンダリングとハイブリッドに該当するものの基準を高く設定しました。これらのカテゴリは、このレポートで示されているよりも大きい可能性があります。

分析

カテゴリが定義されたので、2024年にそれらがどのようにトレンドになっているか見てみましょう。

静的サイトジェネレータ

SSGはプリレンダリングを実行する技術であり、分析の自然な出発点となります。すべての静的サイトジェネレータがフィンガープリントを残すわけではないことに留意してください。たとえば、11tyのようなツールはデフォルトで何の痕跡も残さないため、このデータセットには反映されていません。

過去3年間、プリレンダリングカテゴリではHugoがかなりの差をつけてリードしているのがわかります。Hugoは高速で柔軟なSSGとして知られており、パフォーマンスを重視するコミュニティがあるため、リストのトップにいるのは驚くことではありません。

Next.jsはウェブ上での優位性を維持し、プリレンダリングカテゴリでHugoとの差を着実に縮めています。注目すべきは、私たちのスコアリングでは、既知のHugoサイトのほぼすべてをプリレンダリングと見なしているのに対し、Next.jsがプリレンダリングと見なされるには複数の指標が必要であるという点です。

一方、Jekyll、Gatsby、Hexoはプリレンダリングカテゴリでの使用率が安定または減少しており、これはこれらのフレームワークへの開発が減少していることを反映しています。

Docusaurusは着実に上昇しており、ドキュメンテーション専用であることを考えると印象的です。

ここで本当に際立っているのはAstroで、2024年には3倍に成長しました！今やプリレンダリングカテゴリの主要プレイヤーであり、この傾向が続けば主要なフレームワークになる可能性があります。

ハイブリッドカテゴリを見てみましょう：

ハイブリッドカテゴリでは、Next.jsが過去1年で39%増加し、そのリードを広げていることがわかります。Next.jsは、プリレンダリング、動的レンダリング、インクリメンタル静的再生成（サイト全体のリビルドを必要とせずに特定の静的ページをオンデマンドで更新）が可能な非常に柔軟なフレームワークです。情報サイトから本格的なウェブアプリケーションまで、あらゆるものに対応できるその多様性が、使用率の増加の大きな理由の1つです。

Nuxtはハイブリッドカテゴリ内で着実に成長を続け、Astroは2024年に急速な成長を遂げました。

パフォーマンス

プリレンダリングされたサイトは、サーバーがリクエストごとに動的にレスポンスをレンダリングするのではなく、即座に応答できるため、そのパフォーマンスで知られています。これにより、読み込み時間が短縮され、サーバーへの負荷が軽減されます。分析でそれがどのように現れるか見てみましょう。

サイトのページ転送サイズの中央値は、サイト全体のパフォーマンスに重要な要素であると予想されるため、興味深い出発点です。

平均して、プリレンダリングされたサイトは転送サイズがはるかに小さく、動的サイトの43%に相当します。

プリレンダリングサイトとハイブリッドサイトの間のジャンプは、プリレンダリングサイトが静的な情報サイトである可能性が高いのに対し、ハイブリッドサイトはeコマースやウェブアプリケーションに傾倒する可能性があり、それがより大きな転送サイズにつながる可能性があるという、それぞれの異なるユースケースを反映している可能性があります。

この余分な重みがどこから来ているのかを分解してみましょう。

総リクエスト数を見ると、カテゴリ間の総ページ重量の違いの一部を説明できるかもしれません。2022年から2024年にかけて、プリレンダリングされたサイトでは総リクエスト数はほぼ同じままで、動的ではわずかに増加し、ハイブリッドカテゴリではもっとも大きな増加（2024年に16%）が見られます。

CSSの総転送量は別の視点を提供し、すべてのカテゴリでわずかな上昇傾向を示しています。ハイブリッドサイトと動的サイトの間の顕著なジャンプが目立ちます。正確な原因を特定するにはさらなる分析が必要ですが、考えられる説明としては、プリレンダリングサイトとハイブリッドサイトはウェブ開発者によって手作りされる傾向があるのに対し、動的サイトはしばしばテーマ、ウェブサイトビルダー、プラグインに依存しており、これらは肥大化したウェブアセットで悪名高いということです。

JavaScriptの総転送量は、もっとも興味深い洞察の1つを提供しており、ハイブリッドサイトのJavaScriptサイズが急激に増加し、2024年には動的カテゴリのそれを上回っています。

図14.13. プリレンダリングサイトとハイブリッドサイトで使用されるJavaScriptフレームワーク。

プリレンダリングされたウェブサイトとハイブリッドウェブサイトで使われるJavaScriptフレームワークを分解すると、Reactのような重いフレームワークがハイブリッドカテゴリでより一般的に使われていることがわかります。

総転送サイズからCSSとJavaScriptを除くと、HTML、画像、フォント、その他のメディアが残ります。このフィルタリングされた総中央転送サイズを比較すると、各カテゴリ間にまだ顕著な差があります。これは各カテゴリで行われる総リクエスト数に対応しており、これらのカテゴリで画像やフォントがより多く使用されていることを反映している可能性があります。

図14.15. Astro vs Hugo vs Next.js：年ごとの転送サイズ。

プリレンダリングカテゴリで際立っている3つの静的サイトジェネレータ、Astro、Hugo、Next.jsに焦点を当てることで、ページ重量を分析するための別の視点が得られます。注：この分析には、比較を公平に保つため、プリレンダリングカテゴリのサイトのみが含まれます。

Astroは、AstroアイランドやデフォルトでのゼロJavaScriptからアセット最適化パイプラインまで、必要な最小限のデータのみを送信するために数多くのステップを踏んでいます。そのパフォーマンスへの献身がデータに反映されているのを見るのは素晴らしいことです。

HugoはAstroからページ重量が一段階上がっているのが見られます。HugoにはAstroと同じタイプの資産最適化パイプラインが多くありますが、Astroのパイプラインはフレームワークに深く統合されており、それが違いを説明している可能性があります。

Next.jsはページ重量がかなり増加しています。Next.jsはルーティングとハイドレーションのためのバンドルされたランタイム、そしてReactライブラリと共に出荷され、これら両方がより高いページ重量のベースラインに寄与しています。

図14.16. Astro vs Hugo vs Next.js：年ごとのJavaScriptサイズ。

これを純粋に出荷されたJavaScriptに分解すると、Next.jsのJavaScriptバンドルがいかに重いかがわかります。Astroの3.5倍の大きさです。

配信アプローチがコアウェブバイタルにどのように影響するか見てみましょう。私たちは、サイトが以下の条件を満たす場合にGoogleの良好なコアウェブバイタルの定義を使用します：

Largest Contentful Paint (LCP)がユーザーの75%で2.5秒未満
Cumulative Layout Shift (CLS)がユーザーの75%で0.1未満
Interaction to Next Paint (INP)がユーザーの75%で200ミリ秒未満

プリレンダリングは通常、より速いTime to First Byte（TTFB）をもたらし、それは自然にLCPを改善します：ブラウザがHTMLを速く受け取るほど、アセットの取得とページのレンダリングを早く開始できます。これらのサイトは、しばしば開発者によって手作りされるため、CLSのような詳細にもより注意が払われる傾向があります。ハイブリッドはJavaScriptフレームワークと最大のJavaScriptペイロードを多用しており、それが良好なコアウェブバイタルの割合がもっとも低い理由を説明している可能性があります。

成長

では、これらのアーキテクチャはウェブ全体でどのように採用されているのでしょうか？

完全なデータセットを見ると、プリレンダリングアーキテクチャとハイブリッドアーキテクチャは増加傾向にあるものの、ウェブの他の部分と比較するとまだ比較的小規模であることがわかります。これは、ほとんどのウェブサイトが、プリレンダリングおよびハイブリッドカテゴリで一般的な開発者中心のツールではなく、ウェブサイトビルダーやGUIに依存しているため、理にかなっています。

もっともトラフィックの多いサイトにズームインすると、より多くの成長が見られます：

もっとも人気のある上位1kおよび10kのサイトでは、プリレンダリングの採用が大幅に増加しており、1Mマーク以降では成長が頭打ちになっています。これらの高トラフィックサイトは、パフォーマンス、SEO、セキュリティ、安定性を非常に重視しており、これらの原則はプリレンダリングアプローチと完全に一致しています。

ハイブリッドでも同様で、現在ではもっとも人気のある1万のウェブサイトの12%以上を占めています。

結論

今年の際立った特徴は、2024年にトラフィックの多い上位1万のウェブサイトにおいて、プリレンダリングとハイブリッドアーキテクチャが合わせて67%も成長したことです。これらの人気サイトの12%以上が現在、これらのアプローチを使用しています。プリレンダリングとハイブリッド配信は、ウェブ全体という文脈ではまだニッチですが、その利点がもっとも評価される分野で急速に支持を得ています。

ウェブがいかに本質的に静的であるかを考えると、この傾向は有望です。静的ファーストのモデルを採用し、動的コンテンツに動的レンダリングを限定することで、ウェブはより速く、より軽量になるだけでなく、大幅に環境に優しくなる可能性があります。

Hugoはプリレンダリング分野でトップの静的サイトジェネレータとしてリードを続けており、Next.jsがその差を詰めています。Astroは2024年にプリレンダリングフレームワークの中で最大の成長を遂げ、この分野では比較的新しいフレームワークであることを考えると、これは印象的な偉業です。

プリレンダリングカテゴリとハイブリッドカテゴリの両方でNext.jsとAstroの存在感が増していることは、開発者が静的および動的コンテンツ生成をより細かく制御できるハイブリッドアーキテクチャへのシフトを示しています。Astroのパフォーマンス向上とページ重量削減への注力は実を結んでいるようで、Next.jsに追いつく上で大きな進歩を遂げています。

Jamstackという言葉はもはや広く使われていないかもしれませんが、その進化はトップクラスのウェブサイトを動かす未来を形作り続け、より速く、より安定し、安全で、環境に優しいウェブへの道を開いています。