超チューニング祭ふりかえり（UIデザイン賞と学生賞をもらいました）

1. 超チューニング祭 ふりかえり
-HTMLチューニングの方法と実際-
2 0 1 4 / 0 4 / 2 9
高橋せいべえ
村井研究室 学部3年

2. 1. 超概要
2. 超結果･超分析
3. フロントチューニングとコスパ
4. UIデザインの工夫点

3. 基本ルール（抜粋）
ベースとなる現行 niconico スマートフォンサイトを元に
各自で速度のチューニングやデザイン・UIの改善をしていただきます。
※ あまりにも曖昧だったので 参加者でソーシャルハック した。
コンテンツが2Click以内に表示されれば何をしてもよいらしい。
でも詳しい計測方法などは最後まで分からなかった。

4. 主なチューニング
• HTML/CSSのフルスクラッチ
• JSライブラリの差し替え
(jQuery. -> Zepto.js)
• 画像の遅延ロード (unveil.js)
• PNG画像の最適化
• アイコン画像のHTML埋め込み
• Grunt.による自動処理
• grunt-contrib-concat (ファイル結合)
• grunt-autoprefixer (最適なprefix)
• Grunt-contrib-cssmin (CSS圧縮)
• Grunt-contrib-uglify (JS圧縮)
• grunt-contrib-htmlmin (HTML圧縮)

5. 結果（抜粋）
投票1位、速度5位
（ベストUI賞、学生賞）
速度1位
わたし
最優秀

6. 結果を分析する
公式結果 (iOS7.1) 速度1位 速度2位 速度3位 速度4位 速度5位
DL時間 0.0568 0.4945 0.5860 0.8751 0.9791
レンダリング時間 0.1510 0.0120 0.0586 0.0506 0.0573
合計表示速度 0.2078 0.5065 0.5972 0.9257 1.0364
測定方法
iOS7.1.1/Safari/docomo LTEにて、各10回計測。
平均値(?)を結果として記載。キャッシュや平均の詳細は不明。
公式の測定方法が
よくわからない。
なにこれ？

7. 結果を分析する
公式結果 (iOS7.1) 速度1位 速度2位 速度3位 速度4位 速度5位
DL時間 0.0568 0.4945 0.5860 0.8751 0.9791
レンダリング時間 0.1510 0.0120 0.0586 0.0506 0.0573
合計表示速度 0.2078 0.5065 0.5972 0.9257 1.0364
測定方法
iOS7.1.1/Safari/docomo LTEにて、各10回計測。
平均値(?)を結果として記載。キャッシュや平均の詳細は不明。
公式の測定方法が
よくわからない。
仕方がないので、
自分でも測定して
結果を比べてみよう。

8. 再測定 (Opera20) 速度1位 速度2位 速度3位 速度4位 速度5位
リクエスト回数 0回 1回 2回 11回 16回
ダウンロード容量 0KB 0.7KB 12.8KB 170KB 119KB
DOM要素数 594 2 31 158 345
DOMContent
Loadedイベント
0.2417 ??? 0.1103 0.2467 0.2220
Loadイベント 0.2440 ??? 0.1503 0.2587 0.2627
自動ページ遷移 無し 有り 有り 無し 無し
測定方法
Win8.1/Opera20.0/VDSLにて、各5回計測。
初回のみキャッシュなし。最速と最遅を除く3回の平均を記載。
公式の測定方法が
よくわからない。
仕方がないので、
自分でも測定して
結果を比べてみた。
結果を分析する

9. 再測定 (Opera20) 速度1位 速度2位 速度3位 速度4位 速度5位
リクエスト回数 0回 1回 2回 11回 16回
ダウンロード容量 0KB 0.7KB 12.8KB 170KB 119KB
DOM要素数 594 2 31 158 345
DOMContent
Loadedイベント
0.2417 ??? 0.1103 0.2467 0.2220
Loadイベント 0.2440 ??? 0.1503 0.2587 0.2627
自動ページ遷移 無し 有り 有り 無し 無し
測定方法
Win8.1/Opera20.0/VDSLにて、各5回計測。
初回のみキャッシュなし。最速と最遅を除く3回の平均を記載。
公式の測定方法が
よくわからない。
仕方がないので、
自分でも測定して
結果を比べてみた。
結果を分析する

10. 超 残念な結論
モバイル回線では、リクエスト数の少ないものが勝つ。
→ 実際の現場ではほとんど役にも立たない。
「リクエスト数を簡単に減らせたら苦労しないよ！」
フロントチューニングは無駄なのか？
そうではない。しかし、コスパの良いものを選ばないと後悔する。

11. チューニング技法 効果 導入 コメント
HTML/JavaScript/CSSの圧縮･結合 良 簡単 必ずやるべき
CDNの利用 (Google Libraries API等) 良 簡単 グローバルサイトで効果的
画像の遅延ロード (Unveil.js) 優 普通 推奨。imgタグの記述を工夫する必要がある
PNG画像の最適化 可 普通 Kflate圧縮アルゴリズムによる可逆圧縮。
自動化必須
jQuey.jsのZepto.jsによる代替 良 面倒 軽量かつスマホに最適化されたライブラリ。
完全互換でないので移行は手間がかかる
CSS Sprite (画像の結合) 可 面倒 レイアウト変更時の作業が大変。
自動化必須
base64 encoding (画像の埋め込み) 可 面倒 画像容量が135%肥大化するので要注意。
初期ロードが遅延する危険性がある
画像のWebフォント化 可 面倒 CSS Spriteのベクター版。単色画像のみ

12. チューニング技法 効果 導入 コメント
処理の重いCSSプロパティーを使わない ほぼ無 面倒 正直ほとんど意味がない
ApplicationCache (オフライン対応) 優 大変 2回目以降のアクセスで劇的な効果。
キャッシュマニフェストの厳格な管理が必要
JS/CSSのフルスクラッチ 可 大変 納得できるまで書き直す。採算度外視
画像の色分布最適化 可 大変 コスパ悪すぎ
画像を使わない 良 無理
提言
自動化できないチューニングを現場で活用するのは現実的でない。
きちんと実装･管理コスパを考えて最適化をしたい

13. ベストUI賞をいただいたデザインの解説
時間がないのに
イラレでデザインを組み、
徹夜でHTML/CSSを
フルスクラッチした。
スライドメニューなども
考えたが、時間の都合で
実装せず。

14. ベストUI賞をいただいたデザインの解説
どうしたら軽いままデザインを良くできるか？
元はモノクロで淡白なデザインだった
→ PC版と同じカラーを採用
→ 見出しは日本語Webフォントを使った
（やさしさゴシックをサブセット化して使用）