2014/6/21に開催されたFrontrend in NagoyaのRe-think about Web Performanceのセッションの資料です。

1. Frontrend in Nagoya
2014/6/21
@1000ch

3. Performance
Evangelist
パフォーマンス改善
および推進活動

4. 名古屋初上陸！

5. Google I/O 2014
参加してきます！

6. Webフロントエンド最前線
新連載始まります！

9. To me, performance is a feature, and I simply like using
fast websites more than slow websites, so naturally I'm going to build a site that I would
want to use. But I think there's also a lesson to be learned here about the competitive
landscape of the public internet, where there are two kinds
of websites: the quick and the dead.
Performance is a Feature
http://blog.codinghorror.com/performance-is-a-feature/

10. パフォーマンスは
機能の1つである。

11. この世には2種類のWebサイトしかない。
早いか、死んでいる
かのどちらかだ。

12. パフォーマンスを軸にした
ユーザー体験の差…

13. ページが1秒で表示されると…

14. 3秒経ってもページが表示されないと…

15. 約60%のユーザーが離脱する
その内80%は2度と戻ってこない

16. ページビューの低下
ECサイトであれば売上の低下
各種コンバージョン
当たり前だけど、デメリットしかない

17. いくらコンテンツが良くても
遅いサイトにユーザーは来ない

18. Webパフォーマンスの3大要素
Render ComputeNetwork

19. Network (リソース取得関連)
Network
サーバーサイド
プログラム
DNS Lookup?
KeepAlive?
<img src=…>
<link href=…>

20. Render (描画関連)
Render
CSS3
CPU or GPU
Render Tree
= DOM + CSSOM

21. Compute (JS実行関連)
Compute
V8?
JIT Compile?
Garbage Collection
物理演算処理

22. ページが表示されるまで
Initialize Process
RenderNetwork Compute

23. 閲覧中・ページを閉じるまで
Runtime Process
Render ComputeNetwork

25. Amebaあるある

26. プランナー ディベロッパー
ここにコンテンツを
追加したいです！
（どんどんページが縦
長になっていく…）

27. エンジニア ディベロッパー
サーバーサイドの
実装終わりましたー！
（このAPIまとめて欲
しかった…）

28. パフォーマンスに対する
開発者の意識の欠落…

29. プランナー ディベロッパー
このスケジュールで
お願いします！
（忙しくてチューニン
グどころじゃない…）

30. 開発負荷が高すぎて
チューニングが後手に回される

31. デザイナー ディベロッパー
ここのマージン
やっぱり10pxで！
（また微調整か…）

32. エンジニア ディベロッパー
このAPIはこう返却す
るようにします！
（JSONの形式変えない
でくれーorz）

33. エンジニアとデザイナーの間で
板挟みになりがち

34. 招かれる結果

35. 積み上がるレガシーコード
デザインへの対応で肥大化するCSS
技術的負債
最適化せずリリースされるプロダクト

36. 頻繁に行われるデザインリニューアル
短すぎるスケジュール
疲弊する開発者
とにかく色々とシビア

37. 後になればなるほど
修正は困難になる

38. プロジェクト分析

39. 遷移ベースがほとんど（SPA少ない）
ゲーム系プロダクトは特に運用が辛い
サービスの分布
ガラケーに対応している古参サービスも

40. イニシャルコストを最適化出来ていない
大量のサードパーティモジュール
コードの状態
長きに渡ったプロジェクトの負の遺産

41. 結構大変…orz

43. 各方面と
対話してもらう

44. 「ボタンの余白、統一して！」
「この影ならCSSで出来るんですが！」
対デザイナー例
「画像の要らないテクスチャに！」

45. 「ビルドフローに●●を含めて！」
「このレスポンス早くなりませんか！」
対エンジニア例
「キャッシュを効かせて！」

46. パフォーマンスに対する
意識を植え付ける
+
フロントエンドで（ある程度）
イニシアチブを取る

47. もちろん精神論だけ
ではダメなので…

48. 具体的に数値を示し
対策を提案する

49. 各種計測ツールが
あります

50. PageSpeed Insights

51. YSlow

52. PSI

53. Phantomas

54. WebPageTest

55. Kingfisher
WebPageTest Private Instance

56. 社内専用のプライベートインスタンス
Ameba専用にUIをカスタマイズ
WebPageTest for
キュー待ちなし！APIキー不要！

57. これらのツールで
実際に計測する

58. 発生している
HTTPリクエストの一覧

59. CSSや画像といった
サブリソースを返却する
サーバーレスポンス
HTMLを返却する
サーバーレスポンス

60. 20:80

61. HTTPリクエストは…
Render ComputeNetwork

62. CSS・JSファイルの結合と圧縮
HTMLファイルの圧縮
ネットワーク最適化
画像の減色とメタ削除
キャッシュヘッダ・Gzip等

63. 画像の最適化、重要

64. CSS、JSをいくら削減しても
画像の最適化を忘れれば水の泡
ファイルサイズの半分を
メタ情報が占めていることもある
たかが画像されど
キービジュアルでなければ
多少の劣化は許容する判断も必要

65. https://github.com/1000ch/compress-image
PNGの最適化
58,217 bytes 14,244 bytes
76%down

66. https://github.com/1000ch/compress-image
JPGの最適化
141,033 bytes 14,045 bytes
90%down

67. ImageOptim

68. ImageAlpha

69. grunt-image

70. これらの対策案を
プロジェクトに
フィードバック

71. @1000ch
プロジェクトBの人
ココを直して下さい！
プロジェクトAの人

72. プロジェクトAはやってくれた
プロジェクトBはやってくれなかった
その後…
忙しさに多少の差はあれど…

73. どうしても
属人的になる

74. コードを直してプルリクエスト
便利ツールの作成して使ってもらう
それでもだめなので
かくなる上は最終手段…

75. 対策を義務化する

76. レスポンス選手権

77. ランキング付けして競争心をあおる
少しずつレスポンスを気にするように
レスポンス選手権
ストップウォッチで計測

78. ストップウォッチ…
(´･∀･`)？

80. (・×・)

81. 爆レス大会

82. WebPageTestのプライベート版で計測
SpeedIndexとVisualCompleteが指標
爆レス大会
1日3回計測、1週毎に結果配信
1月に1度、ランキング上位に景品

83. Speed Index
0
2500
5000
7500
10000
5月1週 5月2週 5月3週 5月4週 5月5週
プロジェクトA
プロジェクトB
プロジェクトC
低ければ低い程
パフォーマンス良❤

84. Speed Index
0
2500
5000
7500
10000
5月1週 5月2週 5月3週 5月4週 5月5週
プロジェクトA
平均スコアNo.1

85. Speed Index
0
2500
5000
7500
10000
5月1週 5月2週 5月3週 5月4週 5月5週
プロジェクトB
改善率No.1

86. チューニンガソン

87. 運用中では改善が後手に回ってしまう
PJから数人選出して連れて行く
短期集中改善合宿
長期的にダラダラやるより集中して直す

88. 絶賛進行中…

89. 徐々に広がる
パフォーマンス文化

91. パフォーマンスを
重要視する土壌が必要

92. 開発の中心だからこそ
周りを巻き込んでいく

93. パフォーマンスとの
戦いは終わらない…