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
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
910
リクルート流データ基盤塾~鶴谷と学ぶ~
recruitengineers
PRO
5
140
『SUUMO』 スマホサイト デザインリニューアルへの挑戦
recruitengineers
PRO
5
280
『リクルートダイレクトスカウト』 のリニューアルから振り返る: ビジョンドリブンの可能性
recruitengineers
PRO
3
270
負債あるモノリスのオブザーバビリティに組織で向き合う
recruitengineers
PRO
9
380
あなたの知らないiOS開発の世界
recruitengineers
PRO
4
310
大規模プロダクトにおける組織作りと技術ポートフォリオマネジメント
recruitengineers
PRO
4
440
OR学会2024秋_短期収益と将来のオフ方策評価性能を考慮したクーポン割当方策混合比の決定
recruitengineers
PRO
5
660
リクルート新人研修2024 テキスト生成AI活用
recruitengineers
PRO
12
1k
Other Decks in Technology
See All in Technology
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
220
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
soudai
24
6.8k
Jr. Championsになって、強く連携しながらAWSをもっと使いたい!~AWSに対する期待と行動~
amixedcolor
0
190
2024-10-30-reInventStandby_StudyGroup_Intro
shinichirokawano
1
640
[AWS JAPAN 生成AIハッカソン] Dialog の紹介
yoshimi0227
0
150
物価高なラスベガスでの過ごし方
zakky
0
380
ガバメントクラウド先行事業中間報告を読み解く
sugiim
1
1.4k
10分でわかるfreeeのQA
freee
1
3.4k
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
2
100
Amazon_CloudWatch_ログ異常検出_導入ガイド
tsujiba
4
1.6k
omakaseしないための.rubocop.yml のつくりかた / How to Build Your .rubocop.yml to Avoid Omakase #kaigionrails
linkers_tech
3
740
Automated Promptingを目指すその前に / Before we can aim for Automated Prompting
rkaga
0
110
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Writing Fast Ruby
sferik
626
61k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Designing for Performance
lara
604
68k
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