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

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

Transcript

1. 平野 耀介
   実践！パフォーマンス改善
   2021年 07月 28日
   

   View Slide

2. なぜ僕が話すのか？
   

   View Slide

3. 担当PJにおける改善成果
   ● Core Web VitalsがPC / SP全て良好に
   ● PSIが15程度から 60〜80に
   

   View Slide

4. 本会の１番の動機
   

   View Slide

5. 同じ苦労をしないでほしい😭😭
   

   View Slide

6. 本日お話すること（≒ゴール）
   1. （Why）なぜパフォーマンスを改善するべきなのか
   2. （How）どのように改善すればよいのか
   3. （How事例）どう改善したのか
   

   View Slide

7. 本日お話すること（≒ゴール）
   1. （Why）なぜパフォーマンスを改善するべきなのか
   2. （How）どのように改善すればよいのか
   3. （How事例）どう改善したのか
   

   View Slide

8. なぜ改善するべきか
   【結論】２つの事業的メリットがあるから
   1. SEO
   2. ユーザー体験改善による収益性（≒離脱率, CVR）の向上
   

   View Slide

9. 2018年7月から読み込み速度がランキング要因に
   2021年6月からコアウェブバイタルがランキング要因に
   つまり、ページパフォーマンスはSEOに直接的な影響がある
   ※どちらも同点決勝の基準程度の重み
   → 当然ながら関連性やコンテンツ品質などのが重み大
   なぜ改善するべきか
   1. SEOとの関連性
   

   View Slide

10. なぜ改善するべきか
    Googleいわく、
    表示速度: 1秒 → 3秒　直帰率: 32%上昇
    表示速度: 1秒 → 5秒　直帰率: 90%上昇
    Pinterest
    待ち時間を40%削減　→　SEOの流入とログイン率が15%向上⤴
    > 参照: Pinterest - Driving user growth with performance improvements
    2. 収益性との関連性
    

    View Slide

11. なぜ改善するべきか
    Googleいわく、
    表示速度: 1秒 → 3秒　直帰率: 32%上昇
    表示速度: 1秒 → 5秒　直帰率: 90%上昇
    Pinterest
    待ち時間を40%削減　→　SEOの流入とログイン率が15%向上⤴
    > 参照: Pinterest - Driving user growth with performance improvements
    2. 収益性との関連性
    CVR ⤴
    離脱率 ⤵
    

    View Slide

12. なぜ改善するべきか
    パフォーマンス改善をする理由は２つの事業メリットのため
    1. SEO
    2. ユーザー体験改善による収益性向上（離脱率⤵, CVR⤴）
    その他のメリット
    ● リクエスト量の削減
    ● ユーザー体験向上
    まとめ
    

    View Slide

13. 本日お話すること（≒ゴール）
    1. （Why）なぜパフォーマンスを改善するべきなのか
    2. （How）どのように改善すればよいのか
    3. （How事例）どう改善したのか
    

    View Slide

14. どう改善するのか
    目的を明確にする
    例）SEOのためにCore Web Vitalsを全て良好にする
    まずは目的・目標を定義する
    1
    計測して現状を把握する
    2
    指標ごとの目標を決める
    例）LCP: 2.5s, FID: 100ms, CLS: 0.1
    3
    

    View Slide

15. どう改善するのか
    目的を明確にする
    例）SEOのためにCore Web Vitalsを全て良好にする
    まずは目的・目標を定義する
    1
    計測して現状を把握する
    2
    指標ごとの目標を決める
    例）LCP: 2.5s, FID: 100ms, CLS: 0.1
    3
    

    View Slide

16. 計測してみよう！💪
    

    View Slide

17. 見なくていい
    PSIの読み方
    

    View Slide

18. フィールドデータ
    または
    リアルユーザーモニタリング
    (Real User Monitoring)
    PSIの読み方
    

    View Slide

19. 計測の知識
    実ユーザーの環境で計測する方法
    ● Chrome UX Reports
    ● Search Console
    ● NewRelic Browser
    Googleの呼び方
    フィールドデータ
    Chrome UX Report
    Search Console
    計測方法① リアルユーザーモニタリング（RUM）
    

    View Slide

20. ラボデータ
    または
    合成モニタリング
    (Synthetic Monitoring)
    

    View Slide

21. 計測の知識
    可能な限り環境の一貫性を保ち計測する方法
    ● PageSpeed Insights
    ● Webpagetest
    ● Lighthouse (※1)
    Googleの呼び方
    ラボデータ
    計測方法① 合成モニタリング (Synthetic Monitoring)
    (※1) ある程度収束するものの実行端末のスペックに影響される
    

    View Slide

22. どっちを見るのが良いのか？🤔
    

    View Slide

23. 計測の知識
    【結論】：両方見る（ケースで使い分ける）
    リアルユーザーモニタリング（フィールドデータ）
    ● Core Web Vitals改善の成果を見るとき
    ● 実ユーザーの体験を観測するとき
    合成モニタリング（ラボデータ）
    ● 条件を変えて計測するとき
    ● 改善施策の検証をするとき
    

    View Slide

24. どう改善するのか
    目的を明確にする
    例）SEOのためにCore Web Vitalsを全て良好にする
    まずは目的・目標を定義する
    1
    計測して現状を把握する
    2
    指標ごとの目標を決める
    例）LCP: 2.5s, FID: 100ms, CLS: 0.1
    3
    

    View Slide

25. その理由
    めちゃくちゃ上下幅がある
    → どの指標で変化したのかわからない
    正しい目標設定
    指標ごとに設定する
    指標ごとの目標
    目標をPSIスコアで置くことはオススメしない😡
    

    View Slide

26. 指標ごとの目標
    Core Web Vitalsで置く場合
    

    View Slide

27. 指標ごとの目標
    Core Web Vitalsで置く場合
    ところでLCPってなに...？🤔
    

    View Slide

28. 指標ごとの目標
    指標の説明
    LCP
    Largest Contentful Paint
    最大の画像 or テキストが表示されるまでの時間
    

    View Slide

29. 指標ごとの目標
    指標の説明
    ユーザーの操作から処理を開始できるまでの時間
    FID
    First Input Delay
    

    View Slide

30. 指標ごとの目標
    指標の説明
    CLS
    Cumulative Layout Shift
    予期しないレイアウト移動量の合計
    

    View Slide

31. 指標ごとの目標
    FCP
    First Contentful Paint
    コンテンツの一部が画面に表示されるまでの時間
    指標の説明
    

    View Slide

32. 指標ごとの目標
    指標の説明
    TBT
    Total Blocking Time
    メインスレッドがブロックされた時間の合計
    

    View Slide

33. どう改善するのか
    改善サイクルを回す
    1. 改善したい指標を決める
    2. 改善の仮説を立てる
    3. 仮説を検証する
    4. 実装して再検証、リリース
    5. 計測・記録する
    

    View Slide

34. どう改善するのか
    改善サイクルを回す
    1. 改善したい指標を決める
    2. 改善の仮説を立てる
    3. 仮説を検証する
    4. 実装して再検証、リリース
    5. 計測・記録する
    LCP
    画像サイズが大きすぎる
    画像のリクエストをブロック
    webp化 / srcset属性を使う
    PSIなど (自動化を推薦)
    

    View Slide

35. 実演✊
    

    View Slide

36. どう改善するのか
    改善サイクルを回す
    1. 改善したい指標を決める
    2. 改善の仮説を立てる
    3. 仮説を検証する
    4. 実装して再検証、リリース
    5. 計測・記録する
    LCP
    画像サイズが大きすぎる
    画像のリクエストをブロック
    webp化 / srcset属性を使う
    PSIなど (自動化を推薦)
    

    View Slide

37. どう改善するのか
    改善サイクルを回す
    1. 改善したい指標を決める
    2. 改善の仮説を立てる
    3. 仮説を検証する
    4. 実装して再検証、リリース
    5. 計測・記録する
    LCP
    画像サイズが大きすぎる
    画像のリクエストをブロック
    webp化 / srcset属性を使う
    PSIなど (自動化を推薦)
    どうやって決めた？
    🤔
    

    View Slide

38. 【方法①】 PSIの「診断」を見る
    【方法②】web.devの指標別改善方法ページを見る
    前提として...
    どちらも具体的にはわからない事が多い
    → 指標計測のタイミングやシステムの状態を見て考えよう！
    どう改善するのか
    実施する施策の選び方
    

    View Slide

39. 【方法①】 PSIの「診断」を見る
    気をつけること
    ある程度正確なものの過信は禁物
    → 言われたとおりにしても全然指標が改善しないことがある
    なので仮説検証をしっかりやること！
    どう改善するのか
    実施する施策の選び方 ①
    

    View Slide

40. 【方法②】web.devの指標別改善方法ページを見る
    決め方例
    1. LCPを改善したい
    2. https://web.dev/optimize-lcp/ を見る
    3. 「リソースのローディング」が影響してそう（仮説）
    Google監修だから 正確＆自動翻訳で読みやすいため最高の情報源
    どう改善するのか
    実施する施策の選び方
    

    View Slide

41. どう改善するのか
    まとめ
    1. 目的を明確にする
    2. 計測して現状を把握する
    3. 指標ごとの目標を決める
    1. 改善したい指標を決定
    2. 改善の仮説を立てる
    3. 仮説を検証する
    4. 実装して再検証
    5. 計測・記録する
    ① 目的・目標を決める ② 改善サイクルを回す
    

    View Slide

42. 本日お話すること（≒ゴール）
    1. （Why）なぜパフォーマンスを改善するべきなのか
    2. （How）どのように改善すればよいのか
    3. （How事例）どう改善したのか
    

    View Slide

43. 10個以上やってきた施策の中で効果的かつ汎用的なものを紹介
    1. CLSの改善
    2. ファーストパーティJSの最適化
    3. 要素の非同期読み込み
    どう改善したのか
    改善施策3選
    ※ そのまま横展開は❌ 実装先でちゃんと検証⭕
    

    View Slide

44. やることは単純！
    1. Lighthouseでレイアウトシフトしている要素を調べる
    2. 修正する（widthとheightを設定する）
    ただし、そのままだとレスポンシブしなくなる
    ＞　CSSで「max-width:100%」「height:auto」を設定
    ＞　これによりaspect-ratioが設定される
    どう改善したのか
    ① CLS改善
    

    View Slide

45. 修正箇所の見つけ方実演💪
    https://s.kakaku.com/mobile_data/sim/
    

    View Slide

46. どう改善したのか
    やったことは３つ
    1. 未使用JSの削除
    2. scriptタグのレンダリングブロック防止
    3. ページや要素に合わせた動的読み込み（Code Splitting）
    ② ファーストパーティJSの最適化
    改善する指標
    FCP / LCP / TBT / TTI
    

    View Slide

47. 1. 未使用JSの削除
    どう改善したのか
    ② ファーストパーティJSの最適化
    Chromeの「Coverage」で未使用処理を発見できる！
    が、結局は地道な検証が必要（テストコードがあればやりやすい）
    

    View Slide

48. Chrome - Coverageの見方
    処理を通ったかで色が変わる
    ファイルごとのカバレッジ
    JSだけでなくCSSも見れます
    

    View Slide

49. ● scriptの属性 Defer or Async を使う
    ● 並行で読み込まれ、後で実行される
    使い分け方
    ● DOMの読み込みを待ちたい　→　Defer
    ● 読み込み後すぐ実行OK（DOMに依存しない） →　Async
    どう改善したのか
    ② ファーストパーティJSの最適化
    2. scriptタグのレンダリングブロック防止
    

    View Slide

50. どう改善したのか
    ② ファーストパーティJSの最適化
    2. ページや要素に合わせた動的読み込み（Code Splitting）
    要素の有無でJSを動的に読み込ませるために、
    ● 特定要素（タブコンポーネントなど）専用のJSを分割
    ● 要素があるかチェック、存在するときにDynamic Import
    import関数を使えば Webpack SplitChunksPlugin がいい感じにやってくれる
    ※ webpack ≧ 4に限る
    

    View Slide

51. どう改善したのか
    ② ファーストパーティJSの最適化
    2. ページや要素に合わせた動的読み込み（Code Splitting）
    この実装で、
    ● toggleAccordionが別ファイルに分割
    ● 「.js-accordion」が存在するときのみ
    読み込まれる
    JS本体のコードが減り、
    　　　　　　FCPやTBTが改善
    

    View Slide

52. どう改善したのか
    ③ 要素の非同期読み込み
    影響の大きいスクリプトを非同期で読み込ませる
    改善する指標
    FCP / LCP / TBT / TTI
    例）TwitterウィジェットのJSなど
    

    View Slide

53. ご清聴ありがとうございました！
    

    View Slide