Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの
Search
Recruit
PRO
June 29, 2021
Technology
5
4.5k
タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの
20210629_Node学園 36時限目 での前田の講演資料になります
Recruit
PRO
June 29, 2021
Tweet
Share
More Decks by Recruit
See All by Recruit
Balancing Revenue Goals and Off-Policy Evaluation Performance in Coupon Allocation
recruitengineers
PRO
1
13
Flutterによる 効率的なAndroid・iOS・Webアプリケーション開発の事例
recruitengineers
PRO
0
120
VPC Traffic Mirroring とOSS を利⽤した ネットワークフォレンジック基盤の構築・運⽤
recruitengineers
PRO
1
44
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
1.1k
リクルート流データ基盤塾~鶴谷と学ぶ~
recruitengineers
PRO
5
250
『SUUMO』 スマホサイト デザインリニューアルへの挑戦
recruitengineers
PRO
5
340
『リクルートダイレクトスカウト』 のリニューアルから振り返る: ビジョンドリブンの可能性
recruitengineers
PRO
3
310
負債あるモノリスのオブザーバビリティに組織で向き合う
recruitengineers
PRO
9
400
あなたの知らないiOS開発の世界
recruitengineers
PRO
4
330
Other Decks in Technology
See All in Technology
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
180
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
160
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
880
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
AWS Media Services 最新サービスアップデート 2024
eijikominami
0
200
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.5k
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
6
660
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
TypeScript、上達の瞬間
sadnessojisan
46
13k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Ruby is Unlike a Banana
tanoku
97
11k
How to Ace a Technical Interview
jacobian
276
23k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Typedesign – Prime Four
hannesfritz
40
2.4k
Scaling GitHub
holman
458
140k
Writing Fast Ruby
sferik
627
61k
What's in a price? How to price your products and services
michaelherold
243
12k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Transcript
タウンワークにおけるCore Web Vitals改善施策とそれにより見え てきたもの 2021/6/28 Node学園 36時限目 takumo maeda
自己紹介 前田 琢百 Maeda Takumo 株式会社リクルート プロダクト統括本部 プロダクト開発統括室 プロダクトディベロップメント室 HR領域プロダ クトディベロップメントユニット HR領域エンジニアリング部 HRプロダクト開発2グループ(長い タウンワーク Webエンジニア(主にバックエンド、フロントエンドも時々) 2016新卒。HR領域サービスネイティブアプリ開発
→バッチ改善とかとか→Web開発(エンハンスチーム , オフショ ア開発検証 とかとか)→遊撃部隊としてCore Web Vitals改善主導
Core Web Vitalsおさらい • LCP(Largest Contentful Paint) ユーザーがページで最も有意義なコンテンツをどのくらい早く見ることができるかを表す。感覚的な読み込 みスピードを測定し、ページ読み込みタイムラインにおいてページの主要コンテンツが読み込まれたと思わ れるタイミングを指す。
• FID(First Input Delay) 最初の入力までの遅延を表す。応答性を測定して、ユーザーが最初にページを操作しようとする場合に感 じるエクスペリエンスを定量化する。 • CLS(Cumulative Layout Shift) ページがどのくらい安定しているように感じられるかを表する。視覚的な安定性を測定し、表示されるページ コンテンツにおける予期しないレイアウトのずれの量を定量化する。 ※参考 ユーザー体験を表す重要な指標として一旦この 3つを定義するよということ。 主要コンテンツが早く表示され (LCP)、すぐにページを操作でき( FID)、予期せぬカクツキとかない( CLS)ページが至高だよね ということ。
本日の話:タウンワークにおけるWebパフォーマンス改善 背景 GoogleがCore Web Vitalsを2021/5からランキングシステムに組み込むと 発表。(最新発表では 6月中旬から段階的に取り入れる) 改善期間 2021 3月~4月(計測含む)
改善対象 タウンワーク:アルバイト・社員求人サイト 改善スコープ 上記期間で改善リリースまで行える ROIの高いと見込んだ施策 クライアント カスタマー アルバイト探し 働き手探し
本日の話:タウンワークにおけるWebパフォーマンス改善 改善対象画面 タウンワークにおける主要な画面をピック 地方選択 エリアトップ 求人一覧 求人詳細 求人タイトル 求人詳細情報
まずは現状のパフォーマンス計測してみた
計測データ種類 • ラボデータ - 一連の固定されたネットワーク条件で 1 台の端末でページ読み込みをシミュレートしたデータ - パフォーマンスの問題のデバッグに役立つ -
Lighthouseはモバイル ネットワーク上のミッドレンジ端末(Moto G4)でページ読み込みをシミュレートした 結果を表示している • フィールドデータ - 実際のさまざまな端末やネットワークの条件におけるユーザーから匿名で送られたパフォーマンス データ - 過去28日間の収集期間をもとに算出 - ランキング要因となるのはこちら
計測(フィールドデータ) 地方選択 エリアトップ 求人一覧 求人詳細
計測(フィールドデータ) 地方選択 エリアトップ 求人一覧 求人詳細 ぱっと見の課題仮説(全画面横断で) FID, CLSに関してはそこまで問題なさそう。 FCP, LCPが改善余地ありそう。
→ネットワークI/Oによるオーバーヘッドがかかっていないか見てみる
ネットワークI/Oといえば • Web Font • 3rd Party Resources • Unused
JS/CSS • Image • その他(サーバレスポンス、キャッシュ制御等)
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources •
Unused JS/CSS • Image • その他(サーバレスポンス、キャッシュ制御等)
3rd Party Resources(Request Mapを使用) リクルート別サービスの状態と比べて必要最低限な状態 リクルートの別サービス
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS • Image • その他(サーバレスポンス、キャッシュ制御等)
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS • Image • その他(サーバレスポンス、キャッシュ制御等) Unused JS/CSS, Image, その他はChrome DevToolsを使用して計測
Unused JS/CSS 全画面共通で呼ばれている CSS(JSも)が存在し、 Unusedな割合が高い。
日々のフロントエンド開発改善(ボーイスカウトルール的に実施) 共通JS(CSSも同様) 画面ごとにwebpackでbundleされた1つのjs 日々の開発改善にて Unusedなものを減らす努力は行っている
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施 策対象から除外。 • Image • その他(サーバレスポンス、キャッシュ制御等)
計測(Chrome DevToolsにてシミュレート) ハイスペックな開発端末の場合、性能が良くてボトルネック が見えづらい可能性があるので、NetworkをFast3Gに、 CPUを4倍低速で計測
Image(一覧画面においても) 自分の開発端末だと性能が良くてボトルネックが見えづら い可能性があるので、NetworkをFast3Gに、CPUを4倍低 速で計測 First Viewに関係ない画像を最初から呼びにいっている → `loading=lazy`を付与し遅延読み込みさせることで初期 表示の改善の見込み
あとは単純に画像サイズを小さくしたら読み込み速度改善するはずだが、そもそも現状画像サイズの最適化を行 うプロセスが開発フローに存在していなかった。 フロントエンドエンジニアが画像サイズ小さくして実装することも。 Image 案件起案 デザイン作 成 フロントエンド実 装 デザインレ
ビュー
あとは単純に画像サイズを小さくしたら読み込み速度改善するはずだが、そもそも現状画像サイズの最適化を行 うプロセスが開発フローに存在していなかった。 フロントエンドエンジニアが画像サイズ小さくして実装することも。 Image 案件起案 デザイン作 成 フロントエンド実 装 デザインレ
ビュー ということもあり、再度各画像のサイズ最適化できそう(漏れがありそう) だったので施策リストに追加
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施 策対象から除外。 • Image → 以下の施策を改善対象に追加 1. 遅延読み込み 2. サイズ最適化 • その他(サーバレスポンス、キャッシュ制御等)
キャッシュバスティング用のクエリ( v=の部分)をつけているものに対して max-age=0となっており、同じバージョン のものでも毎回サーバリクエストが発生してしまっている その他(サーバレスポンス、キャッシュ制御等)
現状はapacheのmod_deflateモジュールによるgzip圧縮を行っているが、 brotli圧縮にすることで転送量の削減 が見込まれる。 その他(サーバレスポンス、キャッシュ制御等) ex) トップページ index.html index.html 313.8KB index.html.gz
40.0KB index.html.br 27.9KB
後続処理をブロックしている css読み込み(全画面で呼ばれている)を発見 その他(サーバレスポンス、キャッシュ制御等) mp-include-sp.css内に mp-include-sp.css mp-include-sp-shain.css
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施 策対象から除外。 • Image → 以下の施策を改善対象に追加 1. 遅延読み込み 2. サイズ最適化 • その他(サーバレスポンス、キャッシュ制御等) →以下の施策を改善対象に追加 1. キャッシュ制御 2. Brotli圧縮 3. css @import削除
ネットワークI/Oといえば • Web Font →タウンワークでは未使用 • 3rd Party Resources →必要最低限の使用のため改善対象から除外
• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施 策対象から除外。 • Image → 以下の施策を改善対象に追加 1. 遅延読み込み 2. サイズ最適化 • その他(サーバレスポンス、キャッシュ制御等) →以下の施策を改善対象に追加 1. キャッシュ制御 2. Brotli圧縮 3. css @import削除 今回の施策対象としては2ヶ月弱で実施できる施策ということで以下の対応を行なった (各対象画面にて)
施策の実施
対象ファイル洗い出し(例:求人一覧画面) Image:遅延読み込み
初期読み込みからFirst Viewに関係ない画像が消えていることを確認(例:求人一覧画面) Image:遅延読み込み ここらへん
画像サイズを最適化した結果: 20~40%ほど画像サイズ削減 Image:サイズ最適化 before after
キャッシュバスティング用のクエリ( v=の部分)がついている資材に対して max-age=0 → max-age=1年に変更 apache conf修正 キャッシュ制御
JS/CSSにおいてキャッシュ制御されることで読み込み速度改善 キャッシュ制御
標準モジュールとして使用できるわけではなく、 apacheの再コンパイルが必要であり、サービス影響が大きくス コープから除外 Brotli圧縮
importしていたスタイルを親 cssのmp-include-sp.cssにマージ css @import削除 mp-include-sp.css mp-include-sp-shain.css ここのブロックがなくなる
施策実施後の計測
施策実施後の計測データ • フィールドデータ • Navigation Timing APIを使用したページロード時間実測値
計測(フィールドデータ) 地方選択 求人一覧
計測(フィールドデータ) エリアトップ 求人詳細
計測(Navigation Timing APIによる実測値) https://developer.mozilla.org/ja/docs/Web/API/Navigation_timing_API ほぼすべてのブラウザにて使用可能
計測(Navigation Timing APIによる実測値) 雑実装でAdobe Analyticsのページ描画のタイミングで一緒に送っているので、全てのロードが終わる前に送るよ うにはなっているものの、読み込み前半のページロード速度は見ることができる。 取得データをBig Queryにて確認。
計測(Navigation Timing APIによる実測値) 20210407 キャッシュ制御 施策 詳細画面 Image 施策 20210414
一覧画面 Image 施策 エリアトップ画面 Image 施策 cssの@import削除 右記のグラフを見ると施策効果がわかる 各画面0.2sほど 縦軸は実測のページロード時間の中央値 ※正確にはBig Queryにて PERCENTILE_CONT(x, 0.5) OVER() AS median として算出
計測(Navigation Timing APIによる実測値) 全ユーザーの実測値のグラフ(縦軸 UU, 横軸ページロード時間)を見ても山が左に動いていることがわかる 求人一覧 求人詳細 4/5 4/16
サマリ(改善結果) - 対象画面の3/4はFCP, LCPにて20~30%ほど速度改善できた - 詳細画面においても FCP, LCPともにグリーンの割合を増やすことができた - 基本的に早いロードの人をより早くというより、遅かった人を早くした
- Navigation Timing APIの実測値を見ても今回の施策が正しくページロード速度の向上に寄与していること が確認できた
サマリ(改善により見えてきたもの & 今後の展望) - これまでタウンワークではさまざまな改善活動が行われてきたのもあって、大きな粒度の改善をやらなけれ ばいけないみたいなことがなかったため、焦らずに小さい粒度で改善活動を行なうことができた。未来に繋 げるために日々のパフォーマンス改善していく文化づくりの重要性 を感じた。 - akamai
CDN導入 - 一覧画面の画像はhttp2対応 - 2年前のフロントエンド改善 - webpack等導入 - サーバ側でのレコメンドロジック削除 - etc https://codezine.jp/article/detail/11445 https://codezine.jp/article/detail/11570
サマリ(改善により見えてきたもの & 今後の展望) - 画像サイズの最適化をプロセスのどこでやるか曖昧だったものを明確にすることができた。また、エンジニ ア・SEOチームだけでなく、デザイナーや企画側にもパフォーマンス改善の重要性を認知してもらうことがで きつつあるので継続して改善活動を推進していきたい。 - 事業KPIにパフォーマンスがどう影響しているかというところも計測していく。 (現状他ABテストが常時走っており計測できていなかった
Core Web Vitalsによるビジネスインパクトの他会社の事例 https://developers-jp.googleblog.com/2021/05/core-web-vitals.html