タウンワークにおける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 ● その他（サーバレスポンス、キャッシュ制御等）

ネットワーク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