アプリケーションのチューニング
ウェブでAPIを用意して、リクエストに対するJSONを返すだけのサービスなら、純粋にレスポンスにかかる時間（いかに早くJSONを返すか）に集中してチューニングすればいいかもしれません。
しかし、 多くの場合ウェブはクライアントとして「ブラウザ」が前提になります。また、ブラウザは基本的に人間が使うものです。従って、以下のような観点もチューニングには必要になってきます。
ブラウザの挙動
ブラウザがどのようにリクエスト／レスポンスを処理するかといった挙動を理解することは重要です。そこを理解しないと、効率よくブラウザにコンテンツを届けられず、思ったような速度が得られない場合があります。
人間への視覚フィードバック
ブラウザを使って人間が操作することを想定しているならば、視覚的なフィードバックを調整することで「速いと感じる」という観点からチューニングするアプローチもあります。実際、純粋なレスポンスタイムの短縮が限界にきたら、こうした観点のチューニングは避けては通れないでしょう。
こうしたベストプラクティスについては、ハイパフォーマンスウェブサイト で「14のルール」としても紹介され、 続・ハイパフォーマンスウェブサイト では、そこにモダンな技術も追加されています。両方を手元に置いておくことをお勧めします。
「推測するな、測定せよ」
「推測するな、測定せよ」という言葉があります。全てのチューニングは、ボトルネックの把握が必要です。やみくもにチューニングすればいいというものではありません。場合によっては遅くなるケースも考えられます。
この連載では、テーマごとに「なぜそれらが作られたのか」を重視して解説します。そこから学べるものが多いからです。しかし、筆者は連載を通して、「入れると速くなるから、今すぐ入れましょう！」などというつもりは一切ありません。
もし、紹介したものから何かを導入するのであれば必ず測定をし、効果と対応クライアントなどをきちんと確認した上で、自己責任で進めて下さい。 また導入した場合は、ノウハウや効果をBlogなどで是非公開して下さい。それは貴重な情報であり、 “Make the Web Faster" にとって大きな貢献になります。
※この記事はHTML5 Experts.jpのIntro – Webを速くするためにGoogleがやっていること Make the Web Faster 00 -をZDNet Japan編集部が加筆、修正したものです。
- Jxck
- ウェブ アプリ開発技術関連から始まり、アーキテクチャからプロトコルまで手を出す ウェブ 系エンジニア。セマンティクス厨、 REST 厨、テスト厨、リアルタイム厨などをこじらせ、Node.js の WebSocket 系モジュールである Socket.IO の啓蒙やマニュアル翻訳活動などを実施。現在は SPDY/HTTP2.0 周辺に興味を持ち勉強中。CROSS 2013 では「次世代 Web セッション」を担当し、今 Web において「なにが起こっているのか」「どこに向かっているのか」 この二つを軸に議論。Web+DB press にて WebSocket や SPDY の特集を担当。他にも Node.js の勉強会、 Go の勉強会なども主催している。
