大きな画像の場合、画像をあえて切って表示させる場合があると思います。かなり古くからある手法でISDNなどナロー回線時代によく使われた技法になります。

とある案件でサイズの大きな画像はスライスさせるというルールを徹底されました。最近はファイルサイズよりもリクエスト減らしたほうが早いと考えていたので「これって本当に意味あるの？」と、思い検証してみました。

結論としてはナローバンドには効果があると思います
(しかし読み込み完了は遅くなる)

ナローバンド、いわゆる低速帯の人には効果があります。その代わり通信速度が上昇した現代っ子達にとっては逆に遅くなる結果に。

実はナローバンドもページの読み込み完了は伸びてしまっているはずです。一言で言うとリクエスト回数がボトルネックに。
※スマホは挙動が違い、適度なスライスの方が早いかも。PCブラウザより優秀でしたiPhone(safari)

各種スライスページの速度表

利用した画像：
全て同じ画像を利用。jpeg(最高画質)で書き出しています。
基本サイズ：width = 535px / height = 800px / 535kb
画像タグに幅と高さを記述。
※幅と高さを記述しないとレンダリングが遅くなります。

通信環境：
家庭用回線 wifi接続 23.405Mbps

ブラウザ：
Chrome35.0.1916.114

検証ページ：
①スライス無しのページ
②縦に3分割したページ(画像3枚)
③横10×縦15の150分割(画像150枚)
④横30×縦60の1800分割(画像1800枚 笑)

3回読み込んでの平均を出しています。サンプルページのURLも紹介。ただ横30×縦60はブラウザとサーバーが落ちる可能性もあるので結果だけ・・・。

300kb程度の画像ではスライスしても表示速度は変わらない

C,Dは大げさなのでA,Bを見てみます。わかりやすい特徴として画像のファイルサイズが大きくなります。
速度は10ms遅くなっていますがこれは誤差でたまたま遅いだけでしょう。画像のリクエストには平均30msでBは3回飛ばしていますが通信速度のおかげでページ表示に差は出ませんでした。

高速回線
Bはリクエスト回数が増える分無駄な処理(スライスする手間も含め)をしています。当然ながら表示速度を体感できる変化は感じらせません。

低速回線
ISDN以下の速度であればBを利用することで画像がちらっと見えて早く感じるかもしれません。
※個人的にインターレースでいいんじゃとも思う。

検証で感じたのはファイルサイズよりリクエスト回数が増えるほど遅くなる

スライスでパーツの一つ一つは軽くなりますが、それに伴うリクエスト回数の方が速度の足を引っ張っている印象です。

利用している回線速度以下の画像サイズであれば大きかろうが小さかろうがリクエスト1回30ms以上かかっています(僕の使っているサーバー)。
ナローバンド向けにサイト作るわけでないのであれば画像は分けない方が良いのではないでしょうか。

おまけ軽量サイズのPNGを1800枚並べてみた

リクエスト回数の負荷の検証のためにPNG(8bit 2色)の小さな画像を1800個並べてみました。

軽量サイズということ、そしてwidthとheightの指定有り無しということに注目。

A：上記のjpegと比べてみて下さい
「D:横30×縦60の1800分割」と比べるとファイルサイズは1/10以下です。163kbしかないのに40秒近くかかっています。
ファイル容量よりリクエスト回数が増えることでページ表示が遅くなるということではないでしょうか。

B：widthとheightの有り無しについて
結構大きく差がでました。imgタグに画像のサイズを記述していないと15秒も遅くなる結果に。
もうひとつの特徴として画像の大きさがわからないためスタイル崩れを起こします。だんだんメイン領域が広がっていくのがお分かりかと。
ECサイトなんかでは結構画像のサイズを記述していない場合を見かけます。ECこそ画像をふんだんに使っているので記述するべきですね。

おわり

1800枚はかなり大げさですね。単純にHTMLタグのdivを1800個置いただけでも遅くなりますし。しかし検証Cの150枚程度ならあり得るサイトはあるのでは。楽天とか。あと楽天とか。
今回でわかったのは「画像サイズが小さくても数を沢山置くとレンダリングが遅くなる」です。

今度は「Webデザイナーでもできるサイト速度を1%でも上げる方法」に挑戦しようと思います。