こんにちは、ふろしきです。HTML5 Conference 2016の当日は、38度近くの熱があり、発表時はろれつが回ってませんでした。しかし、伝えたいことは伝えられたと思っています。その内容とは…

「この1年でWebのパフォーマンスの技術にどんな動きがあったのか」

というダイジェスト。ここで話した3つのテーマについて、本記事でもご紹介。

1. レイアウト処理を減らす

HTML5がバスワードするよりもずっと前から、CSSでアニメーションさせることはごくごくあたりまえ。JSが扱えないデザイナーであっても手軽にアニメーションできる良い世界になりました。しかしそこに、モバイルが出現したことで、JSだけで満足という人たちもCSSの機能を活用しなくてはいけなくなりました。

モバイルのUIによくありがちなのが、あるコンポーネントの形状を変化させるようなアニメーションや、スワイプ操作のような指の位置に応じてコンポーネントを動かすもの。それを描画するとなると、CPUはあまりにも非力で、GPUの力を借りることが求められています。CSSはGPUと相性がよいため、JSからCSSの機能を呼び出して効率的にGPUを活用するということが求められています。

そのアプローチについては、HTML5 Experts.jpでも「モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI」で紹介していますので、本記事では簡単にだけ説明。

GPUでできることは、極めてシンプル。ある四角形の描画結果を、どの位置に表示させるのか、拡大縮小させるのか、回転させるのか、といった変更加えるだけ。それだけでいいというのであれば、CPUを介さず、GPUのみで描画処理を完結させることができます。

これをブラウザで行う場合は、ある特定のDOMとその配下にあるDOMの描画結果をGPU側に転送し、GPU側にどういう描画を行わせるのか指示を送ることで、高速に処理させます。その間、操作はすべてCSSのプロパティを使って行うことになります。

CSSも、従来の left や top といった、レイアウトを操作するようなものではなく、 transform プロパティ経由で指定。 JS上で、以下のように指定することで、CPUによるレイアウト処理を避けつつ、GPUで描画の位置のみを変えるというもの。

// ある要素の横の位置を移動
elem.style.transform = `translateX(#{position}%)`;

この方法は一昔前には泥臭いとされ、バッドプラクティスと考えられていました。しかしそれも、最近は will-change というCSSプロパティが正式に標準化の流れに入ったことで、考えが改められています。GPU上に描画結果を保存させるのはバッテリー消費が大きいため、開始時に will-change: transform; で有効にし、終了時には will-change: none; で解除する、という流れになります。

簡単な例をあげると、以下の通りです。

// スワイプ時、指の位置にあわせてコンポーネントを左右に動かす。
class MovableComponent {
  constructor(elem) {
    this.elem = elem; // 動かす対象のコンポーネントのDOM
  }
  // ある要素の横の位置移動を開始
  function begin(beginX) {
    this.x = beginX; // 開始位置をセット
    this.elem.style.willChange = 'transform'; // GPU側に描画結果を置く
  }
  // 位置を変更(指の位置がかわるごとに呼び出される)
  move(currentX) {
    this.x = currentX; // 現在の位置をセット
  }
  // 描画(requestAnimationFrameで毎回呼び出される)
  render() {
    this.elem.style.transform = `translateX(#{this.x}px)`;
  }
  // 横移動の完了
  end() {
    this.elem.style.willChange = 'none'; // 解除
  }
}

2. スクロールイベントを減らす

ブラウザのscrollイベントが、スクロールの滑らかさを落としてしまう。とはいえ、「どれだけスクロールされたのか？」というのに応じて何かしらのJSの処理を動かしたくなるという需要はなくならず、できるかぎりパフォーマンスを上げようという努力はされてきました。

2015年の4月にChromium Blogにポストされた「Chromium Blog News and developments from the open source browser project 」は有名な話です。Chromeではブラウザ上で動作するタスクに優先度を与え、JSの処理やブラウザ側の内部で行われる処理のうち、スクリーン上への描画が関わるタスクを優先的に扱うようにすることで、スクロールの滑らかさを損なわないようにしようという取り組み。確かに、ユーザーの体感としてパフォーマンスは上がったようにみえるでしょう。

しかしこの問題、その本質は、イベント自体が無駄に多く呼び出されてしまっているというところが大きかったりします。したがって、ユーザーワールド側でも、scrollイベントを毎回素直に実行するのではなく、頻度を落として実行するThrottlingという方法が一般的になっています。

これらはパフォーマンスを改善する上で、たしかに有効ではあります。ただ、デベロッパーが本当にやりたいことに目をむけ、そこにより特化した機能をブラウザ側が持てば、もっと良い解決につながるのは間違いありません。ハードウェアが貧弱で、スレッドの扱いに制約の多いブラウザでは、そこに踏み込んだアプローチが求められています。

scrollイベントの利用ケースで、かなり多いもののひとつに「画像の遅延読み込み」があげられます。例えば、ATF(Above The Fold : Webページアクセス直後にスクリーン内に映り込む領域)の表示を速くしたい！それこそ、headタグ内の大量のCSSファイルやトップの巨大な画像ファイルに帯域を譲らないことには高速化が困難ということになれば、ATF外にある画像ファイルは後から読み込んだほうがいい、ということになります。もちろん、サーバーの負荷を下げるという用途でも活用されるでしょう。

それを解決する方法として、Web標準「Resource Priorities」にて、lazyloadというプロパティをHTMLのタグに追加しようという流れが生じ、IE11にも実装されたのですが、「そもそもそういう用途で使われるようなプロパティは追加されるべきなのか？」「本来JSであったり、より低レイヤーなアプローチで解決すべきでは？」という意見もあり、削除されてしまいました。

あれから2年が経ち、lazyloadは理想的な形で実現できるようになりました。それが「Intersection Observer」です。

Intersection Observerは、スクロール時に特定のDOMがスクリーン上に現れるタイミングでイベントを発火させてくれます。したがって、scrollイベントよりも軽量な上、scrollイベントの多くのユースケースを巻き取ることができます。そもそもDOMの位置を取得する、scrollTop、offset、getBoundingClientRect、といったプロパティやメソッドは、本記事の1章でもあげたような、レイアウト処理というヘビーな処理を呼び出しのタイミングで必要とする場合がある。それも無くなるとなれば、一石二鳥でlazyloadのような類の処理を最適化できるというわけです。

以下、使い方の例。jQuery.lazyloadのようなものを実装するとしたら、以下のようになります。

// 遅延読み込みをさせる専用のObserverを生成
let imageLazyLoader = new IntersectionObserver((changes) => {
  // イベント発火のタイミングで、遅延読み込みさせる
  changes.forEach((change) => {
    let image = change.target;
    image.src = image.getAttribute('data-original');
  });
}, {
  rootMargin: "120% 0" // 読み込みを開始するタイミング
});
// 遅延読み込みさせたいimg要素を取り出し、Observeさせる
let images = Array.from(document.querySelectorAll('img.lazyload'));
images.forEach((image) => {
  imageLazyLoader.observe(image);
});

3. タスクキューの待ちを減らす

最後に、タスクの最適化の話です。ここの話については、ピクシブのブログのエントリー「JSがブラウザを固めてつらいので、新しいAPI「requestIdleCallback」を使うことにした」でも取り上げてますので、ざっくりと背景と概要を。

元々は、2016年頃にMicrosoft側が「setImmediateをちゃんと実装しよう！」と。Microsoftのプラットフォームにおいて、多くのユーザーがsetImmediateを利用しているということを、W3C Web Performance WGのMLで問題提議し、 setTimeout(fn,0) を使ってタスクを遅延実行させるバッドプラクティスを緩和しようという提案から始まった話です。こうした悩みは「requestAnimationFrameで解決されるものだ！」という意見もあったのですが、現実問題としてはそうはうまくいかないというのは、フロントエンドをやっているエンジニアなら感じられたはずです。

そもそもこの問題はどこから生じたのか？一昔前のビデオカードが、１つのスレッドでしか描画を扱えないという制約があった。そういった背景もあり、現在のブラウザもまた、ブラウザの内部の処理からJSで実装したユーザーワールドの処理に至るまで、その多くのUIスレッドと呼ばれる単一のスレッドだけで処理しざる得ない状況となった。その恩恵というべきか、JSはこれだけ単一スレッドで処理実行させることに進化したのですが！JSでやることが多くなってしまった今、本記事の2章でも語られたような「タスクの優先度」に手を加えないことには、解決出来ない問題も多くなったのです。

こうした中ででてきたのが、requestIdleCallbackという機能です。

2章にもでてきた、Chromeのスクロールパフォーマンスを改善した、パフォーマンス周りを専門としているGoogleのエンジニアRoss McIlroyら。彼らが、Microsoftがだした「setImmediateを全ブラウザでちゃんと実装しようぜ！」という案をはねのけて提案したのがこのrequestIdleCallback。

scrollイベントの改善で、彼らはあくまでブラウザ側のタスクの優先度に対して手を加えたわけですが、ここにきてデベロッパーが作ったJSの処理。ユーザーワールドで実行されるものについても、優先度のようなものを与えて、タスクが実行されるタイミングをうまく制御しようという提案をしたのでした。scrollイベントで培ったノウハウを広げようとしたんだろうなぁと、私は推測してます。

requestIdleCallbackはどういうものか？scrollイベントの一件では、緊急度の高いブラウザ内のタスクを、あらゆるタスクよりも優先して速く実行するというものでした。一方でrequestIdleCallbackは、ユーザー側の体験としてパフォーマンスが低いという状況を生み出しがちな、緊急度が低いユーザーワールドのタスクを、あらゆるタスクよりも低く実行するというもの。ブラウザ側だけじゃ限界があるから、デベロッパー側でもなんとかする術というのを提供したといったところです。

その仕組はとてもシンプルで、処理されることを待っているタスクがあれば絶対に実行しない。無ければそのタイミングで実行しようというもの。

サンプルは以下の通り。

var hd = requestIdleCallback( => {
  // タスクキューが空になってから実行されるタスク
},{
  timeout: 10000 // 何msであきらめるか。
});

最後に

CPUからGPUに処理を移したいというお話から、それでもどうしようもないシングルスレッド問題を、いかにして効率的に運用するのかというお話まで。GPUがデベロッパーを幸せにしたり、不幸にされたからどうにかしようとしたり、という感じで、GPUとブラウザのパフォーマンス問題は切っても切り離せないようですね。

ちなみに、この記事を書いている今、TPACというイベントが開かれ、パフォーマンスに関する議論も行われています。そこでは様々な議論が繰り広げられているのですが「Measuring and improving scroll latency (~30m; rbyers)」というスクロールをもっと良くしようよという話や、「Paint metrics」といったレイアウト処理のさらに先の描画系の発展的な話であったり、「Long Tasks API」みたいな、requestIdleCallbackとか以前にタスクの処理時間長くね？ってところをなんとか変えていこうよという議論もあったりします。

個人的に注目しているのは、以前からデベロッパーの間で薄っすら思われていた、SPAの時にブラウザのナビゲーション計測系のAPIが役に立たないのだけどどうするの？って問題に注目しているところです。SPAと一言でいっても、Ruby on RailsのTurbo Linksのようなものもあり、ブラウザの持つページ遷移機能が活用されないケースがある中で、パフォーマンス計測はどうあるべきなのか。「ナビゲーションの開始」と断定することが困難であり、それゆえに画面の切り替わりにどの程度の時間がかかったのかわからないこの問題を、今後どう扱うのかが議論されるようです。

一通り終わったなぁ、パフォーマンス周りの機能整備、なんて思ったのですが、よくよく考えたら実態にそこまで即した感じでもないんですよね。今後も様子を見ておきたいと思います。それでは！

HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。

GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します.

Make the Web Faster: TCP Fast Open

3 Way Handshake

TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状態をきちんと確認しながら実施するための 3 Way Handshake (以下3WH)という方式を採用しています。

例えば、クライアントがサーバに対してHTTPリクエストを送信したい場合は、以下のような流れになります。

クライアントは、3WHが終わってはじめてHTTPリクエストを送信できるため、HTTPのリクエストを送るまでにはTCPのレイヤで三回の通信が必要になります。 HTTPでは、Keep-AliveなどでTCPコネクションを使いまわすこともできますが、それでも切断と接続の頻度は多いのが現状です。

そこで、3WHの通信を「なるべく少なく」することで、接続確立の高速化を図る方法が、今回紹介する TCP Fast Open (以下TFO)です。

なぜ3WHを使うのか

わざわざ三回も通信を行う3WHを用いる理由はいくつかありますが、その一つとして、クライアントIPの確認があります。

クライアントSYNが含まれるパケットにはクライアントのIPアドレスが載るため、サーバはそのアドレスにレスポンスを返すのですが、このIPは簡単に偽装することができます。

そこで、HTTPのやりとりに移る前に、クライアントのアドレスに対してサーバからもSYNを送ります。 もしこのとき、アドレスが偽装されたものであった場合、その機器が実在したとしてもサーバからのSYNは無視されるため、HTTPのやりとりに移る前にアドレスが正しいことを確認できるのです。

TCP Fast Open

TFOは、簡単に言えばTCPレイヤでCookieを用いることで、すでに接続を確立したことがあるIPアドレスのホストに対しては、3WHを簡略化するという方式です。

Cookieを用いるため、まったく初めて接続する(Cookieを保持していない)ホストに対しては通常の3WHを実行し、その時ホストがCookieを発行します。 二回目以降の接続確立では、クライアントはそのCookieをサーバに送信するという流れになります。

では、通信の詳細を見てみましょう。

次に解説する流れは、TCPコネクションを確立した後にHTTPのGETリクエストを発行し、レスポンスを受け取るところまでの範囲とします。 この時、HTTPのリクエストの受信、レスポンスの送信はサーバの責務ですが、リクエストデータを処理しレスポンスデータを生成するのは、アプリレイヤの責務であるという前提を踏まえて読んでください。

最初の接続

この時点ではサーバとクライアントが有効なCookieをお互いに保存していません。

1. クライアントは、SYNに Fast Open Cookie オプションにCookie Requestをつけて送信する。
2. サーバは、 TFO-Cookie を生成し、それをFast Open CookieオプションにつけたSYN-ACKを送信する。
3. クライアントは、TFO-Cookieをキャッシュする。
4. クライアントは、ACKを返し、通常の接続確立を終える。
5. クライアントは、HTTP GETリクエストを送信する。
6. サーバは、HTTP GETクエストをアプリレイヤに渡し、アプリが生成したレスポンスデータをレスポンスとして送信する。

通常の3WHと違うのは、SYNとSYN-ACKにFast Open Cookieオプションが付く点です。 通信の回数は三回と変わりません。 また、最初のSYNを受け取ったサーバがTFOに対応していない場合、サーバはオプションを無視して通常の3WHが実行(フォールバック)されます。 HTTPの通信は3WHが完全に終わった後になります。

ここでサーバが生成するTFO-Cookieは、クライアントのIPをベースにします。 クライアントはこのTFO-Cookieを、次回以降の接続で仕様するためにキャッシュします。

次回以降の接続

サーバとクライアントが有効なCookieをお互いに保持している状態です。

1. クライアントは、SYNパケットにキャッシュしたTFO-CookieとHTTP GETのリクエストデータを含めて送信する。
2. サーバは、TFO-Cookieを受け取る。この時初回接続で生成した方法と同じようにSYNからTFO-Cookieを生成し、受け取ったTFO-Cookieと比較する。同じであればTFO-Cookieは正しいものであり、同時にクライアントのIPは偽装されていないことがわかる。
3. TFO-Cookieが正しいことを確認したら、サーバはリクエストデータをアプリケーションレイヤに渡す。クライアントにはSYN-ACKを返すが、もしHTTPレスポンスデータが準備できていればSYN-ACKに載せることも可能。
4. アプリレイヤがHTTPレスポンスデータを生成し終えたら、サーバはそれをクライアントに送信する。
5. クライアントは、ACKを送信する。

通常の3WHと違うのは、SYNに初回接続でキャッシュしたTFO-CookieとHTTP GETのリクエストデータが付くことです。 サーバはTFO-Cookieを元に、クライアントがIPを偽装していないかを知ることができるので、正しいIPであればその後のクライアントからのACKがくる前にGETのデータをアプリのレイヤに渡してしまいます。 アプリから見れば一回の通信で、リクエストデータを取得したのと同等の状態になります。

また、TFOは3WHの省略と解説されることが多いですが、実際にはサーバは従来どおりSYN-ACKを返し、クライアントも最後のACKをきちんと送ります。 ただし、もしアプリが生成したレスポンスデータがサーバに届いたらSYN-ACKに載せて返すこともできますし、SYN-ACKを先に返しておいて別途送ることもできます。 最後のクライアントACKを待たずにレスポンスを開始できるのが、3WHを短縮するからくりになっているのです。

もし、サーバがTFOに対応していなかったりクライアントのTFO-Cookieが無効と判断された場合は、通常の3WHにフォールバックされ、通常のフローでHTTPのGETが行われます。

TFO-Cookie

TFO-CookieはクライアントのIPを保証できなければなりませんが、その生成アルゴリズムは仕様では定義されておらず、実装依存です。 参考までにLinux Kernel 3.11では、以下のようにクライアント/サーバ双方のIPアドレスを暗号化して生成しています。

http://lxr.linux.no/linux+v3.11/net/ipv4/tcp_fastopen.c#L67

IPアドレスを元に生成しているため、クライアントのIPが変わるとCookieが無効になることを意味します。

注意点

Intermedialies(中間サーバ問題)

こうしたネットワークプロトコルの改善には、必ずIntermedialies(middleboxともいう)と呼ばれる中間サーバが問題になります。 具体的にはプロトコルをいじることで、NATやFWなどが通信を不正と見なして遮断したり、内容を書き換えてしまう問題です。

TFOの場合は、NATでアドレスが書き換わる状況などではCookieが不正とみなされ、TFOが成功しない可能性が考えられます。 しかし、問題があれば通常の3WHへのフォールバックによって、通信を続行することができるよう設計されているため、この問題は最小限に抑えられています。

ただし、リクエストデータを付与したSYNが拒否され、3WH成立後に改めてリクエストを送信する場合は、リクエストデータが二重に送信されるためオーバーヘッドになる可能性があります。

導入方法

TFOはクライアントAPIがLinux kernel 3.6に、サーバAPIが3.7にマージされています。 執筆時点ではWindowsおよびMac OSでは使用することができません。

TFOを有効にするには、設定ファイルにフラグを立て、ソケットプログラムにおいて適切なシステムコールを呼ぶ必要があります。

サーバ

サーバでは、生成したソケットをバインドした後に、setsocketopt(2)を用いてTCP_FASTOPENオプションを付与する必要があります。 qlenの値は、TFOによって3WHが終了していないソケットのキューサイズです。

s = socket(AF_INET, SOCK_STREAM, 0);   // ソケットの生成

bind(s, ...);                          // アドレスへのバインド

int qlen = 5;
setsockopt(s, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)); // TCP_FASTOPEN オプションの設定

listen(s, ...);                        // ソケットのリッスン

クライアント

クライアントでは、生成したソケットに対するconnect(2)とsend(2)の代わりに、sendto(2)を使用してデータを送信します。 これは通常UDP通信などで使用されるシステムコールですが、TFOでは3WHが終了していない状態でのデータ送信が必要なため、これを用います。

このsendto(2)は、初回接続時はTFO-Cookie Requestを送信し、既にCookieがある場合はそれを使用してSYNにデータを載せて送信を行います。

// ソケットに対する connect(2) + write(2) の代わりに sendto(2) を使用
sendto(s, data, data_len, MSG_FASTOPEN,
    (struct sockaddr *) &server_addr, addr_len);

// 以降の送受信は通常どおり read(2)/write(2) を使用

設定

Linux KernelではTFOの設定ファイルとして /proc/sys/net/ipv4/tcp_fastopen が用意されています。 このファイルにはビットでクライアント/サーバごとに有効/無効の設定が可能です。 Linux Kernelでは以下の設定値が定義されています。

0x0: 無効 0x1: クライアントのみ有効 0x2: サーバのみ有効 0x3: クライアント/サーバともに有効 0x4: CookieがなくてもSYNでデータを送信 0x100: Cookie を検証せずにデータの載ったSYNを受け入れる 0x200: Cookie オプションがなくてもSYNにデータを載せる 0x400/0x800: TCP_FASTOPENオプションを設定してないソケットでもTFOを有効にする。

実装

簡単なTFOサーバとクライアントのスクリプトを作成して、パケットの流れを確認してみます。 現時点で言語レベルでTFOをサポートしているものは少ないため *1、Pythonで直接システムコールを呼ぶスクリプトを使用します。

python sample code (gist)

クライアントは “hello\n” を二回送信し、サーバはそれをエコーバックします。 二台のマシン(MacOS)上のVartual Box上のUbuntuで実行します。

# server
$ sudo python server.py # listen port 80
# client
$ python client.py 192.168.1.10 # server address

実行結果をWiresharkで確認します。

最初のClient SYNにFast Open Cookie Requestが付き、SYN ACKでFast Open Cookiが付与されていることがわかります。 データは別のパケットで送られています。

二回目のClient SYNには、このCookieとデータが一緒に載っています。 しかもサーバはSYN ACKを返した後に、サーバのACKを待たずにデータを返しています。 正常に動いていることがわかりますね。

ApacheとChrome

ApacheやNginxなどはまだTFOに対応していませんが、kernel側でリスニングソケットにTFOを強制するオプションがあるので、それを使用して検証します。 また、最新のChromeはTFOに対応しているため(OSもTFO対応が必要) 、これをクライアントとして利用します。

まず、サーバ側でTFO強制の設定をしApacheをインストールします。

$ echo 0x403 | sudo tee /proc/sys/net/ipv4/tcp_fastopen
$ sudo apt-get install apache2

クライアント側は最新のchromeを用意し chrome://flags で “TCP Fast Openを有効にする” を設定します。

この状態でChromeからapacheのデフォルトページに二回アクセスします。 Chromeは、一回目のGETでCookieをリクエストし、二回目のGETでSYNにCookieとリクエストヘッダを載せて投げています。

同様の方法を使えば、設定ファイルを書くだけで既存のサーバをTFOに対応させることができるでしょう。 しかし、このオプションはあくまでもテスト目的に使用するもので、本番運用ではkernel APIレベルで対応したものを使用するべきです。

ベンチマーク

TFOはRTTが大きい環境でこそ効果が期待されます。そこでAWSを用いて、Tokyoリージョンをクライアント、N.Virginiaリージョンをサーバとし、ベンチマークをとってみます。使用するAMIは以下です。(インスタンスにはElastic IPをふっています)

• TOKYO: ubuntu-raring-13.04-amd64-server-20130820(ami-0b8c1f0a)
• N.Virginia: ubuntu-raring-12.04-amd64-server-20130820(ami-77fcbc1e)

サーバにはApacheを、クライアントはTFOに対応しているHttpingを用いて十回のリクエストを投げる簡単なベンチを行います。

$ echo 3 | sudo tee /proc/sys/net/ipv4/tcp_fastopen
$ wget http://www.vanheusden.com/httping/httping-2.3.3.tgz
$ tar zxvf httping-2.3.3.tgz
$ cd httping-2.3.3.tgz
$ ./configure --with-tfo # TFO を有効にしてビルド
$ make
$ ./httping -g http://192.0.2.0/ -c 10    # TFO off
$ ./httping -g http://192.0.2.0/ -c 10 -F # TFO on

結果

# TFO off 10 connects, 10 ok, 0.00% failed, time 13830ms round-trip min/avg/max = 344.7/382.6/424.2 ms

10 connects, 10 ok, 0.00% failed, time 12052ms round-trip min/avg/max = 161.8/204.9/364.2 ms (TFO onのパターンは、最初の一回はCookie Requestです)

この検証では、RTTは平均で46%短くなっている事がわかります。

まとめ

TFOは、まだドラフトの段階で実装も限られていますが、仕様が固まればサーバやOSも対応が進むと考えられます。 各言語の標準ソケットモジュールレベルでの対応も少しずつ進んでいるため、今後は普通にネットワークプログラムを書けば自動的にTFO対応されるでしょう。

注意点として、通常の3WHにフォールバックした場合にリクエストデータが二重になる可能性がありますが、 一方で通信を「なるべく少なく」することによる効果は非常に大きいため、そことのトレードオフとなるでしょう。

普及にはまだ時間がかかるかもしれませんが、今のうちから自身のもつサービス検証をしてみてはいかがでしょうか。

検証環境

• Ubuntu 13.10
• kernel 3.11.0-13-generic
• Python 2.7.3
• Wireshark 1.10.2
• HTTPing 2.3.3
• Google Chrome 32(beta)

1. いくつかの言語は導入に関する議論やパッチを見つけたので載せておきます。 Ruby, Go, Python

Googleは、よく使われるJavaScriptのライブラリなどをGoogleのインフラを使って配布しています。 これを Google Hosted Library と呼びます。

この、Hosted Libraryの導入を単純に「自分で配布しない分が楽になるだけ」、くらいな感覚で使っている方も多いと思います。しかし、実はこれはみんなが使えば使うほど、得をする仕組みになっていることを見落としてはいないでしょうか？

今回はそんな、Google Hosted Libraryについて、その仕組となるCDNやキャッシュの技術などについて解説します。

よくある Web ページ

例えば自分が配信するindex.html内でjquery.2.0.3.min.jsとそれに依存したmy-client.jsを使う場合、3つとも自分のサーバから配信するとします。 index.htmlは以下のような感じになるでしょう。

<html>
  <title>my web</title>
  <script src="js/jquery-2.0.3.min.js"></script>
  <script src="js/my-client.js"></script>
  ...
</html>

これで全く問題なく動くはずです。

キャッシュ

ところでindex.htmlやmy-client.jsは、自分がアップデートすることで内容が新しくなる可能性がありますね。 しかし、jQueryはどうでしょう？jquery.2.0.3.min.jsの内容は通常一度生成されたら二度と変わりません。もしjQuery自体がアップデートされれば、付与されるバージョン番号が変わるので、バージョン番号を含んだファイルは将来の変更を意識する必要がありません。

将来変更がないのであれば、ブラウザへのキャッシュを検討することができます。 全く内容が同じファイルを何度も配信する必要はなく、一度配信したものをキャッシュさせ、次回以降再利用させれば、無駄なネットワークアクセスを減らすことができるからです。 重複したリクエストが減るのは、「なるべく少なく 」の原則ですね。

キャッシュの設定には、jquery.2.0.3.min.jsのレスポンスにキャッシュをコントロールするヘッダを加えてあげる必要があります。 キャッシュヘッダの設定は実はそれだけで一つの記事になるくらい細かいのですが、今回の目的ではざっくりと以下の設定が考えられます。

::
Cache-Control:public, max-age=2592000
Expires: Sun, 1 Jan 2014 11:11:11 GMT

Cache-ControlはHTTP/1.1のヘッダで、クライアントにコンテンツをキャッシュさせる時間を指定できます。この例では30日を指定しています。

ExpiresはHTTP/1.0のヘッダで、指定された日時までキャッシュさせる設定です。Cache-Control非対応のクライアントを想定し、両方が現時点から同じ日(例えば30日後)になるように設定することが多いです。

これで、一度取得したファイルを30日はキャッシュし、ファイルの取得が必要なくなります。

Google Hosted Library

さて、Google Hosted Libraryは、よく使われるJavaSriptの配信を代わりにやってくれるのですが、使い方は簡単。一覧ページ から欲しいライブラリとバージョンのリンクをコピーして貼るだけです。

先ほどのjQueryを置き換えると以下のようになります。

<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min.js"></script>
  <script src="js/my-client.js"></script>

まず効果として、ファイルはGoogleの強靭なファイルサーバから取得されるため、可用性やパフォーマンスの面で有利ですし、自分のサーバからはその分の負荷がごっそり減ることになります。

そして、キャッシュ用のヘッダもすでに設定されているため、悩む必要がありません。jQueryにはキャッシュに関わる、以下のようなヘッダがついていました。

::
Cache-Control:public, max-age=31536000
Expires:Mon, 08 Sep 2014 00:23:36 GMT
Last-Modified:Tue, 09 Jul 2013 11:31:25 GMT

これは、ファイルを1年間キャッシュするという設定です。 Last-Modeifiedは、「条件付きGet」という方法で使われるヘッダですが、今回は説明を割愛します。

では、自分で適切にキャッシュの設定ができて負荷も問題なければ、Hosted Libraryを使う必要はないのでしょうか？

同時接続数

ブラウザは、ファイルを取得する時にサーバとのTCPの接続を必要とします。 もし1つのTCP接続しかなかったら、同時に1つのファイルしか取得できず、他は待たされます。

これだと、画像やJSなどのファイルが多い場合、全て取得し終わるまでに時間がかかってしまいます。 そこで、ブラウザは種類にもよりますが大体同時に6つのTCP接続をサーバと作ります。つまり6個同時に取得できるので、全部取得するのにかかる時間も減らせます。

しかし、もっとたくさんの接続を作れば、もっと同時にダウンロードできそうですよね。実は6個という数字は、一つのドメインとの間の接続の数です。なので、ドメインが違えばもう6個追加で接続できるのです。

もしあなたのサイトがexampl.e.comというドメインだとしたら、ajax.googleapis.comは別のドメインなので、jQueryは別の6つから取得できることになります。　Hosted Libraryを使うだけで、JSをダウンロードに必要な接続は、自分のサーバの貴重な6接続とは別にできるのです。

ちなみに、同じexample.comでもサブドメインを切ればそれは別ドメインとみなされます。 つまりstatic.example.comというドメインを作って、js, css, pngなどはそこから配信することで、接続数を増やすという策はよく使われます。もちろん、自分で契約したCDNも別のドメインにすることが多いです。

では、ドメインとキャッシュ設定が適切に設計されていれば、Hosted Libraryを使う理由はないでしょうか？

CDN(Contents Delivery Network)

ところで、このGoogleのサーバはどこにあるのでしょう？ 具体的な場所は公開されていませんが、Google曰く「世界中にある」そうです。

この世界中に散らばったサーバをエッジサーバといいます。 そして、先ほどのURLにアクセスした場合、そのユーザから一番近いエッジサーバからファイルを取得してくれる仕組みになっています。この仕組みは、 CDN(Contents Delivery Network) といいます。

具体的には、サーバの名前解決時にDNSがなるべく近いサーバのIPに解決してくれています。 例えば、日本でapi.googleapis.comを解決すると173.194.72.95になりますが、USのバージニア州(AWS us-east 上)では173.194.76.95になります。

日本から二つのサーバにPINGを打ち、RTT(Round Trip Time)を比較してみましょう。

:bash:
$ ping 173.194.72.95 -c 10 (jp to jp)
rtt avg = 53.441

$ ping ping 173.194.76.95 -c 10 (jp to virginia)
rtt avg = 174.525

実に3倍近い差が出ていることが分かります。 つまり、世界中からアクセスがくるようなサービスの場合は、Hosted Libraryに変えるだけで、JSが地理的に近いエッジサーバから配信され、RTTを小さくできる可能性があるのです。「なるべく近く 」の原則ですね。

ちなみに、CDNという仕組み自体をサービスとして提供している会社もあります。 有名なのは 「Akamai Technologies」や「Limelight Networks」、あとAWSにも「Cloud Front」というサービスがあり、いずれもお金を払うとエッジサーバを貸りてCDNを構築できます。 ちゃんとやるとそれなりのお値段がする場合が多いですが、Googleはそれをタダで使わせてくれるんですね。

もし自分でCDN環境を持っていれば、index.htmlやmy-client.jsも配信できるので、同じ効果が他のファイルでも得られます。

では、自分でお金をかけてCDNを構築していたら、Hosted Libraryを使う理由はないでしょうか？

Google Hosted Libraryはみんなが使うほど得をする

最初にキャッシュの話をしましたが、ブラウザはキャッシュをURLごとに管理しています。 例えば、自分のページにアクセスしたユーザが、 同じURLのJSを別のサイトで取得しキャッシュしていた場合、そのキャッシュを自分のサイトでも利用することができます。

同様に自分のページでキャッシュしたJSも、他のページで再利用できます。同じURLのJSを一度どこかでキャッシュしていれば、キャッシュが切れるまでの間は、同じURL のJSを使っている全てのサイトで、そのキャッシュは使いまわすことができるのです。

自前のCDNでは、せいぜい自分の管理するサイト内でしか使いまわせません。 しかし、Hosted Libraryの場合は、みんなが同じURLを共有するため、多くのページがHosted Libraryを使えば使うほど、キャッシュヒットする可能性が高くなり、ダウンロードが必要なのはそのどれか最初にアクセスした1つのページだけで済みます。

本来自分のサイトで発生したはずのリクエストがそもそもなくなったり、自分のサイトで発生したリクエストを他でも活かせるので、非常に大きなメリットとなります。

他のHosted Library

例えばjQueryのページを見に行くとjQueryを配信しているCDNが他にもいくつか紹介されています。

http://jquery.com/download/

ここでは、hosted library以外にも、 code.jquery.comという公式のCDNと、Microsoft, CNDJSが紹介されています。細かい違いは、今回解説した知識を踏まえて、同ページか各リンク先を確認して下さい。

どれを選択するかは、サーバ自体の性能やエッジの数・場所などと合わせて、「みんなが使っている」というのもひとつの指標になることは、解説した通りです。

まとめ

Hosted Libraryは、ただリンクを張り替えるだけで、無料で導入できるので非常に手軽です。 メリットとして、以下があります。

• 高可用、高性能なファイルサーバが使える
• キャッシュの設定がされている
• ドメインが分かれる
• 場所に応じてRTTの小さいエッジが選ばれる
• 同じURLを使うページ間で、キャッシュが共有できる

仕組みを知っているからこそ、あえてそれらを使わず自分でCDNを用意したり、自分のサーバから直接配信するといったことも戦略として比較検討ができます。

今までなんとなく使っていた方は、その意味とメリットを少しでも理解して頂ければ幸いです。

画像は、サイズが大きい（大きくなりがちな）コンテンツの一つです。 最近は画像を使わないページはほとんどなく、むしろ使う量はどんどん増えているんじゃないでしょうか。また、HiDPI対応などでサイズも増えつつあるでしょう。 Googleの調査では、現在Web上のトラフィックの65%を画像が占めているそうです。Introで解説したように、パフォーマンスを考えるとファイルサイズは「なるべく小さく」が望ましいため、画像は通常圧縮された形式で使用されます。

WebPは、Googleが開発した圧縮形式で、従来の形式よりもファイルサイズを小さくすることを目的としています。今回はそんなWebPの概要と使い方、注意点を取り上げます。

画像圧縮とは？

ここで対象としているのはピクセル形式の画像で、ざっくり言うと「1pxごとにそこが何色なのか」という情報を持つ形式です。 例えば、Windowsのペイントなどで作れるBitmap(.bmp)という形式がなじみ深いでしょうか。

ところが、例えば以下の画像を見て下さい、同じ色が連続している場所があります。 そこで、「このピクセルは赤、このピクセルも赤…」と繰り返す情報を、「ここからここまで赤」と置き換えると、同じ情報を小さく表せるはずです。

このように、同じ情報を小さく表現する方法を圧縮といいます。これを画像に適用したのが画像圧縮です。 上の図の方法は逆の計算をすれば元の画像が完全に復元できるため、「可逆圧縮（lossless）」といいます。

また、写真などにはものすごく細かい色の変化もあり、なくなっても人間は気づかれない場合が多いので、こうしたデータを捨てることで圧縮率を上げる方法もとられます。代わりに、完全には元に戻せなくなるため、この方法は「非可逆圧縮」と呼ばれます。

この例は、あくまでもイメージで、実際には同じ情報を小さく表わす方法はいろいろとあり、それにより圧縮形式が異なります。 次によく使われる圧縮形式を見てみましょう。

圧縮形式

Webの世界では、現在以下の三つがよく使われています。

• JPEG: 写真など色数の多いものに有効。非可逆圧縮。
• GIF: 色数が少ないアイコンなどに有効、アニメーションが可能。可逆圧縮(*1)。
• PNG: アイコンなどに使われ、透過も可能。可逆圧縮。

現状はこれらの形式を場合に応じて使い分けているわけですが、Googleは多くの場合にこれらの形式よりも小さく圧縮でき、透過やアニメーションなどの機能もそろった新しい圧縮形式を開発しました。それが、WebPです。

*1: 非可逆も可能です。

WebP

読み方は、Weppy＝ウェッピーです。 ファイルの構造としては、同じくGoogleが持つVP8コーデックを用いたWebMという動画フォーマットをベースとしており、WebMの1フレームだけを切り出したものがWebPで、それをRIFFという軽量なコンテナに格納した形式になっています。

https://developers.google.com/speed/webp/

WebPは以下のような特徴があります。

• 可逆 / 非可逆圧縮が可能
• 透過 (アルファチャネル) が可能
• 写真の圧縮にも向いている
• アニメーションが可能
• カラープロファイル対応
• メタデータを持たせることができる

画像に求められる基本的な機能をひと通り備えており、一つのフォーマットで幅広い用途で利用できるように作られていることがわかります。 現在Googleのサービスでは、Gmail、Google Drive、Picasa、Play Magazines、Image Search、YouTube、Chrome Web Storeなどがサポートしており、Facebookもサポートを始めました。

ブラウザ対応

現在、以下のブラウザがWebPに対応*2しています。

• Chrome
• Opera (12.0~)
• Android Browser (4.2~)
• Chrome for Android

Firefoxでは議論中で、IEやSafariは対応していません。 こうしたクライアントを対象とする場合は、後ほど説明するフォールバックが必要になります。

*2: http://caniuse.com/webp

ツール

WebPは以下のような公式のライブラリ、オーサリングツールなどで生成することができます。

• WebP Library
• Pixelmator
• ImageMagick
• GIMP
• Leptonica
• XnConvert
• Photoshop Plugin
• img2webp.net

しかし、FacebookがWebPをサポートしたところ、ユーザから「画像をダウンロードしたら、編集ソフトで編集できなかった」というクレームがあったというニュースがありました。

これは、上記のようなメジャーなものを除いて、まだWebPに対応していないオーサリングツールが多くあることを意味しています。 また、OSのデフォルトのプレビューでは見れないため、Webから落とした後のことも考えるのであれば、代替手段として同じ画像のPNGやJPEGをダウンロードする手段を用意することが望ましいでしょう。

WebP Library

今回はWebP公式ライブラリに同梱されたCLIツールを用いて、実際に画像をWebPに変換してみます。 公式ライブラリは以下のページで公開されています。

Downloading and Installing WebP

ここには以下のツールと、開発用のライブラリが含まれます。

• cwebp: WebP への変換
• dwebp: WebP からの変換
• vwebp: WebP の表示
• webpmux: アニメーションの作成
• gif2webp: GIF から WebP への変換

これらのツールはかなりたくさんのオプションがあります。詳細はドキュメントを参照ください。

ここでは、使い方の解説を兼ねてPNG、JPEG、GIFとの簡単な比較をしてみます。(ライセンス情報は末尾に記載)

あくまで簡単な実験です、より厳密かつ詳細な比較結果は、こちらを参照ください。

可逆圧縮

可逆圧縮を、PNGファイルと比べてみます。 対象はPNGがよく使われるWebのUIアイコンとして、下記のPNGをもとにWebPに変換したものを比較します。

::
$ cwebp uikit.lossless.png -o uikit.lossless.webp -lossless

PNG	WebP
74 KB	62 KB

非可逆圧縮

非可逆圧縮をJEPGファイルと比べてみます。 対象はJPEGがよく使われる写真として、おなじみlennaさんのPNGをもとに、ImageMagickでJPEGに変換したものとWebPに変換したものを比較します。

::
$ cwebp lenna.lossless.png -o lenna.lossy.webp
$ convert lenna.lossless.png lenna.lossy.jpeg

JPEG	WebP
74 KB	20 KB

アニメーション

5つのJPEG画像をもとに、500msごとに切り替えるアニメーションをGIFとWebPで作って比較します。

::
$ webpmux -frame 1.webp +500+0+0+0 -frame 2.webp +500+0+0+0 -frame 3.webp +500+0+0+0 -frame 4.webp +500+0+0+0 -frame 5.webp +500+0+0+0 -o animation.webp
$ convert -delay 50 -loop 0 *.jpg animation.gif

GIF	WebP
262 KB	55 KB

残念ながら執筆時点では、WebPアニメーションを表示できるブラウザはないため、上記は表示されてないかもしれません。その場合はvwebpコマンドで表示できます。

::
$ vwebp animation.webp

GIFは色数が少ないため、写真を元にするとざらついた画質になりますが、WebPは比較して綺麗なアニメになっていることが分かると思います。

圧縮解凍の速度

WebPは圧縮率を上げるために、以下の追加コストがかかります。*4

• 圧縮: JPEG より 5~10 倍程度のコスト
• 解凍: JPEG より 1.3 倍程度のコスト

特に圧縮は大きな差に感じます。 しかし、画像は一般的に一度作られたら更新されることが少ないリソースであり、圧縮が必要なのは一回ですが、参照される機会が多いのが特徴です。 WebPは多少時間をかけて、じっくりと小さく圧縮することを選択しています。

CPU資源は、サーバ側はサービスの規模に応じて投資してコントロールできますし、クライアント側は最近はモバイル端末ですらそれなりの処理性能を持っています。 ネットワーク資源は、サーバとクライアント間で状況により変わり、サービス側の投資だけではコントロールしきれないという特徴があります。 したがって、圧縮/解凍にかかる時間よりも、ファイルを小さくすることを選択するほうが、現在のWebを取り巻く環境を考えると妥当な場合が多いと考えられます。

しかし、動的に画像を生成するようなサービスでは、従来のフォーマットと比べるなどの検証が必須になるでしょう。

*4 http://www.igvita.com/slides/2013/io-webp.pdf (P.13)

フォールバック

執筆時点では対応するブラウザは限られています。従ってWebP非対応のブラウザのためにはPNGなどへのフォールバックを検討する必要があります。 対応方法は主に以下があります。

• サーバ側で対応
  • Accept ヘッダでの判別
  • User-Agent ヘッダでの判別
• クライアント側対応
  • JavaScript でのフォールバック

Accept での判別

クライアント・サーバ間での対応フォーマットの確認は、通常HTTP1.1のコンテントネゴシエーションという機能を用いて行います。 具体的には、WebPに対応したブラウザは、画像のリクエストのAcceptヘッダにimage/webpを付与することが求められており、サーバはこの値をもとにクライアントの対応を知ることができます。

手元のChrome29では、HTML中のimgタグのリクエストに以下のヘッダが確認できました。

この方法は、クライアントとサーバの間にキャッシュサーバが入る場合に注意が必要です。 同じURLから取得できるコンテンツがクライアントによって異なるので、キャッシュが共有されることで問題が起こる可能性があるためです。 これを防ぐためには、キャッシュに「Acceptヘッダによって、配信するソースが違う」ということを教えるためにVaryヘッダを付与します。 (この情報はGoogleのBotなどがコンテンツ内容を把握する上でも重要です。)

::
Vary: Accept

コンテントネゴシエーションをサーバに設定する例は、webp-detectが参考になります。

User-Agentでの判別

Chrome29は先のように、imgタグに対してimage/webpを送っていましたが、直接画像のURLにアクセスした場合は送っていません。（Canaryでは全ての画像のリクエストに送ります） またWebPに対応していなくても、全てを許容する意味の */* を送信するブラウザもあり、Acceptヘッダだけで判別するのは難しい場合があります。

そして、せっかく画像サイズを減らしているのに、Acceptヘッダに新しい情報を追加してしまっては、クライアントからサーバへ送信する情報を増やします。その理由から全てのブラウザが、今後Acceptヘッダを対応をするかどうかはまだ分かりません。 *3

こうしたブラウザ場合は、対応をUser-Agentから判断することもできます。 対応するブラウザは、http://caniuse.com/webp から確認できますが、より細かくバージョンを指定したい場合は、 Google Page Speed のソースが参考になります。

*3 HTTP/2.0では、HPACKというヘッダの送受信を効率化する方式が採用される見通しであり、ヘッダへの情報追加によるオーバーヘッドは、HTTP/1.1に比べて減らせる可能性があります。

Nginx のサンプル

以下は、ここまでの判別方法を元に、Nginxでブラウザの対応に応じて切り替える例です。 対応している場合はlogo.webpを、非対応の場合はlogo.pngをレスポンスしています。

location = /logo {
    if ($http_accept ~* "webp") {
        add_header Vary Accept;
        rewrite (.*) $1.webp last;
    }
    if ($http_user_agent ~* "(Chrome|Opera|Android|Android.*Chrome)") {
        add_header Vary User-Agent;
        rewrite (.*) $1.webp last;
    }
    rewrite (.*) $1.png last;
}

実際に以下のリンクで動作を確認できます。（対応ブラウザはWebP、非対応はPNG画像が返ってきます）

https://jxck.io/labs/webp/logo

HTMLごと切り替える

logo.webpとlogo.pngのURLを明示的に分けたい場合は、それらを含むHTMLをまるごと切り替える方が良い場合もあります。

// 対応ブラウザ用
<html>
  <img src="/logo.webp">
</html>

// 非対応ブラウザ用
<html>
  <img src="/logo.png">
</html>

この場合も、User-Agentによって切り替え、Varyヘッダを付与するとよいでしょう。 もしくは、以下のヘッダを付与することでキャッシュの共有を限定してしまう方法もあります。

::
Cache-Control: private

ただしこの方法では、例えばWebPに対応したクライアントで取得したlogo.webpのURLをtwitterなどで共有した場合、 WebPに対応しないクライアントでそれを開くと中身を見ることはできません。こうした状況を想定するならUser-Agentも併用する必要があるでしょう。

JavaScriptでフォールバックする方法

まず、Modernizr.jsには、ブラウザのWebPサポートを調べる機能があります。 これを用いて、読み込む画像をJavaScriptで動的に切り替えることができます。

if (Modernizr.webp) {
  // WebP を読み込む
} else {
  // PNG を読み込む
}

また、WebPがWebMの1フレームに相当することを利用し、 videoタグでWebPを表示可能にする weppy.js というライブラリもあります。

これを用いると、WebMに対応したFireFoxでもWebPが表示できます。

<script src="weppy.js"></script>
<img src="mandelbrot.webp" width="500">

より強力なライブラリとして、WebPのデコードをJSでやってしまうwebp.jsというライブラリもあります。 こちらは、なんとIE6以降でほぼ全てのブラウザに対応しています。

<script type="text/javascript" src="js/webpjs-0.0.2.min.js"></script>

まとめ

画像を効率よく圧縮できれば帯域を節約でき、特にモバイル対応の場合は全体のパフォーマンスに大きく影響が出ます。 WebPはこの点を解消するために生まれ、圧縮率等に関しては一定の成果を出していると言えるでしょう。

しかし、まだ普及しきっていないため、フォールバックなど考慮すべき点もあります。特に、フォールバックのために施した対策のために、WebPで得られた以上のオーバーヘッドが生じては、パフォーマンスの観点からは台無しです。（全てWebP対応を考えた上での暫定策であれば別ですが）

また、圧縮効果が高いかどうか、不可逆でも画質を維持できるかどうかは、全てどういう画像をどういう用途で配布するかにかかります。パフォーマンスの向上も、今回解説したことを踏まえて、「推測するな測定せよ」を忘れずに実施してください。

Version

• libwebp 0.3.1
• ImageMagick 6.8.6-3
• Mac OSX 10.7.5

Photo License

• Lenna: http://www.cs.cmu.edu/~chuck/lennapg/lena_std.tif
• Smooth UI Kit: Creative Commons Attribution 3.0
• Photo Credit: Luz Adriana Villa A. via Compfight cc
• Photo Credit: pedrosimoes7 via Compfight cc
• Photo Credit: kevin dooley via Compfight cc
• Photo Credit: kevin dooley via Compfight cc
• Photo Credit: VinothChandar via Compfight cc
• Photo Credit: See-ming Lee 李思明 SML via Compfight cc

今回から数回にわたって、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.

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

そして、連載初回の今日は、これら “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” にとって大きな貢献になります。