Webパフォーマンス最適化のためのコーディング手法
石本 光司（いしもと・こうじ）
株式会社ドーガ
コーディングもするウェブデザイナー
ECサイト運営更新が多い
- ビジネスインパクトとスタンス
GoogleRankingAlgorithmに反映
4/9アナウンス .comのみ
わかっている計測方法２つ
Adwords：品質スコアにページ表示速度が関連している
「HTML」（画像CSSなどはふくまない）の表示速度
→すでに取り組まなければいけない案件
GoogleWebMasterTools
「サイトのパフォーマンス」
上位20% 1.4秒
高速サイトがもたらすほかの利益
再訪問数の増加
セッションあたりのPV増加
コンバージョン率の改善
収益増加
顧客満足度の向上
サーバなどインフラコストの現象
「トーン＆マナー」→耳がない
「SEO」→重要視
→パフォーマンスを意識したコーディング
→会社内での存在意義が高まる
コーダー・デザイナーは忙しい
・HTML5
・CSS3
・JS
・アクセシビリティ
・ユーザビリティ
・アクセス解析
・jQuery
最小限の対策で最大限の効果
- ボトルネックはどこか？
パフォーマンスというみえないものをビジュアライズする
HttpWatch6.2 BasicEdition
ウォーターフォールチャート
→リクエストの各段階で色分けされる
例：ドーガのトップページ：「赤色」が目立つ！
ほとんどがサーバ待ち時間（WaitTime！）＝かならずかかる税金のようなものでどうしようもない
ハンバーガーショップのイメージ
IE6とFireFox3.6では読み込まれ方が違う
→「HTTP/1.1ホスト名ごとの同時接続数（２つまで）IE67」のため ←いまだにシェアが多い
IE8、FireFOXなどは6つなげる
Blockingで接続待ち時間が長い ＝ レジが２つしかない
HTTPリクエストはコストが高い
- 改善事例：株式会社ドーガ
CSSスプライト
データURIスキーム
CSSJSファイルの結合
CSSスプライト
複数画像をまとめて、CSS背景＋位置指定で表示する
１回の注文でチキンナゲット３つ
- 150msの成果
HTTPリクエスト数：11→3
CSSスプライトのジレンマ
ページ数 保守性 最適化 ３つぜんぶをとれない
データURIスキーム
画像をデータでそのままHTMLに埋め込む
base64データ
→最強？ Ie5-7非対応☆
→ハックで分岐処理
サイズ制限 Opera7.2 4.1KBまで
HTTPリクエスト数：1→0
CSSJSファイルの結合
CSS1枚、JS1枚に変更
→メンテナンス性が下がる
なんとかかんとかで@importを擬似的に表現するとさらによい
６→２
CSS3プロパティ
画像を使わないと表現できなかったものを、CSSで表現
ドーガでは使ってない
どの方法も欠点や短所がある
考えた
ChangeDesign！
NicoleSullivanワークショップ
デザインを考え直してみる
SmoothScroll機能って必要？「Topへ戻る」コストをかけてまで使うことはない
ページ高のあるページ自体あまりない
月２万PV中の５回しかおされてなかった
検索画像ボタンって必要？
月５、６回→デフォルトSubmitボタンに変更
２→１
- まとめ
HTTPリクエスト32→17
平均読み込み時間0.5秒
速度統計上位2％にランクイン
パフォーマンスに対するコスト意識
パフォーマンスを武器に効率良く対策すべし
リクエストを減らす簡単な方法はない
それは本当に必要なのか考える
＜感想＞
内容的にはオライリー本でよく知っているものと同じだけれど、実践したことと効果を詳細に説明してとても説得力がありました。また、なぜパフォーマンスのチューニングが必要なのかというコンセプト部分とコーダーの役割・意識についての説明がとてもよかった！基調講演として期待した内容はまさにこの石本さんの話のようなものでした。
