Webページの静的生成と動的生成のどちらが良いかはサイトの性質とポリシー次第。
公開日 : 2007-06-24 22:34:38
(追記)一連のエントリーの成果品? が出来ました。
MT3/4両対応。エントリーアーカイブへの最初のアクセスがあった時点で再構築(静的ファイル生成)を行うMovable Type用のプラグイン+αのプラグラム群です。(追記ここまで)
「静的生成だとリビルドに時間がかかりすぎる。記事数が増えるにつれ、どんどん時間がかかるようになって来た。このツールは重すぎて使えない。動的生成の CMS に乗り換えたら快適になった。動的生成最高。」
「動的生成だから軽い。だからWordPressだよね!」っていうのは「俺のBlogアクセス殆どねぇから」という発言とセットである場合は正しいわけです。
アクセスが多い場合、そうは言っていられません。再構築は不要ですが、逆に閲覧時に負荷がかかります。Yahoo! Newsなんかにとりあげられたら(僕のBlogではそんなことまずあり得ませんが)データベースが悲鳴を上げることは間違いありません。
サイトの特性やアクセス状況等の前提の議論もなく「再構築不要、動的生成マンセー!」って言っている人はバカです。
動的生成と静的生成どっちが良いってのは、状況とサイトの性質、ポリシーによるのです。
「1000ページあるBlogがあって、毎日1エントリー追加。1000ページのうち900ページは5日に1回しかアクセスされない。最新の100ページはそこそこアクセスされる」というケースで、毎日1000ページすべてを再構築するのは時間の無駄ですから。
(こういったケースでは、比較的アクセスの多い100ページは静的ページを再構築してその他のページを動的生成にすると幸せになれます。)
表示されりゃぁOK! であれば別の解決方法もあります。
その昔、JavaScriptが登場した時に(こんな話すると年齢がばれるわけですが)、「JavaScriptはクライアントマシンで実行されるからサーバーでCGIを起動させる負荷が生じない」という説明がなされていてそれは正しいってことが改めて証明されている昨今ですね。
『各ページ共通部分で更新の頻繁な「最近のエントリー」とかいっそのことJSONかXMLで構築してJavaScriptで引っ張ってくればいいのに』っていうのがもうひとつの解決策です(もっと単純にObject要素でインクルードしてしまう手もあります)。
「やっぱりHTMLとしてStrictなものであるべきだろうしそれってアクセシビリティ的にどうなのよ」みたいな考え方はGoogle AdSense(このblogもそう)やその他のブログパーツを貼りまくったことでクライアント側が「重いなぁ」って感じるサイトにおいては何の説得力も持ちません。
もちろん再構築の負荷や時間を短縮するための正攻法ってのも存在します。まずはやれることからやるべきでしょう。このBlogでは以下のような考え方で再構築時間を短縮しています。
一方で動的生成の場合はサーバー・クライアント双方でのキャッシュの使い方次第で負荷軽減が可能です。サーバー側のキャッシュについては後述しますが、クライアントマシンのキャッシュを上手に使うためにはHTTPヘッダの扱いを工夫します。
以前に少し触れましたが、「動けばオッケー」的なWebアプリではHTTPヘッダとか殆ど意識されないケースが多いようですが(自分が作る時もそういう傾向は無きにしもあらず、ですが本当に負荷やレスポンスを考えるのであれば真っ先に検討すべき課題です)、この部分(HTTPヘッダによるクライアントのキャッシュの利用)の工夫をするかどうかでレスポンスや負荷は大きく変わって来ます。
但し、この方法の有効度合いもサイトの性質やユーザーの性質によって変わって来ます。
リピーターが比較的多い場合には、このようにクライアント・キャッシュを有効に扱う効果が最大限発揮されます。一方で、「リピーターはあまりいない」のであればこの方法はあまり効果を発揮しません。
そう、つまりはサイト次第なのです。
「何を重視するか」によっても変わって来ます。
「とにかくページが見られること」が最優先であれば断然静的生成です。データベースが悲鳴を上げてもページは閲覧できますし、サーバーが死んでもファイルのバックアップをどこかにコピーすれば見ることができます。
一方で、動的に動く部分(BBSやフォーラム、Wikiとか主体で動的に動く部分)が死んだらサイトとして成立しないような場合、例えばコミュニティサイト等なんかであれば、ページが見えても「使えない」わけですから、負荷はおさえる工夫はするにしても動的生成で運用すべきです。というか動的生成でないと使えません。
最後に(ここが本論なのですが)、サーバー、クライアントのキャッシュを上手に使いつつ、最初の動的生成時に静的ファイルを生成してしまう、って言う方法が実は一番合理的じゃないかと思っています。つまり、はじめてそのページにアクセスしたユーザーが「再構築」の負荷を負担する、という方法です。この方法であれば「アクセスの無い古いコンテンツ」は再構築の必要もなく、コンテンツ制作者にも全体再構築の負担がなく、最初のアクセス以後は静的生成されたページを送り返すだけですから。
このあたりの思想? をCMS(多分MTになるんでしょうが、他にも選択肢はあるでしょう)に反映させたようなソリューションを作りたいと考えています。
追記:
キャッシュの実装方法にも色々あるけれど、昔MacOS9でWebサーバーを動かしていたとき(10年くらい前) は「すべてのコンテンツをメモリに入れてしまう」という方法をとっていたなぁ。かなり強引なやり方だけどそりゃぁ(当時としては)高速だった。
