リクルートにおけるWebパフォーマンス改善の取り組み

Slide 1

Slide 1 text

リクルートにおける  Webパフォーマンス改善の取り組み  2019/6/3  GoogleCloudで実践する Web アプリ開発  リクルートテクノロジーズ新井智士 

Slide 2

Slide 2 text

新井智士  フロントエンドエンジニア  リクルートテクノロジーズ  アプリケーションソリューショングループ所属  現在は SUUMO でウェブアプリケーションのパフォーマンスモニタリングを中心にエンジニアの育成・フロントエンド設計開発に携わる。 

Slide 3

Slide 3 text

お話しする内容  1. リクルートでの取り組み  2. SUUMOでの性能改善の取り組み実例  - SUUMOでの取り組み方  - パフォーマンスバジェット  - 性能改善ハッカソン 

Slide 4

Slide 4 text

1. リクルートでの取り組み  ライブラリ・ツール開発  （開発効率化）  性能改善  新規開発支援・エンジニア育成 

Slide 5

Slide 5 text

1. リクルートでの取り組み  ライブラリ・ツール開発  （開発効率化）  性能改善  新規開発支援・エンジニア育成 

Slide 6

Slide 6 text

リクルートでの取り組み（性能改善）    ● パフォーマンス改善に関する勉強会開催  ● Google主催スピードハッカソン参加  期間内に最もページスピードを改善したタウンワークが優勝      ● タウンワークスピード改善ローンチ  https://codezine.jp/article/detail/11445  ● SUUMOスピードハッカソン社内実施  ● AirSHIFT性能速度改善  https://speakerdeck.com/maxmellon/reactzhi-spa-niokeru-pahuomansutiyuningu 

Slide 7

Slide 7 text

3. SUUMOでの性能改善取り組み実例 

Slide 8

Slide 8 text

SUUMOについて  ● 国内最大級の不動産情報サービス   ● 2009年スタート  （複数のプロダクトが合流） 

Slide 9

Slide 9 text

https://business.suumo.jp/welcome/chintai/index.html 2019/03 時点

Slide 10

Slide 10 text

活発なエンハンスを続けている  ● 2009年から10年の歴史あるサービス  ● 多くの機能追加開発  ● 細部にわたった使い勝手向上の取り組み    （コンテンツは最適化されていく一方で、）  → 頻繁な追加・改修の分、  　ページ表示性能低下の懸念  　機能を追加：画像、CSS、JSを追加して、、   

Slide 11

Slide 11 text

過去のWebパフォーマンス改善  たびたび改善の取り組みはされており、結果も出ている  ただし、  ● 「Webパフォーマンスを改善する案件」になっている。  ● 取り組みが属人化してしまう  → なかなか定着させられない   

Slide 12

Slide 12 text

Webパフォーマンスって（これまで）  ● サーバからの何秒でコンテンツを返せるか  ● 秒間にいくつのリクエストを扱えるか   

Slide 13

Slide 13 text

Webパフォーマンスって（現在）  ● コンテンツがリッチに  ● 低スペックな端末、通信環境（3G, 4G）  ● サーバーでのレスポンス性能だけでは不十分   

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Webパフォーマンスって（現在）  ● コンテンツがリッチに  ● 低スペックな端末、通信環境（3G, 4G）  ● サーバーでのレスポンス性能だけでは不十分    → 待ち時間の80-90%がフロントエンド 

Slide 17

Slide 17 text

Webパフォーマンスの昨今  HttpArchive.orgより  ページサイズ読み込み時間      （モバイルに関して、2016年〜３年間の中間値では）  ● ページサイズは76% の増加  ● 読み込み時間は20% の増加 

Slide 18

Slide 18 text

Webパフォーマンスの昨今  ● モバイルユーザーが重視するもの  （Google の2017年の調査報告）    https://www.awwwards.com/brainfood-mobile-performance-vol3.pdf 

Slide 19

Slide 19 text

Webパフォーマンスの昨今  ● 2018/07 Google SpeedUpdate  “Using page speed in mobile search ranking” https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html ページの速度をモバイルの検索順位に使用する  “We encourage developers to think broadly about how performance affects a user’s experience of their page and to consider a variety of user experience metrics. ” パフォーマンスがページのユーザーのエクスペリエンスにどのように  影響するかについて広く考え、さまざまなユーザーエクスペリエンス  の測定基準を検討することを開発者に推奨します。   

Slide 20

Slide 20 text

Webパフォーマンスの昨今  ● デバイス性能、通信環境、通信品質が多様化  ● ユーザーはスピードを重視している  ● パフォーマンスはユーザー体験に影響を与える    → 多くの人に利用してもらうサービスとして、  　コントロールする必要がある！ 

Slide 21

Slide 21 text

SUUMOでのアプローチ          パフォーマンス  バジェット  性能改善  ハッカソン  予防  現状の可視化・共通認識化   案件企画・設計から意識   ○  ○  維持  指標と基準を定めてアラート   ◯    改善  基準に満たないページを改善     ○  予防・維持・改善の３つの枠組みで活動 

Slide 22

Slide 22 text

SUUMOでのアプローチ                これまでの取り組みは改善から予防の流れ      パフォーマンス  バジェット  性能改善  ハッカソン  予防  現状の可視化・共通認識化   案件企画・設計から意識   ○  ○  維持  指標と基準を定めてアラート   ◯    改善  基準に満たないページを改善     ○ 

Slide 23

Slide 23 text

    パフォーマンス  バジェット  性能改善  ハッカソン  予防  現状の可視化・共通認識化   案件企画・設計から意識   ○  ○  維持  指標と基準を定めてアラート   ◯    改善  基準に満たないページを改善     ○  SUUMOでのアプローチ 

Slide 24

Slide 24 text

性能改善ハッカソン  ● パフォーマンス改善のための調査・計測・改善見立てを  １日(または短期間)で行う  ● 計測には Lighthouse を利用。 

Slide 25

Slide 25 text

性能改善ハッカソンでの手順  11:00 フリースペース集合  11:00 - 12:00 かんたんな説明など  12:00 - 18:00 作業  　　　　　　　 https://web.dev/fast  18:00 - 　　　チーム内で施策の共有・まとめ  実装内容などについて話し合う 

Slide 26

Slide 26 text

性能改善ハッカソンのポイント  ● アーキテクチャやビジネス上の制約を無視してとにかく点数を上げる！  ● 範囲を狭める（1-数ページ程度）  ● 現場の開発チームに参加してもらう 

Slide 27

Slide 27 text

性能改善ハッカソンの効果  ● パフォーマンス改善のための具体的な案件リストが短期間で手に入る  ● サービスに関する事前知識がほぼ不要になり、  業務知識の少ないメンバーでも貢献しやすい  ● （範囲が絞られているので）  普段触れない部分に積極的に手を入れることができる  ● チームの性能への意識向上  ● 性能上のボトルネックが明確になる。  コードと性能の関連性が体験できる。 

Slide 28

Slide 28 text

● Chrome DevTools  ボトルネックの調査  （network, performance, coverage）  ● Thumbor（画像変換サーバー）  画像を一つづつ変換するのは大変なことも。  変換サーバを経由させると楽  など  便利なツール紹介 

Slide 29

Slide 29 text

● 有効な施策を短期間に提案できた  ● （特定環境下で）100点まで（元の数倍のスコア）改善  ● 代表的な性能を低下させる項目  ○ 読むこむ必要のない画面外の画像  ○ アクセス解析・広告タグ  ○ 画像のサイズ、品質が過剰・最適でない形式  ○ 使用していないJavaScript、CSS など  SUUMOで実施した結果 

Slide 30

Slide 30 text

● 価値、難度、コストで評価  ● 簡単にできて効果の高いものから実施していく   → 正しく修正できていないと  　画像が見られなかったり、画面崩れが発生したり、、  即障害に繋がるためリリース前にしっかりテスト！  改善施策の適用 

Slide 31

Slide 31 text

● 売上、CVR  ● 滞在時間・ページビュー・離脱率  → 改善途中のため、引き続き計測していく！  改善の効果計測   

Slide 32

Slide 32 text

● 改善しただけだと機能追加、サービス成長に伴ってすぐに劣化してしまう！  ● パフォーマンスを維持しなければならない  → 価値のあるサービスを継続的に届ける    改善のその後 

Slide 33

Slide 33 text

SUUMOでのアプローチ          パフォーマンス  バジェット  性能改善  ハッカソン  予防  現状の可視化・共通認識化   案件企画・設計から意識   ○  ○  維持  指標と基準を定めてアラート   ◯    改善  基準に満たないページを改善     ○ 

Slide 34

Slide 34 text

パフォーマンスバジェット  (Google Developers) パフォーマンスバジェットのご紹介  https://developers-jp.googleblog.com/2019/03/blog-post_15.html  ● ウェブサイトを高速に保つために便利な考え方  ● パフォーマンスに関する予算を決めて維持  ● UX 上重要なもの、運用しやすいものを予算として定義    → これにより、ユーザー体験を一定に保つ前提で、  　機能と性能のトレードオフを可視化・説明・判断できる  　  

Slide 35

Slide 35 text

パフォーマンスバジェットでの指標  Milestone   - 読み込み・表示にかかった時間、など  Quantity （量）  - ファイルサイズ  - リクエスト数、など  Rules  - パフォーマンススコア  など    　　　　　　　　　　　　　　　　　　 https://addyosmani.com/blog/performance-budgets/    

Slide 36

Slide 36 text

SUUMOのパフォーマンスバジェット  ● SUUMOではまずレポーティングに取り入れている  ● 定期的に計測し、傾向など含めレポーティング  ● レポートは開発チーム主体で作成（リリース毎など）  ● 一定期間内でのレポートをまとめ、サマリし全体周知    → 最新の状況と施策の進捗を共有  → パフォーマンスがユーザー体験に直結するという共通認識  をビジネスサイドを含めて作る     

Slide 37

Slide 37 text

パフォーマンスバジェット  この機能を入れると検索がこんなに使いやすくなります！ 

Slide 38

Slide 38 text

パフォーマンスバジェット  この機能を入れると検索がこんなに使いやすくなります！  そうすると、実現に必要なリソースが30KB 予算オーバーです。  かわりに機能が使われるまで必要なリソースのロードを遅延させて表示性能を維持しましょう。 

Slide 39

Slide 39 text

SUUMOのパフォーマンスバジェット  読み込みの遅延の他にも、    ● ほかの機能の最適化  ● ほかの機能の削除  ● 機能追加をやめる    という対応ができる     

Slide 40

Slide 40 text

SUUMOでのパフォーマンス計測  ● クラウド上に独自に構築  ● 既存サービスでは対応できない要件があったため  ● View の自由度が高い  （エンジニア以外が見てもわかりやすくしたい、など） 

Slide 41

Slide 41 text

パフォーマンス計測ツール  ● Lighthouse  ● Chrome User Experience Report (CrUX)  ● Page Speed Insight  ● Web Page Test  ● Google Analytics  など。SpeedCurve、Calibre などのサービスも利用できる。それぞれの特性については↓  https://developers.google.com/web/fundamentals/performance/speed-tools/ 

Slide 42

Slide 42 text

1. SUUMOでは改善→維持→予防の順ですすめている。  2. 改善はハッカソンを入り口に  3. レポーティングでチーム内に共有・共通認識に。  → 企画・設計段階から意識できるように  4. チーム・組織全体で取り組む。属人化させない。  5. 引き続き取り組んでいく！      まとめ 

Slide 43

Slide 43 text

ありがとうございました！ 