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

2019/6/3 Google Cloud で実践する Web アプリ開発での新井の講演資料になります

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19. 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. ” パフォーマンスがページのユーザーのエクスペリエンスにどのように
 影響するかについて広く考え、さまざまなユーザーエクスペリエンス
 の測定基準を検討することを開発者に推奨します。
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41. パフォーマンス計測ツール
 • 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/

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

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