Jxck

Intro – Webを速くするためにGoogleがやっていること Make the Web Faster 00 –

連載: Make the Web Faster (1)

今回から数回にわたって、Googleが進める”Make the Web Faster” というプロジェクト(以下、プロジェクト)について、プロジェクトにリストされたGoogleのプロダクトや仕様提案、ベストプラクティスなどを連載形式で紹介していきます。

Make the Web Faster

“Make the Web Faster” のページには、文字通り Google が 「Webを速くするため」に開発したプロダクトや、新しい仕様の提案、ベストプラクティスなどがリストされています。

例えば以下のようなものがあります。

  • WebP
  • TCP Fast Open
  • Google DNS
  • Google Hosted Libraries
  • Page Speed
  • SPDY
  • etc.

shoto1

この連載では、そこから特に重要なものを、筆者の気の向いた順に紹介していきます。

そして、連載初回の今日は、これら “Make the Web Faster” を紹介するにあたり、共通して押さえておくべき基本知識について紹介します。

Web というターゲット

プロジェクトには様々な手法がリストされていますが、全てに共通するのは「Webの高速化」を目的としている点です。対象がWebであるために、共通するチューニングの観点としては大きく「ネットワーク」と「アプリケーション」の2つが考えられます。

ネットワークのチューニング

Web はネットワークへのアクセスを伴います。ネットワークを効率よく使うことは、パフォーマンスの改善を試みる上で非常に重要です。

まずは、一番簡単な原則としてこれだけは覚えておいてください。

なるべく小さく

Webは、HTML,CSS,JS,画像,動画などのデータをネットワーク経由でクライアントに届けています。このデータが小さければ小さいほど、速く届けることができます。特に画像や動画はサイズが大きくなりがちです。送る上でなるべく小さくするにはどうするか、ここで圧縮などの技術が有効になります。

なるべく少なく

ネットワークアクセスの回数が増えるほどオーバーヘッドが大きくなるため、極力少ない方が望ましいです。アクセス回数を減らす工夫や、プロトコル仕様レベルの改善などがあります。

なるべく近く

ネットは世界の裏側でも簡単にデータを届けることができますが、遠ければそれだけ遅くなってしまいます。しかし、コンテンツの種類によっては、ユーザに近いところにそれを配置するなど、工夫できるところがあります。

他にも HTTP と TCP についての基本的な知識が必要な回もあります。そうした場合は、3 Minutes Networking や、現在執筆が進んでいる High Performance Browser Networking などが参考になるでしょう。(この本はすでにHTTP2.0など最新のトピックも扱っています。)

アプリケーションのチューニング

WebでAPIを用意して、リクエストに対するJSONを返すだけのサービスなら、純粋にレスポンスにかかる時間(いかに早くJSONを返すか)に集中してチューニングすれば良いかもしれません。

しかし、 多くの場合Webはクライアントとして「ブラウザ」が前提になります。また、ブラウザは基本的に人間が使うものです。従って、以下のような観点もチューニングには必要になってきます。

ブラウザの挙動

ブラウザがどのようにリクエスト/レスポンスを処理するかといった挙動を理解することは重要です。そこを理解しないと、効率よくブラウザにコンテンツを届けられず、思ったような速度が得られない場合があります。

人間への視覚フィードバック

ブラウザを使って人間が操作することを想定しているならば、視覚的なフィードバックを調整することで「速いと感じる」という観点からチューニングするアプローチもあります。実際、純粋なレスポンスタイムの短縮が限界にきたら、こうした観点のチューニングは避けては通れないでしょう。

こうしたベストプラクティスについては、ハイパフォーマンスWebサイト で「14のルール」としても紹介され、 続・ハイパフォーマンスWebサイト では、そこにモダンな技術も追加されています。両方を手元に置いておくことをお勧めします。

「推測するな、測定せよ」

「推測するな、測定せよ」という言葉があります。全てのチューニングは、ボトルネックの把握が必要です。やみくもにチューニングすればいいというものではありません。場合によっては遅くなるケースも考えられます。

この連載では、テーマごとに「なぜそれらが作られたのか」を重視して解説します。そこから学べるものが多いからです。しかし、筆者は連載を通して、「入れると速くなるから、今すぐ入れましょう!」などというつもりは一切ありません。

もし、紹介したものから何かを導入するのであれば必ず測定をし、効果と対応クライアントなどをきちんと確認した上で、自己責任で進めて下さい。 また導入した場合は、ノウハウや効果をBlogなどで是非公開してください。それは貴重な情報であり、 “Make the Web Faster” にとって大きな貢献になります。

Powered byNTT Communications

tag list

アクセシビリティ イベント エンタープライズ デザイン ハイブリッド パフォーマンス ブラウザ プログラミング マークアップ モバイル 海外 高速化 Angular2 AngularJS Canvas Chrome Cordova CSS de:code ECMAScript Edge Firefox Google Google I/O 2014 HTML5 Conference 2013 html5j IoT JavaScript Microsoft Node.js PhoneGap Polymer React Safari SkyWay TypeScript UI UX W3C W3C仕様 Webアプリ Web Components WebGL WebRTC WebSocket