この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
第1回のアジェンダ編では、高速化に関わる要因と解決策の全体像を紹介しました。
アジェンダ編にもかかわらず多くのブックマーク、シェアをいただきありがとうございます！
余談ですが、記事にブックマーク、シェアをしていただくと、このブログでは執筆者に経験値がたまるような仕組みになっています。
たくさん経験値を貯めると四半期ごとに良いことがあるかもしれないので、気が向いたらこの他の執筆者の記事もシェアしていただけるとうれしいです。
言葉にせずとも、わかっていただけると思いますが、この記事も・・・ね？ 右上にあるボタンをちょちょっと。
本題
余談はさておき、本題に入りましょう。
今回は「無駄なリクエストとレスポンスの削減」に視点を置き、解決策について調査、計測して紹介してみたいと思います。
と思ったのですが、長くなりすぎたため、まずは「検証ツールとHTTPについて」紹介することにしました。
この記事の執筆を行っている段階で調べたことも多々あります。
多くの方の記事などを参考にさせていただきました。これらの点について自身の勉強のために書いた記事ですので予めご了承ください。
筆者の知らない情報や勘違いがあれば川○シェフ並のどや顔でコメントしていただけると泣きはしませんが大変感謝いたします。
目次
- 検証用ツールについて
- 高速化度合いの確認ツールについて
- HTTPリクエストとレスポンスとは
- ブラウザごとの同時接続数（HTTP1.1）
- 主要なHTTPステータスコード（HTTP1.1）
1, 検証用ツールについて
HTTPのリクエストとレスポンスを検証できるツールは色々あります。
今回はGoogle Chromeで「Web Developer Tools」、Firefoxで「Firebug」、Internet Explorerで「開発者ツール」を利用します。
もっと詳しく確認できるツールはあるらしいですが、使いこなせる知識がないので、もっと勉強してから紹介したいと思います。
1.1 ツールの起動方法
細かな操作方法は追って説明していきますが、開き方だけ紹介します。
Web Developer Tools
Google Chrome Web Developer Tools：F12キー
Firefox(Firebug)
Firefox Firebug：拡張機能のFirebugをインストール後 F12キー
IE開発者ツール
Internet Explorer 開発者ツール：F12キー
参考：
それぞれのツールについては、以下の参考サイトもどうぞ。
- Google ChromeのWeb Developer Toolsはこちらの解説「Google Chrome Developer Tools入門 in DevFestX Sapporo」がわかりやすそうです。
- Firebugはこちらの解説「意外と知られていない機能が多い！？Firebugの使い方」がかなりはてブされているようです。
- Internet Explorerの開発者ツールは本家の解説「F12 開発者ツールで Web ページをデバッグする方法」があります。
1.2 紹介してもらったツール（追記）
紹介してもらったツールを追記していきます。
Speed Tracer (by Google)
Speed Tracer (by Google): Google Chrome拡張機能
tilfin(Tosshi Note)さんが教えてくれました
参考サイト：[所感][ツール]ウェブページ表示速度計測ツール「Speed Tracer」Google Chromeエクステンション
2, 高速化度合いの確認ツールについて
現在運用中のサイトがどれぐらい高速化できていないか確認してみたい時や、対策をしてみた効果をチェックしたい時に便利なツールです。
2.1 GTmetrix
全体の高速化最適化度合いを計測するには「GTmetrix」が便利です。
GTmetrixは29の項目について即座に検証してくれる便利なツールです。
試しにこの開発ブログを計測してみました。
まあまあな点数ですね。
結果のSummary部分が評価指数になります。参考程度にいくつかのサイトを調べてみました。
| サイト | Page Speed Grade | YSlow Grade |
|---|---|---|
| facebook https://www.facebook.com/ |
A(99%) | A(97%) |
| twitter https://twitter.com/ |
A(97%) | A(97%) |
| Yahoo http://yahoo.co.jp/ |
B(86%) | B(85%) |
| Amazon http://amazon.co.jp/ |
A(94%) | B(83%) |
| クックパッド http://cookpad.com/ |
B(83%) | C(70%) |
| 楽天 http://www.rakuten.co.jp/ |
D(68%) | D(61%) |
| ZOZOTOWN http://zozo.jp/ |
D(66%) | E(59%) |
| クラスメソッド株式会社 https://classmethod.jp/ |
B(83%) | A(90%) |
参考にトップ1,000もどうぞ。
2.2 その他のツール
「GTmetrix」以外にも以下のようなサービスがあります。
PageSpeed Insights
GTmetrixと見ているものは基本同じですが個別に計測できます。
YSlow
Google ChromeやFirefox、Opera、Safariにインストールして利用することができます。こちらもGTmetrixでも利用できます。
Google Analytics
Google Analyticsでもサイト表示速度が計測できるようになりました。以前はWeb Master Toolsで計測できましたが、Google Analyticsの方が便利そうです。
3, HTTPリクエストとレスポンスとは
HTTPとは
HTTPとはTCP（Transmission Control Protocol）を利用したパケット型のやりとりで、基本的に1つのリクエストに対し、1つのレスポンスを返します。
そのデータには大きく別けて３つの情報に別けられるようです。構造としてはシンプルですね。
- 「リクエスト/レスポンス行」どのようにデータを取得するかのメソッド・URL・HTTPのバージョンが入る
- 「ヘッダー」制御系の情報を持つ
- 「ボディ」実際のコンテンツである
UDP（追記）
TCP意外にもUDP（User Datagram Protocol）というプロトコルがあるそうです。
UDPはTCPとは違い、信頼性を保証したプロトコルではなく、レイテンシの低減を重視したプロトコルである。
レイテンシとは（追記）
レイテンシとは、リクエストからその結果が返されるまでの遅延時間のこと。
3.1 リクエスト/レスポンス行とは
リクエスト/レスポンス行では、それぞれ項目が異なります。
リクエスト行では「メソッド名」「パス名」「HTTP/バージョン」となります。
GET /web_acceleration_sample/images/requests/load_sample_image_04.png HTTP/1.1項目ごとに分解してみます。
| メソッド | URI | プロトコル |
|---|---|---|
| GET | /web_acceleration_sample/images/requests/load_sample_image_04.png | HTTP/1.1 |
レスポンス行では「HTTP/バージョン」「ステータスコード」「メッセージ」という項目が送られてきます。
HTTP/1.1 200 OKこちらも項目ごとに分解してみます。
| プロトコル | ステータスコード | メッセージ |
|---|---|---|
| HTTP/1.1 | 200 | OK |
3.2 HTTPヘッダーとは
HTTPヘッダーはリクエスト時、レスポンス時どちらにも存在します。
リクエストヘッダ
リクエストヘッダーはブラウザ側が作り、サーバー側へ送ります。
以下がそのサンプルです（主なHTTPヘッダについては後述します）。
Host: nonakaryuichi.github.com
Connection: keep-alive
Cache-Control: max-age=0
If-Modified-Since: Sun, 13 Jan 2013 15:49:45 GMT
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17
Accept: */*
Referer: http://nonakaryuichi.github.com/web_acceleration_sample/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Accept-Charset: UTF-8,*;q=0.5
Cookie: logged_in=yesレスポンスヘッダー
レスポンスヘッダーはHTTPリクエストを受け取ったサーバー側が返すHTTPリクエストのHTTPヘッダーのことです。
Server: GitHub.com
Date: Thu, 17 Jan 2013 12:37:45 GMT
Content-Type: image/png
Content-Length: 1312
Last-Modified: Sun, 13 Jan 2013 15:49:45 GMT
Connection: keep-alive
Expires: Fri, 18 Jan 2013 12:37:45 GMT
Cache-Control: max-age=86400
Accept-Ranges: none3.3 HTTPボディとは
この部分が実際に送受信するデータの本体となる部分です。
リクエストの際に利用する場合は主にPOSTメソッドなどでデータを送る際に利用し、レスポンスの際はHTMLなどが入ります。
3.4 HTTP1.0と1.1の違い
今ではほとんどのサイトがHTTP1.1を利用しているようです。
簡単に図を作ってみました。
HTTP1.1の特徴
HTTP1.1では、1つのIPアドレスでホストごとに返すコンテンツを制御できるバーチャルホストとKeep-Aliveという持続的接続が可能になりました。
この持続的接続とは、リクエストの都度TCP接続を確立・解放を繰り返し行わなければならなかったHTTP1.0と違い、1度のTCP接続の確立で、HTTPリクエストとレスポンスを繰り返し行えるようになったことです。
参考：
3.5 主なHTTPヘッダー項目
| 項目名 | リクエスト/レスポンス | 説明 |
|---|---|---|
| Accept | リクエスト | 受信可能なデータ形式をサーバーに通知します。 |
| Cache-Control | リクエスト/レスポンス | キャッシュに関する指示をサーバーに通知します。 |
| Connection | リクエスト/レスポンス | 持続的接続（Keep-Alive）のサポート状態をサーバーに通知します。 |
| Accept-Encoding | リクエスト | ブラウザが受信可能なエンコード方式（gzip）をサーバーに通知します。 |
| Content-Encoding | リクエスト/レスポンス | コンテンツのエンコード方式（gzip）をサーバーに通知します。 |
| Content-Type | リクエスト/レスポンス | MIMEタイプを通知します。 |
| Date | リクエスト/レスポンス | 応答を返す時刻を通知します。 |
| Expires | リクエスト/レスポンス | ロードしたコンポーネント（画像やCSS,JavaScriptなど）のキャッシュ期限を通知します。 |
| Host | リクエスト | HTTP1.1で必須とされている項目です。サーバーに対して要求しているホスト名を通知します。 |
| If-Modified-Since | リクエスト | クライアント側にキャッシュがある場合、新しいものがあれば転送するようサーバー側に要求します。新しいものがなければ304のステータスコードを返し、引き続きクライアント側のキャッシュを利用します。 |
| Etags | レスポンス | キャッシュされているコンポーネントがWebサーバー上のオリジナルと一致しているかは検証します。 |
| Last-Modified | リクエスト/レスポンス | コンポーネントが最後に更新された時刻を通知します。 |
| Referer | リクエスト | 要求元になったページのURLをサーバー側に通知します。 |
| User-Agent | リクエスト | ブラウザのユーザーエージェントをサーバーに通知します。 |
| Warning | リクエスト/レスポンス | ワーニングとメッセージを通知します。 |
参考：
3.6 主要なHTTPステータスコード（HTTP1.1）
HTTPステータスコードは、ファイルのキャッシュを確認するのに必要なので主要なステータスコードを覚えておきましょう。
特に、「200」か「304」かでロードしているかキャッシュしているかわかります。
| コード | ステータス |
|---|---|
| 200 | リクエストが成功し、要求したドキュメントが返ってきたとき。 |
| 304 | ドキュメントが更新されていれば新しいドキュメントを返すようリクエストしたが、更新されていない場合に返ってくるステータスコード。 |
| 403 | アクセス権がないときなど、実行を拒否したとき。 |
| 404 | 要求したURIに一致するリソースが見つからなかったとき。 |
| 500 | サーバー内でのエラーにより処理できないとき。 |
| 503 | サーバーの過負荷かメンテナンスで処理できないとき。 |
参考：
より詳しく知るにはここちら「HTTPステータスコード」が参考になります。
3.7 主要なメHTTPメソッド
| メソッド | 説明 |
|---|---|
| GET | サーバーに対してHTMLや画像のリソースを要求します。広く一般的に利用されているメソッドでWebサイトを閲覧する際のほとんどにこのメソッドを利用しています。 |
| HEAD | ボディなしのヘッダのみを要求するメソッドです。 |
| POST | PHPやRubyなどサーバー側に情報を提供して処理を変えたい時などに利用します。具体的な例としてはお問い合わせフォームがあります。 |
他のメソッドも知りたい方はこちらを参考にどうぞ。
HTTPメソッド
3.8 SPDYからHTTP2.0へ（未来のお話）
SPDYとHTTP2.0は最近見かけるようになった次世代の接続方式のようです。
すぐにという話ではありませんが、目が離せないですね。
@Jxck_ さん「HTTP はもともとドキュメントを操作するためのプロトコルだった。」ドキュメント = 始めと終わりが決まっているテキスト。でも最近は Facebook や Twitter のストリームのようにドキュメントでないものを操作するようになったし、Lingr や LINE のように HTTP で(ユーザー体験的には) ステートフルなチャットも行うようになったし、ネイティブアプリのように内部に多数の状態をもったアプリケーションを JavaScript で動かすようになったし･･･と、10年前には「Webではなかったもの」を Web の上で動かすようになり、こうして Web == インターネットになった。
引用元：Webはインターネットになった
参考：
上記のページも非常に参考になりますがこちら「次世代HTTP 2.0はSPDYの取り組みがベースに」もどうぞ。
4, ブラウザごとの同時接続数（HTTP1.1）
同時接続数とは、ブラウザがサーバーにリクエストを送った際に、同時に受け取れるデータの最大接続数を表します。
しかし、この同時接続数の制限は接続ホストごとに設けられています。
本来、HTTPの同時接続数は「2」が推薦されていますが、最近のブラウザは「6」としているようです。
| IE6 | IE7 | IE8 | IE9 | Firefox | Chrome | Safari |
|---|---|---|---|---|---|---|
| 2 | 2 | 6 | 6 | 6 | 6 | 6 |
4.1 IE6,7のHTTPリクエスト同時接続数
車道で例えてみました。
1台がゴール地点に着くまで次の車はスタートできません。
IE6,7は2本しかないので、それほど多くの車をゴールに移動させることができません。
4.2 IE8,9, Firefox, Chrome, Safariの同時接続数
IE8,9, Firefox, Chrome, Safariは同時接続数が6なのでIE6,7に比べ3倍のリクエストを処理できます。
シャ○・アズナブルの3倍とは違い、物量による3倍ですね。
4.3 Google Chrome Web Developer Toolsでチェックしてみる
IE, Firefoxについても調査しましたが、ここでは「Google ChromeのWeb Developer Tools」を使った簡易的なチェック方法を紹介します。
Web Developer Toolsを開く
検証したいWebサイトを開き、F12キーでWeb Developer Toolsを開きます。
タブメニューの「Network」を選択し、F5でブラウザをリロードします。
同時接続数を確認
平行して処理されている部分を探してみます。
Timeの部分をクリックすると、ソートできるので「End Time」を選択するとわかりやすいかもしれません。
同時に処理されている項目を見ると、同時接続数は「6」のようですね。
同時接続数はクライアント側で変更が可能ですがサーバーの負荷に繋がるため意図的に増やすことは推薦されていません。
別の回で紹介する予定ですが、「mod_limitipconn」を使いサーバー側で制限することができるようです。
参考：
同時接続数に関する解説はこちら「HTTP/1.1 の同時接続数について」により詳しく解説されています。
4.4 ホストを複数にし分散すると本当に早いのか
サンプルを作って検証してみました。
ファイルはgithub、Amazon S3、Amazon CloudFrontにアップロードしています。
同時接続数を確認するためのサンプル：HTTP Requests Sample
結果
ぶっちゃけ早いんだろうけどロード時間を細かく見ないと分散の効果がちゃんと出ているのか自分の中でもまだ腑に落ちていません・・・
良いチェック方法があれば教えて頂けるとうれしいです。
それよりCloudFront早い。
CDNについては別途紹介する予定です。
まとめ
色々と調べてみて重要そうだな、という部分をまとめてみました。
もっと詳しく勉強したい方は所々紹介している参考サイトを読んでみてください。
参考にさせて頂いた記事を書いていただいた方々にあらためて感謝です。
次回こそ「無駄なリクエストとレスポンスの削減」の具体的な方法について紹介したいと思います。
2
