実践！パフォーマンス改善

パフォーマンス改善の実践的な取り組み方を紹介

Transcript

1. 平野 耀介 実践！パフォーマンス改善 2021年 07月 28日
2. なぜ僕が話すのか？
3. 担当PJにおける改善成果 • Core Web VitalsがPC / SP全て良好に • PSIが15程度から 60〜80に
4. 本会の１番の動機
5. 同じ苦労をしないでほしい😭😭
6. 本日お話すること（≒ゴール） 1. （Why）なぜパフォーマンスを改善するべきなのか 2. （How）どのように改善すればよいのか 3. （How事例）どう改善したのか
7. 本日お話すること（≒ゴール） 1. （Why）なぜパフォーマンスを改善するべきなのか 2. （How）どのように改善すればよいのか 3. （How事例）どう改善したのか
8. なぜ改善するべきか 【結論】２つの事業的メリットがあるから 1. SEO 2. ユーザー体験改善による収益性（≒離脱率, CVR）の向上
9. 2018年7月から読み込み速度がランキング要因に 2021年6月からコアウェブバイタルがランキング要因に つまり、ページパフォーマンスはSEOに直接的な影響がある ※どちらも同点決勝の基準程度の重み → 当然ながら関連性やコンテンツ品質などのが重み大 なぜ改善するべきか 1. SEOとの関連性
10. なぜ改善するべきか Googleいわく、 表示速度: 1秒 → 3秒　直帰率: 32%上昇 表示速度: 1秒 → 5秒　直帰率: 90%上昇 Pinterest 待ち時間を40%削減　→　SEOの流入とログイン率が15%向上⤴ > 参照: Pinterest - Driving user growth with performance improvements 2. 収益性との関連性
11. なぜ改善するべきか Googleいわく、 表示速度: 1秒 → 3秒　直帰率: 32%上昇 表示速度: 1秒 → 5秒　直帰率: 90%上昇 Pinterest 待ち時間を40%削減　→　SEOの流入とログイン率が15%向上⤴ > 参照: Pinterest - Driving user growth with performance improvements 2. 収益性との関連性 CVR ⤴ 離脱率 ⤵
12. なぜ改善するべきか パフォーマンス改善をする理由は２つの事業メリットのため 1. SEO 2. ユーザー体験改善による収益性向上（離脱率⤵, CVR⤴） その他のメリット • リクエスト量の削減 • ユーザー体験向上 まとめ
13. 本日お話すること（≒ゴール） 1. （Why）なぜパフォーマンスを改善するべきなのか 2. （How）どのように改善すればよいのか 3. （How事例）どう改善したのか
14. どう改善するのか 目的を明確にする 例）SEOのためにCore Web Vitalsを全て良好にする まずは目的・目標を定義する 1 計測して現状を把握する 2 指標ごとの目標を決める 例）LCP: 2.5s, FID: 100ms, CLS: 0.1 3
15. どう改善するのか 目的を明確にする 例）SEOのためにCore Web Vitalsを全て良好にする まずは目的・目標を定義する 1 計測して現状を把握する 2 指標ごとの目標を決める 例）LCP: 2.5s, FID: 100ms, CLS: 0.1 3
16. 計測してみよう！💪
17. 見なくていい PSIの読み方
18. フィールドデータ または リアルユーザーモニタリング (Real User Monitoring) PSIの読み方
19. 計測の知識 実ユーザーの環境で計測する方法 • Chrome UX Reports • Search Console • NewRelic Browser Googleの呼び方 フィールドデータ Chrome UX Report Search Console 計測方法① リアルユーザーモニタリング（RUM）
20. ラボデータ または 合成モニタリング (Synthetic Monitoring)
21. 計測の知識 可能な限り環境の一貫性を保ち計測する方法 • PageSpeed Insights • Webpagetest • Lighthouse (※1) Googleの呼び方 ラボデータ 計測方法① 合成モニタリング (Synthetic Monitoring) (※1) ある程度収束するものの実行端末のスペックに影響される
22. どっちを見るのが良いのか？🤔
23. 計測の知識 【結論】：両方見る（ケースで使い分ける） リアルユーザーモニタリング（フィールドデータ） • Core Web Vitals改善の成果を見るとき • 実ユーザーの体験を観測するとき 合成モニタリング（ラボデータ） • 条件を変えて計測するとき • 改善施策の検証をするとき
24. どう改善するのか 目的を明確にする 例）SEOのためにCore Web Vitalsを全て良好にする まずは目的・目標を定義する 1 計測して現状を把握する 2 指標ごとの目標を決める 例）LCP: 2.5s, FID: 100ms, CLS: 0.1 3
25. その理由 めちゃくちゃ上下幅がある → どの指標で変化したのかわからない 正しい目標設定 指標ごとに設定する 指標ごとの目標 目標をPSIスコアで置くことはオススメしない😡
26. 指標ごとの目標 Core Web Vitalsで置く場合
27. 指標ごとの目標 Core Web Vitalsで置く場合 ところでLCPってなに...？🤔
28. 指標ごとの目標 指標の説明 LCP Largest Contentful Paint 最大の画像 or テキストが表示されるまでの時間
29. 指標ごとの目標 指標の説明 ユーザーの操作から処理を開始できるまでの時間 FID First Input Delay
30. 指標ごとの目標 指標の説明 CLS Cumulative Layout Shift 予期しないレイアウト移動量の合計
31. 指標ごとの目標 FCP First Contentful Paint コンテンツの一部が画面に表示されるまでの時間 指標の説明
32. 指標ごとの目標 指標の説明 TBT Total Blocking Time メインスレッドがブロックされた時間の合計
33. どう改善するのか 改善サイクルを回す 1. 改善したい指標を決める 2. 改善の仮説を立てる 3. 仮説を検証する 4. 実装して再検証、リリース 5. 計測・記録する
34. どう改善するのか 改善サイクルを回す 1. 改善したい指標を決める 2. 改善の仮説を立てる 3. 仮説を検証する 4. 実装して再検証、リリース 5. 計測・記録する LCP 画像サイズが大きすぎる 画像のリクエストをブロック webp化 / srcset属性を使う PSIなど (自動化を推薦)
35. 実演✊
36. どう改善するのか 改善サイクルを回す 1. 改善したい指標を決める 2. 改善の仮説を立てる 3. 仮説を検証する 4. 実装して再検証、リリース 5. 計測・記録する LCP 画像サイズが大きすぎる 画像のリクエストをブロック webp化 / srcset属性を使う PSIなど (自動化を推薦)
37. どう改善するのか 改善サイクルを回す 1. 改善したい指標を決める 2. 改善の仮説を立てる 3. 仮説を検証する 4. 実装して再検証、リリース 5. 計測・記録する LCP 画像サイズが大きすぎる 画像のリクエストをブロック webp化 / srcset属性を使う PSIなど (自動化を推薦) どうやって決めた？ 🤔
38. 【方法①】 PSIの「診断」を見る 【方法②】web.devの指標別改善方法ページを見る 前提として... どちらも具体的にはわからない事が多い → 指標計測のタイミングやシステムの状態を見て考えよう！ どう改善するのか 実施する施策の選び方
39. 【方法①】 PSIの「診断」を見る 気をつけること ある程度正確なものの過信は禁物 → 言われたとおりにしても全然指標が改善しないことがある なので仮説検証をしっかりやること！ どう改善するのか 実施する施策の選び方 ①
40. 【方法②】web.devの指標別改善方法ページを見る 決め方例 1. LCPを改善したい 2. https://web.dev/optimize-lcp/ を見る 3. 「リソースのローディング」が影響してそう（仮説） Google監修だから 正確＆自動翻訳で読みやすいため最高の情報源 どう改善するのか 実施する施策の選び方
41. どう改善するのか まとめ 1. 目的を明確にする 2. 計測して現状を把握する 3. 指標ごとの目標を決める 1. 改善したい指標を決定 2. 改善の仮説を立てる 3. 仮説を検証する 4. 実装して再検証 5. 計測・記録する ① 目的・目標を決める ② 改善サイクルを回す
42. 本日お話すること（≒ゴール） 1. （Why）なぜパフォーマンスを改善するべきなのか 2. （How）どのように改善すればよいのか 3. （How事例）どう改善したのか
43. 10個以上やってきた施策の中で効果的かつ汎用的なものを紹介 1. CLSの改善 2. ファーストパーティJSの最適化 3. 要素の非同期読み込み どう改善したのか 改善施策3選 ※ そのまま横展開は❌ 実装先でちゃんと検証⭕
44. やることは単純！ 1. Lighthouseでレイアウトシフトしている要素を調べる 2. 修正する（widthとheightを設定する） ただし、そのままだとレスポンシブしなくなる ＞　CSSで「max-width:100%」「height:auto」を設定 ＞　これによりaspect-ratioが設定される どう改善したのか ① CLS改善
45. 修正箇所の見つけ方実演💪 https://s.kakaku.com/mobile_data/sim/
46. どう改善したのか やったことは３つ 1. 未使用JSの削除 2. scriptタグのレンダリングブロック防止 3. ページや要素に合わせた動的読み込み（Code Splitting） ② ファーストパーティJSの最適化 改善する指標 FCP / LCP / TBT / TTI
47. 1. 未使用JSの削除 どう改善したのか ② ファーストパーティJSの最適化 Chromeの「Coverage」で未使用処理を発見できる！ が、結局は地道な検証が必要（テストコードがあればやりやすい）
48. Chrome - Coverageの見方 処理を通ったかで色が変わる ファイルごとのカバレッジ JSだけでなくCSSも見れます
49. • scriptの属性 Defer or Async を使う • 並行で読み込まれ、後で実行される 使い分け方 • DOMの読み込みを待ちたい　→　Defer • 読み込み後すぐ実行OK（DOMに依存しない） →　Async どう改善したのか ② ファーストパーティJSの最適化 2. scriptタグのレンダリングブロック防止
50. どう改善したのか ② ファーストパーティJSの最適化 2. ページや要素に合わせた動的読み込み（Code Splitting） 要素の有無でJSを動的に読み込ませるために、 • 特定要素（タブコンポーネントなど）専用のJSを分割 • 要素があるかチェック、存在するときにDynamic Import import関数を使えば Webpack SplitChunksPlugin がいい感じにやってくれる ※ webpack ≧ 4に限る
51. どう改善したのか ② ファーストパーティJSの最適化 2. ページや要素に合わせた動的読み込み（Code Splitting） この実装で、 • toggleAccordionが別ファイルに分割 • 「.js-accordion」が存在するときのみ 読み込まれる JS本体のコードが減り、 　　　　　　FCPやTBTが改善
52. どう改善したのか ③ 要素の非同期読み込み 影響の大きいスクリプトを非同期で読み込ませる 改善する指標 FCP / LCP / TBT / TTI 例）TwitterウィジェットのJSなど
53. ご清聴ありがとうございました！