行ってきました。
絶対ブログ書く人類枠だったのでブログ書きます。
ハッシュタグは #frontrend。また動画が FRESH! で観られます。
FRESH! クライアントサイドパフォーマンス改善
FRESH! 鈴木雅佳 ( @sutiwo_ ) さん
1. SW で静的アセットのキャッシュ
- 設計方針と実装方法
- キャッシュがあればキャッシュを返し、なければフェッチ
- リリース単位でキャッシュさせるもの（Circle CI の build_id に紐づく）
- 意図的に更新させないとキャッシュされ続けるもの（version.json に任意の日付を入力）
- SW のディレクトリ構成
service-worker/ - assets.js // Web フォント・CSS・JS ファイルのホワイトリストを作成 - index.js // イベントハンドラの登録 - register.js // SW がインストールされているかの確認
最終的に browserify で service-worker.js へ
- ローカルで確認するときはブラウザでスーパーリロードも使えるが、環境変数にフラグを用意するのをオススメ
DISABLED_SW_CACHE: bool
2. Intersection Observer で遅延ロード
- 遅延ロード：スクロールなどをトリガーとして画像を非同期ロード
- FRESH! での例：コンテンツのランキング画面
- ランキング画面には 50 位ぐらいまで表示する必要があるが、常に見えているのは 6 個ぐらい
- FRESH! での例：コンテンツのランキング画面
- Intersection Observer
- 特定の DOM 要素が画面内に存在するかを判定するための API
- React コンポーネントとして OSS 化した：openfresh/viewport-observer
3. SVG スプライトやめてプログレッシブなロード
パフォーマンスを改善して本を売る！「読書のお時間です」の取り組みについて
ブックテーブル 小林正弘( @masahiro_koba ) さん
※資料公開されたら貼る
- SPA + SSR
- 技術選定
- jQuery, handlebars, grunt から React, Flux, webpack などのモダンなツール・ライブラリへ
- 旧システムのページと共存、行き来できる設計
#!（ハッシュバン）から/（パスルーティング）へ
- 1 ページに大量の書籍の表紙画像を表示する必要がある
- サイズ X px、圧縮率 でクライアントからリクエスト -> Image Magick で圧縮
- 事業 KPI との関連を可視化
アメブロ: Isomorphic Application のパフォーマンス・チューニング
アメーバブログ 侯斌 ( @houbin217jz ) さん
- アメブロ SP リニューアル 2016.8
- チューニング内容
- バックエンドのキャッシュ
- 遅延ロード＆コード分割
- Service Worker＆アセットのプリキャッシュ
バックエンドのキャッシュ
- Perf (SSR React) < Perf (Template e.g. Handlebars.js)
- バックエンドキャッシュの設計
- 問題点を洗い出す
- 何をキャッシュする
- 保存・削除するタイミング
- 問題点を洗い出す
- ReactDOMServer.renderToString() の結果をキャッシュしたい
- クライアントによって動的に変わる内容があるので、生成されたHTMLをそのままキャッシュするのではなく、ユーザーの情報に依存しないテンプレート部分のみキャッシュ
- キャッシュ削除タイミング
遅延ロード & コード分割
- SSR の流れ：
- コード分割
- 必要ないコンポーネントをロードしないようにして JS 評価時間が短くなるように
- 分割粒度： Atomic デザインの Organisms 毎
- webpack の dynamic import で
- Lazy Load にしたい場合
const loadExample = () => import('./ExampleComponent')
- Lazy Load にしたい場合
- リビルドが遅いのでローカル開発ではコード分割を無効化する
SW & アセットのプリキャッシュ
- AMP ページ amp-install-serviceworker
- Google の workbox 使ってる
余談
HTTP/2 にしてないと細かく分割した JS はブラウザの同時接続数の問題になりそう…という予想は当たっていたが
SSR だと少なくとも（一番読み込みファイル数が多くなるであろう）初回表示でそういったことは問題にならないのか。なるほど。
おまけ
話に出てきてあまり理解できなかったところの補足。私的メモに近い。
Service Worker・PWA
Service Worker というか PWA については Google for Mobile Workshop Day でやった Google のコードラボがわかりやすかった気がする。
で、やってみるとわかるが、Service Worker を使うためにブラウザが対応しているかチェックしたり起動ほか Service Worker のライフサイクルメソッドを手で実装するのはめんどくさいので
そのあたりよしなにやってくれるライブラリを利用する。
コードラボで紹介されていたのは sw-precache というライブラリだったが、最後の発表で紹介されてた workbox もおそらく似たようなことができるんだろう。
（どちらも触ってはいない）
また、Service Worker 自体はプッシュ通知など様々なことが行えるんだけど、とりあえず導入してその恩恵を受けるのにまずは静的アセットのプリキャッシュを試してみるといいですよ〜というのはコードラボでも Google の人が話してた気がする。
Intersection Observer・遅延ロード（lazy load）
Intersection Observer については前々から聞いてはいたもののどういったものなのか知らなかったが、jxck さんの記事が参考になった。
Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.io
また、lazy load については以前弊社の勉強会で外部の方がこういう LT をしてくれたんだが
そのときは難しくてわからなかった。。。今見たら多少は理解できるだろうか。
みんなにやさしいlazy loadと Reactそしてredux-observable - Google スライド
パフォーマンス測定ツール・指標
会の終わりに
「パフォーマンス測定のためのツールや見るべき指標などは、サイバーエージェント内で全体的に統一されているんですか？」
という質問をした。
（すいません、懇親会出られなかったので最後の発表内容とあまり関係ない質問をしてしまいました。。。）
で、
ということだったので帰り際 @1000ch さんにちょっとだけお話を伺うことができたんだけど、発表にも出てきた通り
- ツール：SpeedCurve
- 指標：Speed Index（これだけというわけではなさそうだが）
を多くのプロダクトでは使用しているとのこと。
SpeedCurve 自体も知らなかったんだけど、特定の URL のページ表示速度を継続的に測定してくれるサービスぽくて良い。
また Speed Index という指標についてはこのあたりを読むと勉強になった。
- Speed IndexというWebパフォーマンスの指標 - EagleLand
- Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc… ::ハブろぐ
感想
SSR + SPA、Service Worker、HTTP/2 などなど次々に実プロダクトに投入していて、そのあたりはさすがサイバーエージェントさんだなあというのが率直な感想です。
自分は業務では Salesforce というプラットフォーム上でアプリ開発をしているので
正直 SSR とか Service Worker とかを業務で使うことはなさそうなんだけど、フロントエンドに関わる人間として知っておかないといけない技術だと思うし
今回 3 名とも事例という形でリアルな話を聞けたのは非常に有意義だった。
（正直めちゃめちゃ難しかったんですが）
また、個人的には最後の発表にあった、JS のコード分割を Atomic Design の Organisms 単位にしているという話が興味深かったです。
Atomic Design の考え方をそこに利用できるのねーという素朴な感想と、Atomic Design も導入して全てうまくいくようなものではなくて何が Atoms/Molecules/Organisms なのかはチームで共通認識を作る必要があると思っているんだけども、
その共通認識の形成や言語化をめんどくさがらずにちゃんとやっておくと今回のような一見関係ない話題でもメンバー同士の会話がしやすいんだろうなあと。
あとこれ。
