読者です 読者をやめる 読者になる 読者になる

アトラシエの開発ブログ

株式会社アトラシエのブログです

responsiveなサイトの画像サイズ問題は無理やり頑張るより妥協したほうが良さそう

ミライエは工数の問題やSEOの観点からレスポンシブレイアウトを採用しています。

miraie.me

レスポンシブレイアウトがSEO上良いという点はこちらを御覧ください。

www.suzukikenichi.com

ところがこの記事で言及されている通り、基本的にPCと同じhtmlやassetsがサーバから送られるので、スマホ用に最適化したものよりも転送量が多くなってしまいます。 実際のところシビアなのは画像で、その他はある程度工夫しようと思えば乗り切れます。

極端な話PC/スマホだけで使用するcssやjsは別にしてminifyした1枚を追加してしまえばいいので出し分けが難しくありません。(ユーザエージェントとviewportは同一ではないという点はありますが。まぁviewportを見て内部的なフラグを持つことも可能です。)

問題は画像で、例えばPCの幅1000pxの画面で横いっぱいに表示する画像が1000x500だったとして、仮にPCのretinaディスプレイをケアすると2000x1000の解像度が必要になります。ところがスマホだとたかだか320x160のretinaで640x320なので、20001000/(640320)=9.7倍もの無駄な転送量がかかってしまいます。

wifiだと問題ないですが、LTEだとけっこう気になってしまいますし、レスポンシブの場合は<img>タグにwidthやheightを書けないので、画像サイズはWebサーバから配信された時点でようやくブラウザ側から判断可能になります。従って画像が読み込まれるたびに表示されているコンテンツが画像高さ分ズレる、というようなダサい挙動が発生します。

解決策1. viewportを見てjsで切り分ける

http://blog.cntlog.net/?p=691

こちらの記事ではdevice-pixel-ratioを見て画像ファイル名に@2xをつけるとか、そういう解決策が紹介されています。

例えば

<img data-small="images/hoge_small.png" data-medium="images/hoge_medium.png" data-large="images/hoge_large.png">とかにして

viewport, device-pixel-ratio等から最適なサイズを出し分けるというのはアリな気もしますが、全体的にこれをやろうと思うと手間もかかりますし、ファイル名にルールを持たせるにしても@2xをつければ2倍になるというようなルールをクライアント、サーバ両側に強いるのは非現実的です。

この手のものはアイキャッチ画像や、ページ中で非常に重要な画像に限り有効だと思います。

解決策2. HTML5のsrcset等を利用する

私も知らなかったのですがsrcset, sizesという属性がHTML5で追加されているそうです。

http://kia-king.com/blog/tutorial/responsive-images-with-srcset/

対応ブラウザが少ないのはpolyfillがあるので大丈夫、ということですが、どうなんでしょうか・・・。 まず対応ブラウザが少ないものはスタンダードとなっていないということで、何か問題があるのでは? と疑ってしまうのとか、いかに技術的に便利でも標準の流れにないものを採用するにはけっこうコストがかかるという経験則、ついでにいえばpolyfill的なものは一見便利で2年後ぐらいにメンテされなくなったりするので、けっこう地雷だと思っているので、まぁまだ手が出せないなという印象でした。

解決策3. 妥協する

話はそもそもPCのretinaに画像を対応させようというところから来ているので、

  1. PCのretina対応を基本的にはしない
  2. スマホのretina対応もやる画像とやらない画像(1x採用)で分ける
  3. レスポンシブのブレークポイント(col-xs-xxみたいなやつ)で画像の表示が大きく変わるときに画像サイズが表示のサイズより小さくて荒くなったりしても気にしない

ということにしてみました。

で、そうすると480x360くらいで呼び出していた画像が1ページに20枚くらいあったんですが、これを160x120で呼び出し、さらにimagemagickで画像クオリティを70%に落としました。

これでファイルサイズ的には一気に1.5MBほど減らすことができました。

Google PageInsights

デバッグにはこれが便利です。他のサイトを見ても完全な最適化をせずにここで「最適化すれば700KB~900KB削れる」と指摘されるくらいまでが許容できる気がします。

たいていのケースで画像サイズによって転送量が増え、ユーザビリティが下がってしまうのはモバイルの場合なので、あとはモバイル単体で大きめの画像を使い過ぎないデザイン、および強調してモバイルに無理強いをしないPCデザインをいい按配で考える、というのが妥当かなと思います。