Guy Podjarny「Responsive Web Designなサイトは遅い、と言っておこう」

Guy's Pod 2012.10.9のブログエントリ
追記
- 元エントリが更新されてたので、修正
- Guyのプレゼン動画聞き齧った内容も少し反映

Guy's Pod » Blog Archive » Responsive Web Design is bad for performance. There, I said it.

世界のトラフィックの数割を捌くAkamaiの中の人によるResponsive Web Designネタ
Guyはモバイル向け速度計測ツール作ってたblaze.ioのCTOだった人
- blaze.io自体は2月にakamaiに買収された
RWDに期待してる、人にも勧めてる
けど認めるべき事実としてRWDは遅い、最適化してもどうにもならない部分残る
その上でRWDでいくのに必要なこと、考えるべきこと、etc.を綴ったエントリ
RWDが引き起こす速度低下は軽減できるがゼロにはならないでしょ、という立場から書かれてる
「RWDを頑張って高速化させる」系TIPSはあまり載ってない
- tips系は、エントリ途中でリンクしてる、スライドに詳しく載ってる
- Performance Implications of Mobile Design (Perf Audience Edition)
- 2012.4.16-18にOrlandで開催されたBDConfでGuyがプレゼンした時のスライド。プレゼン動画もvimeoにアップされてる
- Guy Podjarny - Performance Implications of Mobile Design - BDConf, April 2012 on Vimeo
- 数値、データ豊富でinformativeだが、リソース集としても有益
- rwdのパフォーマンスという（RWDシンパからはまず出てこない）切り口
- モバイル環境でのボトルネックについて事例つきで書いてる60枚くらいのスライド

以下斜め読んだ内容

responsive web design
- 好きなアプローチだし筋はいいと思う
- けどRWDはとりあえず遅い
- RWDが遅くさせたwebを速くさせるのは結構難しい
ハイパフォーマンスresoponsive web siteは不可能？
- そうは言ってない
RWDダメ絶対？
- それも自分は言う気がない
RWDは大抵の場合オススメできる
RWDはページを込み入ったものにさせる
- そういう宿命
- 概して、モバイルで遅くなるよね
RWDネタで書こうと思ったきっかけはTim Kadlecの良エントリ
- Blame the implementation, not the technique - TimKadlec.com
  - （補足）rwd、css プリプロセッサ、エディタ、etc..。個々の技術/ツールに優劣無し、rwdでも適切に実装すれば速くなるよ、という主旨の原則論一杯・データゼロなエントリ
- Tim曰く、実装が良ければたいていの問題は解決できる
- Tim曰く、例えばRWDだって、正確無比に実装すれば高速化できるよ
Timには一般的は同意できる
自分はRWDのパフォーマンスの悪さについて最近プレゼンしたことがある
- Performance Implications of Mobile Design (Perf Audience Edition)
  - （補足）
    - モバイル専用サイト、RWDなサイトのそれぞれのボトルネック、対策を解説してる
    - モバイル専用サイトのボトルネック
      - モバイルサイト本体には問題無し。軽量・高速
      - PC版からのリダイレクトがボトルネック
      - よくあるwww.hoge〜からm.hoge〜へのリダイレクトとか
      - ESPNだと1.3秒のロス、ディスニー系サイトで2秒くらい
      - httpのリダイレクト、js使ったリダイレクト、それぞれのコスト
      - リダイレクトの最小化が、モバイル専用サイトの高速化のポイント
    - RWDサイトのモバイルWebでのパフォーマンスの実情
    - まずはmediaqueri.es
    - Media Queries
    - RWDなサイトのショーケース・お手本リスト
    - スライド作成時点で掲載されてた347サイト。全部調べた
    - webpagetest、解像度は４パターン、iphone/ipadは実機で
    - PC版とほぼ同じリソース（html/css/js/img/json/etc..）をモバイルでもDLさせてる、とか
    - 掲載サイトの5割〜９割は、ノーガード
    - 86％のサイトで、DL量がPC/モバイルでほぼ同じ
    - 11%のサイトで、DL量が減っても10%〜50%減の範囲
    - 3%のサイトでだけ、DL量が50%以下に減らす努力やってる
    - スマホで表示されてないコンテンツもPC版同様にDLされてます
    - メディアクエリがPC向けcssロード自体はストップしてくれない、とか
    - 「display:none」したってDLは止まらない
      - 似た話として、css media queryやmedia typeも、DLの振り分けとかやってくれない
      - smashing magzineは何か勘違いしてないか？
    - PC版と同じ画像をDLさせてリサイズさせてるだけ。横行してる
    - どうしてPC版並の巨大なDOMツリーがモバイル版でも構築してるんだ？
      - RWDの成功例「Boston Gloveサイト」
      - 表示はディスプレイサイズに合わせて可変。モバイルではシンプルに
      - しかし、1400要素、4000ノードという巨大なDOMツリーが構築されてます
    - 不要なリソースDL、過剰なDOMツリー
      - これがRWDがモバイルWebを遅くさせる元凶
    - RWD高速化TIPS
      - 画像をなんとかできると一番大きい
      - モバイルのトラフィック上位数千サイトでデータ取った
      - リソースDLの67%は画像
      - responsiveな画像DL
      - サーバーサイド、クライアントサイド
      - w3cで標準化が期待されてる部分
      - Picture Element Proposal - Responsive Images Community Group
      - 標準化されればimg要素を拡張しマークアップレベルで解決
      - いわゆるmobile firstを読み替えて高速なモバイルwebへ近づく
        
        domツリーのサイズをモバイルに最適化。デザインにフォーカスするのではなく
        
        ミニマムなDOMツリーから、リッチな環境に合わせてDOMツリーをjsでエンハンスしていくアプローチ
      - ミニマムDOMツリーからjsでエンハンスしていくアプローチ
        
        PC版でjsオフにしている人を無視してる
        
        jsオフにしてるPC環境は1%。彼らへの配慮と、モバイルでのパフォーマンスは両立しない
        
        どっち？と言われれば、モバイルのパフォーマンスを取る
        
        解像度やレイアウト別にDLされるファイルを分けれるようにする
        
        レイアウトをコントロールするjsはインラインで書く
        
        解像度に合わせてjs/cssダウンロードに使うscript/link要素のappendはdocument.write使う
        
        httpリクエストを減らす工夫。ファイル結合、htmlに直書き
        
        DLサイズ減らす工夫。minify。画像のフォーマット最適化
        
        表示に必要なコンテンツを最初にDL。他は後回しにするDLの仕組み。オンデマンドなDLとかも
        
        「@import」使わない
    - m.hoge.comのようなモバイル専用サイトを比較対象に。DLされるリソースサイズの最適化を図る
    - 計測ツール色々。計測しないと無意味
      - mobitest,pcapperf(by google),icy(by stoyan stefanov),iwebinspector,webpagetest
- たいていのRWDなサイトがクソ重い原因は単に実装がクズ過ぎるせい、ということを言ってきた
自分はakamaiでこの手の高速化を自動的にやってくれるツール開発に取り組んでもいる
たいていのRWDなサイトはモバイル環境で４〜５倍くらいは高速化できる
とはいえ「RWDはwebを遅くする」という事実は揺らがない。今後も同じ
RWDの問題は複雑さに起因する
よくある「m.」なモバイルサイト（m.hoge.com、m.foo.com）
- シンプル
- htmlだけとかから作り始めれる
- 送受信されるパケットも軽量
- css,js,画像も少量で、それぞれが軽量（なことが多い）
他方RWDなサイト
- 複雑
- スマホでアクセスするとRWDなページはブラウザに巨大なhtmlをDLさせる
- やっとhtmlロード終わっても、js,css,画像の読み込みが更に始まる
- 可能な限りリソースの読み込みを回避する
  - 可能だし、やるべき
  - だが結構難しい
- 実装に問題のないRWDなサイトを作れた場合
  - リソースの読み込みを避けて、コードが複雑化するのを避けることのできたサイト
  - そのレベルに到達してもパフォーマンスは犠牲になる
RWDなサイトをチューニングしまくっても、シンプル軽量なモバイル版（m.hoge..なサイト）の速度には追いつけない
- 同様なチューニングはモバイル版にも出来るから追いつけない
- 現状を見れば、RWDなサイトはモバイル版サイトよりも常に遅い
ここまで言っておいてなんだが自分はRWDを支持してる
他人にもRWDをすすめる
まあ速度は唯一重要なことじゃないから
- webが速度を無視した方向に舵を切ったのは今回が初めてじゃないし
- 90年代初期のお話
  - テキストサイト全盛期
  - パフォーマンスは驚愕のクオリティ
  - googleのトップページも比較にならないくらい高速な世界
  - スクリーンサイズに自動的にアジャストしてた
  - だがUXはひどかった
  - 高速化の恩恵はあった
    - 自分の探してるものがこのサイトにないから別のサイトへ行く、というステップがスピーディー
サイトの最適化をするというなら、最適化のリストに「高速化」が入ってないはナンセンス
- だが速度は唯一考慮すべき項目、という信条を持てるほど自分はナイーブじゃない
- 速度第一にしたら？と他人にも勧めることはない

じゃあどうすればいいのか？

今やってることをそのまま続ける
RWDやってるならそれをプッシュする
- と同時にパフォーマンスのことを意識する
エンジニア、デザイナーへ啓蒙する
- 彼らが「速度」のことを念頭に置くようにしてく
- 今日から今できる最善の手を打つ
ブラウザベンダーに働きかける
- 高速なresponsiveなサイトをより容易に構築できるように
- responsiveな画像表示のために標準化プロセスへ持っていったような努力をしていく
ビジネスの中に「速度」を組み込んでいく
- サイトが遅いことを要注意認定のバグなんだと考える風土を作ってく
実装する側にとって取っ掛かりになるよいリソースがある
- An Ajax-Include Pattern for Modular Content | Filament Group, Inc., Boston, MA
- scottjehl/picturefill
事実を受け入れる
- RWDで作ることとは遅いサイトを作る事に他ならないこと
- RWDには代償がある
  - retina対応の画像がよりリッチなコンテンツを可能すると同時に速度低下をもたらした。これと同じ話がRWDにも言える
- 事実を受け入れ、代償を減らすためにできることを積み重ねていく
コメント欄
- Guyが丁寧にリプライしてるがinfomartiveだと感じる部分ゼロ