これは、HTML5 Advent Calendar 2014の7日目のエントリーとして書いております。
2008年4月1日に初版が発行された、オライリー・ジャパンの「ハイパフォーマンスWebサイト」を未だに参考にされている方は多いと思います。
ウェブページ内で、背景やボタン、ナビゲーションバー、リンクなどで多数の画像を使う場合は、CSSスプライトを使うのがエレガントな解決策です。そうすることで、マークアップが整理され、扱うべき画像の数も減り、レスポンスも高速になります。
― 「ハイパフォーマンスWebサイト 高速サイトを実現する14のルール」 Steve Souders著
その部分を参照されてか、時折、「CSSスプライトを使うことで、HTTPリクエスト数が削減されて、高速化に繋がる」と書かれている方をお見受けします。
しかし、それは本当なのでしょうか?
そこで、今回、本当に効果があるのかどうかを確認すべく、モバイルファーストの時代でもありますから、スマートフォンサイトを想定して、3G回線と光回線を使って実験してみました。
実験計画
- サーバ … Amazon Web Services S3
- 計測間隔 … 60分に1回の頻度。ランダムに間隔は前後する
- 回線 … ソフトバンクとNTTドコモの3G回線(都内、常に電波強度が3以上の場所)、並びに、光回線
- ブラウザ … iPhone4SのSafari
- 計測する対象 … HTMLが1ページ、そして約2MB分の画像。
実験計画法
品質管理で重要なデータの取り方である、実験計画法には、3つの原則があります。
- 局所管理化
- 反復
- ランダム化
局所管理化
局所管理化とは、実験で因果関係を確認したい要素以外の変数は固定化することです。
今回、計測の対象となるWebサーバには、堅牢さで定評のあるAWSのS3を使い、サーバの負荷要因を極力排除しました。
回線については、ソフトバンクとNTTドコモ、それぞれの3G回線を使用しており、性格の異なる回線での比較も試みています。また、光回線も使った計測もして、こちらでも比較しています。これは、無線LAN相当と考えて下さい。何故、実際の無線LANを使わないかというと、無線LANの場合は、電波干渉や様々な要因で接続が不安定になる可能性があるためで、これを排除するために光回線を使用しています。
ブラウザについては、iPhone4SのSafari相当を使用しています。相当と書いているのは、エミュレータを使っているためです。何故、実機ではなくエミュレータを使うかというと、スマートフォン本体のハードウェアスペックの影響を極力排除するためです。
反復
反復とは、計測を何度も一定間隔で行うことです。品質管理は、統計学をベースにして行うものです。残念ながら、統計学にはサンプリングで調査する都合上、「100%」という正解がありません。
従って、統計学においては、「ある母集団から無作為抽出された標本平均はサンプルのサイズを大きくすると真の平均に近づく」という大数の法則に基づいて、計測数が重要になります。
ランダム化(無作為化)
ランダム化とは、局所管理化や反復でも制御できない可能性のある要因の影響を除いて、データの偏りを小さくするために行います。今回の計測では、9:00、10:00、11:00という、きっかり1時間の間隔で計測するのではなく、8:53、10:10、11:07のような、凡そ1時間の間隔でランダムに計測することで、計測値に関与してくるであろう他の変数要因の影響を取り除きます。
計測結果
散布図
まず、ソフトバンクとNTTドコモの3G回線での計測の散布図を見てみます。
期間は、2014年11月23日～12月7日の二週間です。
- パターン1 … 水色: HTML1ページ+画像(2MB)1枚の計測です。
- パターン2 … オレンジ色: HTML1ページ+画像4枚(合計で2MB)の計測です。
- パターン3 … 青色: HTML1ページ+画像13枚(合計で2MB)の計測です。
ソフトバンクでTimeoutエラー多発
▲のマークはエラーを表わしています。120秒付近でエラーが多発していますが、これはTimeoutエラーで、この計測では120秒以上かかったものは、エラーとして処理しているのです。
この120秒のTimeoutエラーは、全てソフトバンクです。
この背景には、ソフトバンクの携帯網においては「通信の最適化」が行われて、画像や動画ファイルに非可逆圧縮がかけられることが関係していると予想されます。
(※参考記事 ― 「ソフトバンクの『通信速度1位』のカラクリが明らかに」)
Timeoutエラーが発生しているのは、21:00～1:00の携帯網が最もアクセスされる時間帯です。他の時間帯では、NTTドコモに比べて、ソフトバンクは非常に高速です。
パターン1の計測だけを抜き出した散布図を見てみましょう。そうすると、きれいな三層構造になっているのがわかります。
普段は、ソフトバンクが圧倒的な速さを誇っているのですが、夜の混雑した時間帯になると、Timeoutエラーが発生しています。そこから、アクセス数の増大に伴う圧縮処理の負荷増大が足を引っ張っているであろう事が推測できます。
パターン2の計測だけを抜き出した散布図は以下の通りです。
パターン3の計測だけ抜き出した散布図は以下の通りです。
光回線では、全く違いが見られず
次は、光回線での計測の散布図です。計測値は、どの組み合わせでも、殆ど1秒以下です。
こちらでも、▲のマークが二つ程見えます。
AWSのS3であっても、時にはこのような遅延が発生していますが、二週間で2回だけですから、外れ値と言って良いでしょう。
分布図で配信速度品質の差を見る
それでは、パターン1から3で、配信速度品質に差が発生しているかどうかを見ましょう。
分布図を作って見ます。横軸がダウンロードにかかった秒数、縦軸がその秒数で計測された回数を表します。
- パターン1 … 緑色: HTML1ページ+画像(2MB)1枚の計測です。
- パターン2 … オレンジ色: HTML1ページ+画像4枚(合計で2MB)の計測です。
- パターン3 … ピンク色: HTML1ページ+画像13枚(合計で2MB)の計測です。
すると、分布図の山がほぼ同じ形で重なりあっており、違いが殆ど無いことが分かります。
Rを使った統計量の要約
グラフではなく、数値で見るために、Rを使って、統計量の要約をしてみたのが下の表です。
| 平均 | 標準偏差 | 四分位範囲 | 0% | 25% | 50% | 75% | 100% | サンプルの大きさ | |
|---|---|---|---|---|---|---|---|---|---|
| パターン 1-NTTドコモ | 20.595775 | 11.394125 | 12.96775 | 4.797 | 12.50875 | 16.9370 | 25.47650 | 71.422 | 182 |
| パターン 1-ソフトバンク | 4.839278 | 10.013305 | 2.33175 | 1.406 | 2.63275 | 3.3120 | 4.96450 | 112.078 | 158 |
| パターン 2-NTTドコモ | 20.517301 | 12.712250 | 10.29250 | 7.641 | 13.14500 | 16.5390 | 23.43750 | 97.313 | 176 |
| パターン 2-ソフトバンク | 4.907903 | 11.820907 | 2.30375 | 1.500 | 2.37600 | 2.9455 | 4.67975 | 103.484 | 144 |
| パターン 3-NTTドコモ | 21.890113 | 10.937367 | 12.45400 | 5.985 | 13.88900 | 19.7180 | 26.34300 | 63.954 | 177 |
| パターン 3-ソフトバンク | 5.309378 | 9.273377 | 2.41250 | 1.718 | 2.34400 | 2.9220 | 4.75650 | 51.469 | 143 |
数値に惑わされないように、箱ひげ図で再びグラフにしてみる
これを分かりやすいように、箱ひげ図にしてみます。
縦軸がテストパターン、横軸がダウンロードの秒数を表わしています。
左側の「ひげ」が、全体の計測値の内、速さで0～25%の分布を示しています。
箱の左側が、全体の計測値の内、速さで25～50%の分布を示しています。
箱の右側が、全体の計測値の内、速さで50～75%の分布を示しています。
右側の「ひげ」が、全体の計測値の内、速さ順に並べた計測値の75～100%の分布を示しています。
箱を区切る線が、中央値、つまり50パーセンタイルを示します。
この「ひげ」や「箱」の長さを見ることで、バラつきを把握することができるのです。
長さが短ければ短い程に、配信品質にバラつきがないという事になります。
余談ですが、今の高校生は、学習要項が変わって、高校1年の数Iで統計学を勉強して、箱ひげ図の見方も勉強してきますので、皆さんも知っておいた方が良いですよ。国としても、統計学の教育はそれだけ重要視しています。
携帯網の特性と右側の「ひげ」の関係
これを見ると全てのテストパターンで、右側の「ひげ」つまり、全体の中の遅い25%(速さ順に並べた計測値の75～100%)の分布が伸びています。
モバイルサイトのパフォーマンス計測の分析では、この「ひげ」より前の部分、つまり、左側の「ひげ」と二つに区切られた「箱」を見ます。何故かというと、携帯網の仕組み上、夜の混雑する時間は、必ず遅延が発生します。
デスクトップサイト(有線回線)とモバイルサイト(携帯網や無線LAN)の一番の違いは、有線は増設が可能なのに対して、無線は増設が不可能な点です。有線は、どんどん回線を増設すれば良いのですが、無線は電波の周波数という「有限」な資源を様々な用途別に区切って使っているため、増設は出来ません。
ですから、無線の場合は、その基地局がカバーする半径を短くすることで、1基地局あたりがカバーする人数を相対的に減らして通信容量を減らしてパフォーマンスを上げることになります。
ケータイWatch「ソフトバンク孫氏が“世界最強”の通信網アピール」より
しかし、夜の21:00～1:00は、多くの人がスマートフォンで接続するため、このようにカバーエリアを小さくして接続人数を相対的に少なくしても、基地局のキャパシティを超える人数が接続してきて、どうしても遅延してしまうのです。
言い換えれば、遅い75パーセンタイル以降は、我々としてはあまり出来ることがない部分なのです。
またソフトバンクに関して言えば、圧縮のシステムの過負荷によって、75パーセンタイル以降が伸びているわけなので、これもまた、我々には手出しができません。
どうしても、この部分を改善したいのであれば、画像を減らしましょう。
今回はデータを掲載しませんが、ページの総容量を100KB以下にすれば、混雑している時間帯でも、高速に配信できることがわかっています。
結論
ちょっと他の説明も書いて回り道をしてしまいましたが、結論から言うと、画像を一枚にしても、分割しても、パフォーマンスには差がほぼありません。
箱ひげ図を見て頂ければ、後ろの25%の「ひげ」以外は殆ど差がないことが分かります。これをミリセカンドレベルで見れば、確かに差はあると思いますが、そのレベルでのパフォーマンスを求めるのであれば、画像を1枚、2枚と、減らした方が効果が高いと思います。
CSSスプライトに手間をかけるよりは、画像の中でテキスト+CSSで置き換えられるものは置き換える作業をした方が、パフォーマンス的には「効く」と考えます。
