オープンソース・ソフト Drupal を使った Web サイトの構築・サポート・研修

分離された Drupal の未来(2/3)

この記事は長いので 3 つに分けてあります。他の部分へのリンク:1/33/3

BigPipe を使ったプログレッシブなレンダリング

完全に分離したアーキテクチャーではパフォーマンスの損失もあり得る。ユーザーには求めている情報をできるだけ早く見せてあげたい(「最初の描画までの時間」を指す)。そして、希望する行動をできるだけ早く起こせるようにしたい(「インタラクションを起こすまでの時間」)。うまく設計された CMS はクライアントサイドのフレームワークに対して、その利点を備えている。

(例に話を戻すと)音楽 Web サイトから送信したいコンテンツの多くはキャッシュ可能であり、ほとんどは静的なものだ。すなわち、ナビゲーション バー、繰り返し出てくるフッター、そして他の変化しないコンポーネントだ。それでも、従来のページ配信モデルの下では、実行に時間がかかるオペレーションは、パイプライン内にある、ページ上のよりシンプルな部分に足止めを食わせる可能性がある。そうすると、クライアントへの応答は顕著に遅れることになる。僕たちの音楽サイトの例でいえば、これは、ユーザーが先週いちばん聴いた曲、そして音楽プレーヤーで今、再生されている曲が入っているブロックであるかもしれない。

僕たちにとって本当に必要なのは、これらコスト(処理の手間と時間)のかかるコンポーネントを選択的にあとで処理し、それほどコストのかからない部分を先に送信するための手段だ。クライアントサイドのダイナミックなコンテント置換のアプローチである BigPipe があれば、ページを段階的にレンダリングできる。まず、ページの骨格がロードされ、そのあとで「先週いちばんよく聴いた曲」なり「現在再生中」なりといった高コスト(expensive)なコンポーネントがブラウザーに送られ、プレースホルダー(割り当てスペースの枠組み)を埋める。このコンポーネント駆動型のアプローチを使えば、僕たちにとっては両方の世界のいいとこどりになる。つまり、最初のインタラクションが瞬時に行える非ブロッキングのユーザー インターフェイス、そしてテーマ レイヤーを活用しながらも Drupal のページ全体をすばやく断片的にロードできるということだ。

現在のところ、Drupal 8 は BigPipe をガッチリと全面的に統合している唯一の CMS だ。その統合はコア モジュールと拡張モジュールの両方に当てはまる。拡張モジュールはただ、キャッシャビリティー メタデータを備えてさえいればいい。技術的な細かいことを知っている必要はない。Drupal 8 の Dynamic Page Cache モジュールはページの骨格がすでにキャッシュされていること、すなわち、すぐに送信できることを保証する仕組みになっている。たとえば、多くのユーザーにとってメニューは同じなので、同じメニュー リンクにアクセスできるユーザーに対してはメニューを再利用しても構わない。だから、Dynamic Page Cache はそれらをページ骨格の一部としてキャッシュすることができる。その一方で、ユーザーがいちばん再生した曲を含むパーソナライズされたブロックをキャッシュするのは、それほど効果的ではない。そのため、ページ骨格が送信されたあとでレンダリングされることになる。このキャッシャビリティーはコアに組み込まれていて、拡張モジュールはすべて、それに不可欠なメタデータを提供する必要がある。

完全に分離されたサイトが、BigPipe を使用している高度にパーソナライズされた(独自に調節されつくした)Drupal 8 よりも迅速にロードするためには、Drupal の精巧なキャッシング機構を大方そっくり構築し直し、そのキャッシュをクライアントに保存し、そのクライアント キャッシュを継続的にサーバー データと同期する必要がある。それに加えて、JavaScript をパースし、実行して HTML(コード)を生成するのは単に HTML をダウンロードするよりも時間がかかる。特にモバイル機器上ではそうだ。結果として、このチャレンジに打ち勝つには、極めて高度にチューニングされた JavaScript(コード)が必要になるだろう。

また、すべてのレンダリングをクライアントサイドで行うことによって、クライアントサイドのフレームワークは、避けられない重大なトレードオフに直面することになる。すなわち、モバイル機器など、接続速度が低い場合、クライアントサイドでレンダリングを行えば、パフォーマンスが低下し、バッテリーはより速く消耗し、ユーザーは待たされる羽目になるということだ。ほとんどの開発者は、現実世界のネットワーク状況下にある実際のデバイス上ではなく、ローカル環境でテストを行う。だから忘れてしまいがちなのだが、遅いこと、頼りにならないということの本当のリスク、特にそれが不安定な接続からきている場合、そのリスクには、完全に分離されたあらゆるサイトが直面し続けることになる。それが Drupal であろうとなかろうとだ。

プログレッシブな分離こそ未来

プログレッシブな分離

プログレッシブな分離の下では CMS レンダラーはまだページの骨格を出力する。

ここまでに見てきたように、完全な分離では肝心な CMS 機能と BigPipe レンダリングが取っ払われてしまう。でも、その両方とも持ったまま分離できたとしたらどうだろう?レイアウト マネージメント、セキュリティー、アクセシビリティーを保持したまま分離し、それでもなお、リッチなインタラクションを備えたシングル ページのアプリケーションが与えてくれる恩恵をすべて享受できたとしたら?さらに大事なのは、BigPipe を利用してインタラクションまでの時間が縮まり、コンテンツをたっぷりパーソナライズするための障壁が減ったことをうまく活用できたらどうだろうかということだ。その答えは分離されたコンポーネント、あるいはプログレッシブな分離にある。ページ全体ではなく、ページの一部を分離するという方法を使わない手はないだろう。つまり、個々のブロックなどのことだ。

このコンポーネント駆動型の分離アーキテクチャーは完全分離型と比べて大きなプラス点を備えている。すなわち、従来型のコンテンツ マネージメントとワークフロー、そしてディスプレイとレイアウトのマネージメントはまだサイト構築者が利用できるということだ。例の音楽 Web サイトの話に戻るなら、僕たちはユーザーが先週いちばんよく聴いた歌の入っているブロックをページ内の任意の区域へドラッグすることができる。そうしたら、フロントエンド開発者はそこにインタラクティビティーを吹き込める。アカウント保持者(ユーザー)はそのリスト上の曲をすぐに再生したり、お気に入りリストに加えたりすることができる。そうしているうちに、もしアカウント保持者が「先週いちばんよく聴いた曲」のブロックをページ内の右サイドバーから左サイドバーに移動させたくなったら、マウスを数回クリックするだけで実現可能だ。フロントエンド開発者を巻き込むようなことではない。

僕たちはこのアプローチを「プログレッシブな分離」と呼ぶ。それは、ページのどれだけの部分を分離するか、Drupal のフロントエンドあるいは Drupal の専用レンダリング機能からどのコンポーネントを分離するかは自分で決めるからだ。この理由から、プログレッシブに分離された Drupal は「組み立てられた Web(the assembled web)」に分離をもたらす。僕はその「組み立てられた Web」の熱烈なファンだ。というのも、サイトの構築者や管理者が(それほど)プログラミングなしですばらしい Web サイトを構築できるようにするのは重要なことだからだ。Drupal には、この能力が独特に備わっている。というのもまさに、Drupal では分離の度合いをいろいろと変えられるからだ。

Drupal 8 は競合製品よりも先を行っている。分離された Web サイトを構築するなら選択するプラットフォームは Drupal だ。Drupal には、すべてのコンテンツ用の REST API、Drupal のデータを照会するシステム(たとえば Views モジュールにおける REST エクスポート)、そして実装された BigPipe が備わっている。また、REST に対応した拡張モジュールがひととおり出そろえば、それはさらによくなる。

Drupal 8 では、完全な分離か従来の Drupal のままかという単なる両極端があるだけではなく、それを超えたエキサイティングな領域が広がる。これまでに見てきたように、完全な分離は、ひとつの Drupal 実装に向けた扉を開いてくれる。その実装は、単独または複数のクライアントからなる広い範囲に向けてコンテンツを提供する(「多頭(many-headed)」の Drupal)。すなわち、モバイル アプリ、インタラクティブな販売サイト、テレビ セットといったようなものだ。しかし、プログレッシブな分離はさらに一歩先へと進む。というのも、Drupal サイトは単独で、かつ、コンテンツを組み立てるツールをそっくり備えたまま、完全な分離とプログレッシブな分離を(同時に)行えるからだ。