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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

なぜ僕が話すのか？

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

本会の１番の動機

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

計測してみよう！💪

Slide 17

Slide 17 text

見なくていい PSIの読み方

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

実演✊

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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