Smashing Magazine の Why Static Website Generators Are The Next Big Thing という記事を読んでの、自分の理解のためのメモです。 直訳というわけでもなく、独自研究が含まれる恐れがあります。

概要

現在の CMS はサーバサイドで動的にHTMLを生成するアプローチが主流ですが、 ブラウザを取り巻く環境の変化や、CDN との兼ね合いで、 静的HTMLを配信してJavaScriptで書き換えるアプローチが重要になりそうです。

サーバサイドで動的なHTML生成を行なうアプローチ

ここで想定しているのは WordPress のようなCMSです。 コンテンツをデータベースに保存しておき、 リクエストに応じて PHP などのスクリプトで動的に HTML を生成します。 いわゆる LAMP スタックの構成となります。

クライアントサイドで動的なHTML生成を行なうアプローチ

タイトルでは静的サイトジェネレータと言ってますが、静的サイトだけでなく、動的なコンテンツも対象です。 つまり、HTML と JavaScript コードを静的ファイルとしてユーザに配信したのち、 JavaScript コードによりコメントなどの動的なコンテンツを取得して表示を切り替えるという手法です。 いわゆる MEAN スタックのような構成で、データベースや API サーバを含むものも想定しています。

サーバサイドでの動的な HTML 生成の問題点

CDNと相性が悪い

たとえばログインが必要なコンテンツでは、ユーザのログイン状態に応じてレスポンスが異なります。 また、コメント機能のついたサイトでは、誰かがコメントするたびに返却されるレスポンスが変わることになります。 このように、サーバサイド動的HTML生成では、 ある URL に対して返却されるレスポンスがデータベースや Cookie の状態などに依存するため、 CDN を利用しようと思うと、キャッシュの管理が非常に難しくなります。

一方クライアントサイド動的HTML生成では、ある URL に対応するレスポンスは一意であり、 デプロイのタイミングで CDN のキャッシュを更新すればよいため、管理が容易です。

遅い

結局のところサーバサイド動的HTML生成のアプローチで どんなにパフォーマンスチューニングを施しても静的なHTML配信にはおよびません。 ただし、ここで重視しているのはファーストビューが表示されるまでの時間で、 すべてのコンテンツが読み込まれるまでの時間ではないことに注意してください。

また、先に述べたようにサーバサイド動的HTML生成でのキャッシュ管理には難しい問題があり、 パフォーマンスチューニングには多大なコストがかかります。

パフォーマンスの重要性については ページが表示されるまでに3秒かかると57%のユーザが離脱する (元記事) という調査に言及しています。 スマートフォンで貧弱なネットワークを介しての閲覧が増えているため、配信の速さは昔よりも重要です。

歴史的経緯

WordPress が登場した当時は Ajax や DHTML が市民権を勝ち得ていませんでしたが、状況が変わりました。 データベースの情報に応じてコンテンツを生成するために、 従来はサーバサイドのスクリプトを利用する必要がありましたが、現在ではクライアントサイドで実現できます。

静的サイトジェネレータ普及のために何が足りないか？

現在、静的サイトジェネレータと呼ばれるツールはざっくり言って Markdown 形式で記述したコンテンツからHTMLを生成してGithubPagesで公開するためのものです(出力形式や公開先で違いはありますが)。 エンジニアが黒い画面を見つめて使うもので、 非エンジニアでもブラウザ上で使えるリッチなエディタや、 複数ユーザを管理するための認証機構などは含まれていません。 あるいは、好みのデザインを探せるマーケットプレイスのようなコミュニティも欲しいところです。

静的HTML配信に向かないもの

大量のデータから検索とフィルタリングで生成されるコンテンツでは、 ユーザに配信してから処理するわけにもいかないので、 サーバサイドでの処理が必要になります。

また、リアルタイム性が高く頻繁に更新されるようなコンテンツでも、 更新のたびに HTML を生成し直すことは現実的でないため、 静的HTMLでの配信ではなく API 経由でデータベースを参照するような形になるでしょう。

まとめ

静的サイトジェネレータというツール群にはまだ足りない部分がありますが、 静的サイト配信という手法は速度や CDN を利用したスケーラビリティの面で有利なので、 今後ますます重要になりそうです。