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.6k
タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの
20210629_Node学園 36時限目 での前田の講演資料になります
Recruit
PRO
June 29, 2021
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
9
2.5k
Curiosity & Persistence
recruitengineers
PRO
2
140
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
320
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
130
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
160
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
210
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
120
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
130
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
120
Other Decks in Technology
See All in Technology
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
toma_sm
0
150
Cursor AgentによるパーソナルAIアシスタント育成入門―業務のプロンプト化・MCPの活用
os1ma
15
5.3k
Running JavaScript within Ruby
hmsk
3
370
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
1
380
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
0
280
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
12
8.4k
Linuxのパッケージ管理とアップデート基礎知識
go_nishimoto
0
470
PicoRabbit: a Tiny Presentation Device Powered by Ruby
harukasan
PRO
2
250
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
130
2025-04-24 "Manga AI Understanding & Localization" Furukawa Arata (CyberAgent, Inc)
ornew
2
260
白金鉱業Meetup_Vol.18_生成AIはデータサイエンティストを代替するのか?
brainpadpr
3
150
新卒エンジニアがCICDをモダナイズしてみた話
akashi_sn
2
260
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Building Applications with DynamoDB
mza
94
6.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building an army of robots
kneath
304
45k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
9
760
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Cost Of JavaScript in 2023
addyosmani
49
7.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
29
5.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
13
1.4k
How to train your dragon (web standard)
notwaldorf
90
6k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Unsuck your backbone
ammeep
670
57k
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