EvidenceによるBI入門 #003.1

Evidenceを理解する上でのポイントとして、静的サイトジェネレータを箸休めとして説明します。

まず、静的サイトと動的サイトの区別からです。静的サイトとは、コンテンツがファイルとして固定され、サーバはリクエストに基づきただ配信するだけのものです。初期のホームページと言われたもののスタイルです。

次に動的サイト、これはリクエストに応じて何らかのコードがサーバ上で実行され、動的にレスポンスが生成され、それがクライアントに返されるものです。WordpressなどのBLOGサービスなどはこの形態です。

静的サイトとは

Wordpressなどではコンテンツはデータベースに格納されたものがベースで、同じようにテーマなどの情報がデータベースに格納され、それがユーザのリクエストによって組み立てられて返答されるという構造です。

静的サイトと動的サイトの差異

これだけで「静的サイトジェネレーター」のすべてがわかりますを参考にすれば以下のように纏められます。

Wordpressなどが動的サイトとして構成されたのは、データベースにコンテンツ、テーマを格納しそれをリクエスト時に構築するという構造が都合が良かったためです。

静的サイトが再度注目された理由

しかし、今、再度、静的サイトジェネレータが注目された理由があります。まず、宿命的に表示されるコンテンツをユーザに合わせてというのは苦手ですが、通常のBlogサービスであれば、読者は通常ログインなどの手続きをしないため、ユーザに合わせては要件から除外できます。そうすると、動的サイトのメリットはかなり減ります。恐らく、GUIでのWebベースでのコンテンツメインテナンスなどのこの表に書かれていないモノになるでしょう。

そして、「全員に同じページを表示する」であれば、コンテンツへのテーマなどの適用はアクセス時にこだわる必要性はないになります。よって、バッチ的にサイトをコンテンツから生成する静的サイトジェネレータとなるわけです。

静的サイトジェネレータを支える要素

静的サイトジェネレータが注目された理由はそれだけではありません。一つはクライアント端末の性能向上です。例えば、昔の携帯電話のパフォーマンスと今のスマートフォンのパフォーマンスを比べてください。昔の携帯電話、フィーチャーフォン向けに開発された、CHTMLなどはかなりの仕様を削減していました、当然、クライアント側でのコード実行などは考えてすらいませんでした。しかし、今のスマートフォンはクライアント側でのモバイルコードの実行には十分であり、ECMA Script、WebAssemblyなどの支援もあります。故にコードの実行をWebサーバからクライアントに移すことも可能になりました。

故に、無理に、サーバ側で全てのコンテンツをレンダリングする必要はなくなりました、また、動的コンテンツを残すとしても、インラインフレームなどで組み込みむ手段もあります。従って、メインのコンテンツを動的に生成することは必ずしも必要なくなくなりました。

静的サイトジェネレータの限界

とはいえ、最初に上げた、「全員に同じページを表示する」という特性は無くなることはありません。

従って、静的サイトジェネレータを基盤とするBIツールであるEvidenceでは例えば、ユーザを認識してコンテンツを変えるなどは苦手です。例えば、厳密に、Need-to-Knowを実現するのは困難です。サイト自体に認証などは出来るにしても、コンテンツをユーザに合わせてレンダリングするのは困難です。

この辺のポイントを理解するのが、Evidenceを有効活用する道になります。