- Bonfire Frontend #3に参加してきました。
| タイトル | 発表者 |
|---|---|
| 技術刷新から考えるWeb開発のプロダクティビティ改善 | 竹野 峻輔 / Retty 株式会社 |
| 一休.comのフロントエンドパフォーマンス改善 | 宇都宮 諒 / 株式会社一休 |
| パフォーマンス改善の具体例とサービスへの売上貢献 | 笹原 翼 / ヤフー株式会社 |
技術刷新から考えるWeb開発のプロダクティビティ改善
- 竹野 峻輔さん(Retty 株式会社)
フロントエンド戦国時代
- 一昔は
- サーバサイドでレンダリング + JSで動的制御
- 今は
- BFFとかFluxとか
- 明らかなパラダイムシフト
- サーバ主体からクライアント主体へ
- Rettyの現状
- モノリシックが不便になってきた
- 中長期的な視点で改善したい
- リアーキテクチャ
なぜリアーキテクチャ?
- なぜ？
- パフォーマンス改善(UX)を持続的に行うための土壌(DX)を築いて行く取り組み
- マイクロサービス化
- ただ分割するだけではだめ
- 境界に注目する
- 凝集化と分割(modukaruze)
- 性質が近いものをまとめる
- 持続的な変更可能性の確保(sustainability)
- 拡張削除がしやすいように
- プロダクトもチームも作り変える
- コラボレーション
- 多角的視点でアーキテクチャを整理
- 親和性
- チームとして力を集約する
- コラボレーション
一休.comのフロントエンドパフォーマンス改善
- 宇都宮 諒さん(株式会社一休)
一休のサービス
最適なパフォーマンス
最適化のものさし
- Lighthouse
- いろんなところに組み込まれるようになってる
- 毎回同じ環境で測定するのがいい
- PageSpeed Insightsなど
- PageSpeed Insights
- URLを入れるだけ
- 細かい設定はできない
- WebPageTest
- 環境の条件を設定できる
- デフォルトで3回計測してくれる
Lighthouseのスコア
- スコア
- 0-49: Slow
- 50-89: Average
- 90-100: Fast
- 指標
- TTIが一番重みが強い
- スコアと指標どっちみる？
- スコアはいろんな指標の組み合わせ
- 仕様変更でも変わる
- 具体的な指標を見た方がいい
- スコアは他のサイトとの相対評価で便利
- ECサイトなら
- 50こえれば速い方
- 70超えたら業界トップクラス
- メディアサイトは
- 70以上がマイルストーン
- 30-40くらいが多い
- 最適化をあまり頑張っていないようなところがこの辺
Webサイトの一般的な最適化
- 速くするより遅い要素を減らす
- 遅い要素
- サイズの大きな画像/フォント
- JS
- 大量のHTTPリクエスト
- 重いDBアクセス
- 一休.comの場合
- キャッシュきかせづらい
- リアルタイム性が重要
- 検索クエリ
- 画像サイズ適正に
- Imgix
- 欲しいサイズのパラメータつけて取りに行くと加工して返してくれる
- https://www.imgix.com/
- キャッシュきかせづらい
- 一休コンシェルジュ
- 全員同じコンテンツを返すのでキャッシュしやすい
- Fastlyでキャッシュ
- TTFB最小化10-20ms
- 画像最適化
- Imgix
- JSできるだけ使わない
- AMPの活用
- 全員同じコンテンツを返すのでキャッシュしやすい
パフォーマンスのためのアーキテクチャ
- パフォーマンスに影響のある要素
- JAMStack
まとめ
- パフォーマンス最適化は計測から始まる
- パフォーマンスの伸びしろは要件次第
- 大幅なパフォーマンス改善にはアーキテクチャレベルの変更が必要
パフォーマンス改善の具体例とサービスへの売上貢献
- 笹原 翼(ヤフー株式会社)
ヤフーショッピングのパフォーマンス改善
- ヤフーショッピングのパフォーマンス改善
- => ページの表示速度アップ
- 半年でCVRが110%へ
なぜパフォーマンス改善
どこでパフォーマンス改善
- どのページ
- Frontend/Backend
- クライアント/サーバ
どのページ
- アクセスが多いページ
- そこを通って買う人が多いとこ
Frontend/Backend、クライアント/サーバ
- SpeedCurve
- 定期実行できる
- グラフ化できる
- 色んな指標とれる
- 競合比較できる
- 改善結果が見やすい
- 5万回まで測定可で月5万
どんなパフォーマンス改善するか
- どの指標を見ていくのか決める
- 安定した測定環境を整える
遅い/直列APIの非同期化
- ファーストビューの扱いは注意
- がたつき
間違った非同期
- 画像は全部lazyloadingすればいいわけじゃない
- 思考停止lazyよくない
画像のpreload
- 読み込み開始が速い
JSとCSSのpreload
- 前のページで次のページのリソースとっておく
JSとCSSの非同期読み込み
- 無理なら1ファイルの容量を減らす
画像の最適化(画質)
- 画質90 -> 85に変更
- 容量40%減
- 50ms減
画像の最適化(解像度)
- Retina対応
- 適したサイズを
ハードのリプレイスすけ＾ルアウと
- 高スペックで高速化
JSとCSSの軽量化
- カバレッジを見て使ってないリソースは削る
- Devtoolsで見られる
どんな効果があったか
- 競合3社中2位に
- CVRが110%へ
- SEOにもいい影響
- クロール量の増加
今後
- 更にパフォーマンス改善
- AMP?
- Signed HTTP Exchangesでドメイン問題解決
- 計測は実ユーザデータ使いたい
