Google I/O Extended Japan 2023 - Web Performance at CyberAgent

国内事例 / Fireside Chat
パスキー、プライバシーサンドボックス、パフォーマンスの 3 つの領域について、先進的な取り組みをされている会社をそれぞれお招きし、Google 社員と対談しながら詳細についてお話しいただきます。
https://developersonair.withgoogle.com/events/ioextendedjapan2023?talk=webcasestudy

Transcript

1. Always Fresh 原 一成　Kazunari Hara He/Him 株式会社サイバーエージェント Tech Lead
3. アクセシビリティとは、障害のある方を含めできるだけ多く の方にコンテンツを理解してもらえるようにすることです。 アクセシビリティが高い Web サイトは、よりインクルーシ ブで、幅広いユーザーにとって使いやすいものになります。 パフォーマンスとは、Web サイトの迅速な表示や素早い 応答により、スムーズな利用体験を実現することです。 Web サイトのパフォーマンスが高ければ、ユーザーがよ り容易に情報にアクセスできるようになります。 アクセシビリティー パフォーマンス サイバーエージェントが重視してきたもの CyberAgent, Inc.
4. システムを構築することで効率化の向上、 繰り返しの多いタスクの自動化、手作業の 減少につながります。 チーム内のコミュニケーションやコラボ レーションにおける無駄を省き、問題解決 や技術革新に集中できるようになります。 システムを構築すると、データ精度が上が り、意思決定およびプロジェクト全体の成 果が向上します。 個人に依存せずチームで協力すると、一人 一人の忙しさに依存せず、目標に向けたタ スクの進捗が安定します。 また、コラボレーションを通じて新しい解 決策が出たり、効果的なコミュニケーショ ンが促進され、プロジェクトを円滑に遂行 することができます。 同じ目標をもった個人が集まり、チームで 取り組むと一人では達成できない、より大 きな成果を生み出せます。 システムを構築する チームで協力する 小さなタスクを 1 つ 1 つ終わらせてい くことは、永遠に達成できないかもし れない完璧さを求めることよりも有益 です。 小さなタスクに集中することで、進歩 を実感し、学びや達成感を得ることが できます。 完璧を求めると、やるべきことを先延 ばししてしまったり、進歩を実感でき なかったりします。 タスクの焦点を絞る FAQ: どのように時間を捻出しているのか？ CyberAgent, Inc.
6. 最適な機能とユーザーエクスペリエンス を提供するために、Web サイトのパ フォーマンス指標を継続的にモニタリン グ・計測します。 ツール、インフラ、人的リソースのコス トを考慮し、Web パフォーマンス指標や リクエスト数の限度／閾値を設定しま す。 モニタリング 予算管理 Web パフォーマンスを向上させるための おおよその戦略を決めます。これには、 パフォーマンス目標の設定、適切な技術 やツールの選定、求められる成果を達成 するために必要なステップの決定などが 含まれます。 プランニング コードの最適化、画像の最適化、キャッ シュの仕組みを活用等、Web パフォーマ ンスを向上させるための戦略やアクショ ンを実行します。 改善策実行後のパフォーマンス測定値と 初期目標を比較して改善の効果を評価 し、必要であれば適宜調整を行い、継続 的に最適化を図ります。 実装 検証 セクション 01 02 03 04 05
7. Web パフォーマンスの必須要素 モニタリング セクション 01
8. LCP (Largest Contentful Paint）は、 Web ページの読み込み・表示速度を測る 指標。 最大のコンテンツ要素（画像やテキストブ ロックなど）が画面上に完全に表示される のに要する時間を指します。 CLS (Cumulative Layout Shift) は、Web ページの視覚的安定性を測る指標で、ペー ジ内で発生する予期せぬレイアウトシフト の量を数値化したもの。CLS が低いほ ど、ページのレイアウトが安定しているこ とを示します。 LCP CLS FID (First Input Delay）/ INP (Interaction to Next Paint) は、Web ページの応答性を測る指標。ユーザー がある Web ページで行ったインタラク ション (ボタンやリンクのクリックな ど) に対し、ブラウザが反応するまでの 時間を指します。 FID / INP ウェブに関する主な指標 (Core Web Vitals) セクション 01
9. 9 ラボデータは通常、ネットワーク速度、デバイスの種類、ブラウザな どの特定の条件を設定し制御された環境で合成テストを実行して収集 します。このデータを見ることで、特定の条件下での問題やボトル ネックを把握することが可能になり、Web サイトのパフォーマンスの デバッグおよび最適化に役立ちます。 また、ラボデータは、サイトやアプリの異なるバージョン間のパ フォーマンス指標の比較にも使われます。しかし、シミュレーション された条件下で収集されるラボデータは、実際のユーザー体験を完全 に再現していない可能性もあります。 サイバーエージェントの開発チームは、Chrome DevTools、 Lighthouse、WebPageTest、SpeedCurve など複数のツールを使って 問題を検出し、修正しています。 セクション 01 ラボデータのモニタリング
10. 10 フィールド データは、リアルユーザーモニタリング（RUM）データとも いい、実際のユーザーがそれぞれの通常環境で Web サイトや Web アプ リケーションを使用している最中に収集されます。このデータは、ネッ トワークの状況、デバイスの種類、ブラウザのバージョン、ユーザーの 行動などさまざまな要因を考慮に入れ、ユーザーが実際に体験している パフォーマンスに関する情報を提供します。 フィールドデータは、リアルな Web サイトパフォーマンスを把握する 上で重要なものであり、ラボテストでは明らかにならない問題の特定に 役立ちます。しかし、フィールド データはさまざまな要因に影響される ため、その収集や分析、問題への対処が難しい場合があります。 サイバーエージェントの開発チームは、Google Search Console を使っ て問題のあるURLを確認し、 web-vitals.js を使って計算した値を 固有 の要素名とともにFirebase、NewRelic などのツールに送っています。 フィールド データの モニタリング セクション 01
11. 特定の期間内の目標を決める 予算管理 セクション 02
12. 12 パフォーマンス バジェットとは、Web サイトやWeb アプリケー ションが達成すべき具体的なパフォーマンスの目標として開発チー ムが設定する一連の制約や限度値を指します。 パフォーマンス バジェットを設定し、それを遵守することで、開発 チームは開発プロセス全体を通じていつパフォーマンス改善に着手 すべきかわかりやすく、チームに共有しやすくなります。 サイバーエージェントの Web チームは、Core Web Vitals、リソー スサイズ、リクエスト数などいくつかの指標をパフォーマンスバ ジェットとして設定しています。 セクション 02 パフォーマンス バジェット
13. すべてのプルリクエストで Web サイトのパ フォーマンス バジェットが維持されている ことを保証するパフォーマンス テストを CI/CD パイプラインに組み込みます。 サイバーエージェントの多くの Web チーム がプルリクエストごとのファイルサイズの 違いをチェックしています。 1 つ以上のパフォーマンス バジェットが設 定値を超えた場合のアラートとして通知が送 信されます。 サイバーエージェントでは、SpeedCurve か ら Slack チャンネルに送信されるアラートを 確認しているチームもあります。 プルリクエスト 予算超過 パフォーマンスレポートは（主に1日単 位で）定期的に作成されます。 チームによっては、 Chrome UX Report API や web-vitals.js で Core Web Vitals を計測するためのスクリプ トを書いています。 デイリーレポート パフォーマン スアラート セクション 02
14. 14 定期的なパフォーマンス レポートは、異常や問題の迅速な特定に役 立ちます。なかでも中長期のトレンドデータは、Web サイトの継続 的な改善を推進する上で重要な役割を果たします。 Ameba の開発チームは、Core Web Vitals を含む Slack からの通知 を毎日確認しています。そのため、トレンドが悪化し始めると、即座 にアクションを起こすことができます。 セクション 02 パフォーマンス デイリーレポート
15. 求める成果のためのアウトラインを引く プランニング セクション 03
16. 16 :yatteiki: プランニングは、潜在的な問題を予測し ながらパフォーマンス目標を設定し、そ れを達成するための戦略を策定するのに 役立ちます。十分に練られた計画的なア プローチにより、成果をより迅速に、よ り効率的に達成できます。 Ameba では、開発チームが「yatteiki」 と呼ばれる定例会議を開催しています。 各四半期始まりに目標を設定し、週単位 で進捗を確認しています。 セクション 03
17. 改善策を実行する 実装 セクション 04
18. 18 A/B テストとは、1 つの Web ページの 2 つのバージョンを比較 して、どちらのパフォーマンスが高いかを判断する方法です。異 なるデザイン、レイアウト、コンテンツを比較することで、どち らのバージョンが求められるアウトカムをより効果的に達成でき るかを判断することができます。 Ameba の Web チームは、パフォーマンス改善をリリースする際 に A/B テストを実施しています。右図は、JS Lazy-loading と Native Lazy-loading のどちらのバージョンでより速く、より効 果的かを示しています。 セクション 04 A/B テスト
19. 19 プリレンダリングは、次に表示される可能性の高いページ をあらかじめレンダリングしておく機能です。リンクがク リックされると即座にそのページが表示されます。これに よってユーザーエクスペリエンスが大幅に向上します。 AmebaNews では、Speculation Rules によるプリレンダリ ングで、 95 パーセンタイルの LCP を 2.2 秒から 1 秒短縮 し、1.2 秒を達成しました。これは、ほぼすべてのユー ザーが 1 秒以内にニュースコンテンツを読み始められる速 さに相当します。 セクション 04 プリレンダリング -1sec P95 LCP
20. 20 View Transitions API を利用すると、Web アプリケーション内の 異なるビューや状態へのスムーズかつ視覚的にも好ましい画面遷移 を実装できます。 Ameba の開発チームは、View Transitions API を使って Web ア プリケーション（SPA、MPA）にシームレスな遷移を付加し、ネイ ティブアプリのようなエクスペリエンスを提供しています。 セクション 04 View Transitions
21. const transition = document.startViewTransition( async () => { await whenPageUpdated(); } ); transition.ready.then().catch(); transition.finished.then().catch();
22. ::view-transition-old(root) { animation: fade-out 150ms both, slide-to-left 350ms both; } ::view-transition-new(root) { animation: fade-in 350ms both, slide-to-right 350ms both; }
23. .header { contain: layout; view-transition-name: header; }
24. <meta content="same-origin" name="view-transition" />
25. 25 CLS を最適化するためには、フィールドでのデバッグ情報の 収集が重要です。CLS は各ページのライフスパン全体を通し て測定され、ユーザーによるページへのインタラクションに よって、レイアウトシフトが起きるかどうか、あるいはどの 要素にずれが生じるかが大きく変わります。 ページ内でレイアウトの安定性が確保されていれば、ユー ザーは簡単にリンクを見つけることができ、クリックにつな がります。Ameba マンガでは、CLS スコアを 10 倍向上させ ることでコミックの読了数が 2～3 倍に増加しました。この 事例は、 2022 年の Google I/O で成功事例として紹介され ました。 セクション 04 レイアウトシフトの 修正 2-3x Comic Read
26. 26 CLS の改善策は、Web ページに影響を与える問題の中 身によって比較的シンプルなものから複雑なものまで 多岐にわたります。簡単に改善できる場合もあれば、 より詳細な分析や開発作業が必要になる場合もありま す。 目指すべきは、ユーザーで発生するレイアウトシフト をすべて特定して修正するのではなく、最も多くの ユーザーに影響を与えるレイアウトシフトを特定し、 そのページの CLS の 75 パーセンタイルを達成するこ とに最大限の努力を割くことです。 セクション 04 最大レイアウト シフト数
27. 27 実際のユーザーがどのように Web サイトを体験しているか を知るためには、フィールド データを収集することが重要 です。web-vitals.js は、ターゲット要素、イベントタイ プ、開始時間などのアトリビューションを収集し、インタ ラクションの遅延を発見するのに役立ちます。 INP を最適化する方法の１つが、イベント コールバックを 最適化し、表示遅延を最小化することです。Ameba では、 イベント コールバックのフローを改善することで、next paint time の 50％ を短縮できました。 セクション 04 INP の最適化 -50% Interaction to Next Paint
28. // NOTE: this is a sample, not a production code // Before photo.addEventListener('click', async () => { const images = await fetch(...); modal.innerHTML = ''; modal.classList.add('show'); });
29. // NOTE: this is a sample, not a production code // After photo.addEventListener('click', async () => { // Display modal ASAP modal.classList.add('show'); const images = await fetch(...); modal.innerHTML = ''; });
30. 実行された改善策を評価する 検証 セクション 05
31. セクション 01 (モニタリング)に戻る セクション 05 01 モニタリング 02 パフォーマンス 03 プランニング 04 実装 05 検証
32. Two more things… セクション 05
33. それぞれの経験を文書化して共有することに よって、知識を伝達し、ベストプラクティスを 見出し、工程や効率性を改善していけます。 また、継続的な改善、情報に基づいた意思決定 といったチームの文化醸成にもつながります。 Ameba では、Spindle というデザインシステ ムにパフォーマンスに関する文書を追加してい ます。 ストーリーを 共有する セクション 05
34. たとえ小さな修正であっても、あなたが手掛けた改善が製 品の品質とユーザー エクスペリエンスの向上に大きく貢献 します。 小さな改善の積み重ねこそ、目標達成に重要な役割を果た すのです。 Be Proud セクション 05
35. Web performance is a long and winding road. セクション 05
36. 原 一成　Kazunari Hara He/Him 株式会社サイバーエージェント Tech Lead Thank You