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

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

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はあまり載ってない
以下斜め読んだ内容
  • 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、解像度は4パターン、iphone/ipadは実機で
        • PC版とほぼ同じリソース(html/css/js/img/json/etc..)をモバイルでもDLさせてる、とか
        • 掲載サイトの5割〜9割は、ノーガード
        • 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なサイトはモバイル環境で4〜5倍くらいは高速化できる
  • とはいえ「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な画像表示のために標準化プロセスへ持っていったような努力をしていく
  • ビジネスの中に「速度」を組み込んでいく
    • サイトが遅いことを要注意認定のバグなんだと考える風土を作ってく
  • 実装する側にとって取っ掛かりになるよいリソースがある
  • 事実を受け入れる
    • RWDで作ることとは遅いサイトを作る事に他ならないこと
    • RWDには代償がある
      • retina対応の画像がよりリッチなコンテンツを可能すると同時に速度低下をもたらした。これと同じ話がRWDにも言える
    • 事実を受け入れ、代償を減らすためにできることを積み重ねていく
  • コメント欄
    • Guyが丁寧にリプライしてるがinfomartiveだと感じる部分ゼロ