Frontrend in Nagoya 2014/6/21 @1000ch

Performance Evangelist

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

名古屋初上陸！

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

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

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/

パフォーマンスは

機能の1つである。

この世には2種類のWebサイトしかない。

早いか、死んでいるかのどちらかだ。

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

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

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

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

ページビューの低下

ECサイトであれば売上の低下

各種コンバージョン

当たり前だけど、デメリットしかない

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

Webパフォーマンスの3大要素

Render ComputeNetwork

Network (リソース取得関連)

Network

サーバーサイド プログラム

DNS Lookup? KeepAlive?

<img src=…> <link href=…>

Render (描画関連)

Render

CSS3

CPU or GPU

Render Tree = DOM + CSSOM

Compute (JS実行関連)

Compute

V8? JIT Compile?

Garbage Collection

物理演算処理

ページが表示されるまで

Initialize Process

RenderNetwork Compute

閲覧中・ページを閉じるまで

Runtime Process

Render ComputeNetwork

Amebaあるある

プランナー ディベロッパー

ここにコンテンツを 追加したいです！

（どんどんページが縦長になっていく…）

エンジニア ディベロッパー

サーバーサイドの 実装終わりましたー！

（このAPIまとめて欲しかった…）

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

プランナー ディベロッパー

このスケジュールで お願いします！

（忙しくてチューニングどころじゃない…）

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

デザイナー ディベロッパー

ここのマージンやっぱり10pxで！

（また微調整か…）

エンジニア ディベロッパー

このAPIはこう返却するようにします！

（JSONの形式変えないでくれーorz）

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

招かれる結果

積み上がるレガシーコード

デザインへの対応で肥大化するCSS

技術的負債

最適化せずリリースされるプロダクト

頻繁に行われるデザインリニューアル

短すぎるスケジュール

疲弊する開発者

とにかく色々とシビア

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

プロジェクト分析

遷移ベースがほとんど（SPA少ない）

ゲーム系プロダクトは特に運用が辛い

サービスの分布

ガラケーに対応している古参サービスも

イニシャルコストを最適化出来ていない

大量のサードパーティモジュール

コードの状態

長きに渡ったプロジェクトの負の遺産

結構大変…orz

各方面と 対話してもらう

「ボタンの余白、統一して！」

「この影ならCSSで出来るんですが！」

対デザイナー例

「画像の要らないテクスチャに！」

「ビルドフローに●●を含めて！」

「このレスポンス早くなりませんか！」

対エンジニア例

「キャッシュを効かせて！」

パフォーマンスに対する 意識を植え付ける

+ フロントエンドで（ある程度）

イニシアチブを取る

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

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

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

PageSpeed Insights

YSlow

PSI

Phantomas

WebPageTest

Kingfisher WebPageTest Private Instance

社内専用のプライベートインスタンス

Ameba専用にUIをカスタマイズ

WebPageTest for

キュー待ちなし！APIキー不要！

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

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

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

HTMLを返却するサーバーレスポンス

20:80

HTTPリクエストは…

Render ComputeNetwork

CSS・JSファイルの結合と圧縮

HTMLファイルの圧縮

ネットワーク最適化

画像の減色とメタ削除

キャッシュヘッダ・Gzip等

画像の最適化、重要

CSS、JSをいくら削減しても 画像の最適化を忘れれば水の泡

ファイルサイズの半分を メタ情報が占めていることもある

たかが画像されど

キービジュアルでなければ 多少の劣化は許容する判断も必要

https://github.com/1000ch/compress-image

PNGの最適化

58,217 bytes 14,244 bytes

76%down

https://github.com/1000ch/compress-image

JPGの最適化

141,033 bytes 14,045 bytes

90%down

ImageOptim

ImageAlpha

grunt-image

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

@1000ch

プロジェクトBの人

ココを直して下さい！

プロジェクトAの人

プロジェクトAはやってくれた

プロジェクトBはやってくれなかった

その後…

忙しさに多少の差はあれど…

どうしても 属人的になる

コードを直してプルリクエスト

便利ツールの作成して使ってもらう

それでもだめなので

かくなる上は最終手段…

対策を義務化する

レスポンス選手権

ランキング付けして競争心をあおる

少しずつレスポンスを気にするように

レスポンス選手権

ストップウォッチで計測

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

(・×・)

爆レス大会

WebPageTestのプライベート版で計測

SpeedIndexとVisualCompleteが指標

爆レス大会

1日3回計測、1週毎に結果配信

1月に1度、ランキング上位に景品

Speed Index

0

2500

5000

7500

10000

5月1週 5月2週 5月3週 5月4週 5月5週

プロジェクトAプロジェクトBプロジェクトC

低ければ低い程 パフォーマンス良❤

Speed Index

0

2500

5000

7500

10000

5月1週 5月2週 5月3週 5月4週 5月5週

プロジェクトA

平均スコアNo.1

Speed Index

0

2500

5000

7500

10000

5月1週 5月2週 5月3週 5月4週 5月5週

プロジェクトB

改善率No.1

チューニンガソン

運用中では改善が後手に回ってしまう

PJから数人選出して連れて行く

短期集中改善合宿

長期的にダラダラやるより集中して直す

絶賛進行中…

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

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

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

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