タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの

タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの 2021/6/28 Node学園 36時限目 takumo maeda

自己紹介前田琢百 Maeda Takumo 株式会社リクルート　プロダクト統括本部　プロダクト開発統括室　プロダクトディベロップメント室　ＨＲ領域プロダクトディベロップメントユニット　ＨＲ領域エンジニアリング部　ＨＲプロダクト開発２グループ（長いタウンワーク 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 • その他（サーバレスポンス、キャッシュ制御等）

• Unused JS/CSS • Image • その他（サーバレスポンス、キャッシュ制御等） Unused JS/CSS, Image, その他はChrome DevToolsを使用して計測

Unused JS/CSS 全画面共通で呼ばれている CSS（JSも）が存在し、 Unusedな割合が高い。

日々のフロントエンド開発改善（ボーイスカウトルール的に実施）共通JS（CSSも同様）画面ごとにwebpackでbundleされた1つのjs 日々の開発改善にて Unusedなものを減らす努力は行っている

• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施策対象から除外。 • Image • その他（サーバレスポンス、キャッシュ制御等）

計測（Chrome DevToolsにてシミュレート）ハイスペックな開発端末の場合、性能が良くてボトルネックが見えづらい可能性があるので、NetworkをFast3Gに、 CPUを4倍低速で計測

Image（一覧画面においても）自分の開発端末だと性能が良くてボトルネックが見えづらい可能性があるので、NetworkをFast3Gに、CPUを4倍低速で計測 First Viewに関係ない画像を最初から呼びにいっている → `loading=lazy`を付与し遅延読み込みさせることで初期表示の改善の見込み

あとは単純に画像サイズを小さくしたら読み込み速度改善するはずだが、そもそも現状画像サイズの最適化を行うプロセスが開発フローに存在していなかった。フロントエンドエンジニアが画像サイズ小さくして実装することも。 Image 案件起案デザイン作成フロントエンド実装デザインレ
ビュー

あとは単純に画像サイズを小さくしたら読み込み速度改善するはずだが、そもそも現状画像サイズの最適化を行うプロセスが開発フローに存在していなかった。フロントエンドエンジニアが画像サイズ小さくして実装することも。 Image 案件起案デザイン作成フロントエンド実装デザインレ
ビューということもあり、再度各画像のサイズ最適化できそう（漏れがありそう）だったので施策リストに追加

• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施策対象から除外。 • Image → 以下の施策を改善対象に追加 1. 遅延読み込み 2. サイズ最適化 • その他（サーバレスポンス、キャッシュ制御等）

キャッシュバスティング用のクエリ（ v=の部分）をつけているものに対して max-age=0となっており、同じバージョンのものでも毎回サーバリクエストが発生してしまっているその他（サーバレスポンス、キャッシュ制御等）

現状はapacheのmod_deﬂateモジュールによる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

• Unused JS/CSS → 日々改善活動を行なっているかつ、今回 1ヶ月弱での改修が必要な中、全画面影響があることを鑑み施策対象から除外。 • Image → 以下の施策を改善対象に追加 1. 遅延読み込み 2. サイズ最適化 • その他（サーバレスポンス、キャッシュ制御等） →以下の施策を改善対象に追加 1. キャッシュ制御 2. Brotli圧縮 3. css @import削除

• 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

タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの

タウンワークにおけるCore Web Vitals改善施策とそれにより見えてきたもの

More Decks by Recruit

Other Decks in Technology

Featured

Transcript