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
   

   View Slide

2. View Slide

3. アクセシビリティとは、障害のある方を含めできるだけ多く
   の方にコンテンツを理解してもらえるようにすることです。
   アクセシビリティが高い Web サイトは、よりインクルーシ
   ブで、幅広いユーザーにとって使いやすいものになります。
   パフォーマンスとは、Web サイトの迅速な表示や素早い
   応答により、スムーズな利用体験を実現することです。
   Web サイトのパフォーマンスが高ければ、ユーザーがよ
   り容易に情報にアクセスできるようになります。
   アクセシビリティー パフォーマンス
   サイバーエージェントが重視してきたもの
   CyberAgent, Inc.
   

   View Slide

4. システムを構築することで効率化の向上、
   繰り返しの多いタスクの自動化、手作業の
   減少につながります。
   チーム内のコミュニケーションやコラボ
   レーションにおける無駄を省き、問題解決
   や技術革新に集中できるようになります。
   システムを構築すると、データ精度が上が
   り、意思決定およびプロジェクト全体の成
   果が向上します。
   個人に依存せずチームで協力すると、一人
   一人の忙しさに依存せず、目標に向けたタ
   スクの進捗が安定します。
   また、コラボレーションを通じて新しい解
   決策が出たり、効果的なコミュニケーショ
   ンが促進され、プロジェクトを円滑に遂行
   することができます。
   同じ目標をもった個人が集まり、チームで
   取り組むと一人では達成できない、より大
   きな成果を生み出せます。
   システムを構築する チームで協力する
   小さなタスクを 1 つ 1 つ終わらせてい
   くことは、永遠に達成できないかもし
   れない完璧さを求めることよりも有益
   です。
   小さなタスクに集中することで、進歩
   を実感し、学びや達成感を得ることが
   できます。
   完璧を求めると、やるべきことを先延
   ばししてしまったり、進歩を実感でき
   なかったりします。
   タスクの焦点を絞る
   FAQ: どのように時間を捻出しているのか？
   CyberAgent, Inc.
   

   View Slide

5. View Slide

6. 最適な機能とユーザーエクスペリエンス
   を提供するために、Web サイトのパ
   フォーマンス指標を継続的にモニタリン
   グ・計測します。
   ツール、インフラ、人的リソースのコス
   トを考慮し、Web パフォーマンス指標や
   リクエスト数の限度／閾値を設定しま
   す。
   モニタリング 予算管理
   Web パフォーマンスを向上させるための
   おおよその戦略を決めます。これには、
   パフォーマンス目標の設定、適切な技術
   やツールの選定、求められる成果を達成
   するために必要なステップの決定などが
   含まれます。
   プランニング
   コードの最適化、画像の最適化、キャッ
   シュの仕組みを活用等、Web パフォーマ
   ンスを向上させるための戦略やアクショ
   ンを実行します。
   改善策実行後のパフォーマンス測定値と
   初期目標を比較して改善の効果を評価
   し、必要であれば適宜調整を行い、継続
   的に最適化を図ります。
   実装 検証
   セクション
   01 02 03
   04 05
   

   View Slide

7. Web パフォーマンスの必須要素
   モニタリング
   セクション 01
   

   View Slide

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
   

   View Slide

9. 9
   ラボデータは通常、ネットワーク速度、デバイスの種類、ブラウザな
   どの特定の条件を設定し制御された環境で合成テストを実行して収集
   します。このデータを見ることで、特定の条件下での問題やボトル
   ネックを把握することが可能になり、Web サイトのパフォーマンスの
   デバッグおよび最適化に役立ちます。
   また、ラボデータは、サイトやアプリの異なるバージョン間のパ
   フォーマンス指標の比較にも使われます。しかし、シミュレーション
   された条件下で収集されるラボデータは、実際のユーザー体験を完全
   に再現していない可能性もあります。
   サイバーエージェントの開発チームは、Chrome DevTools、
   Lighthouse、WebPageTest、SpeedCurve など複数のツールを使って
   問題を検出し、修正しています。
   セクション 01
   ラボデータのモニタリング
   

   View Slide

10. 10
    フィールド データは、リアルユーザーモニタリング（RUM）データとも
    いい、実際のユーザーがそれぞれの通常環境で Web サイトや Web アプ
    リケーションを使用している最中に収集されます。このデータは、ネッ
    トワークの状況、デバイスの種類、ブラウザのバージョン、ユーザーの
    行動などさまざまな要因を考慮に入れ、ユーザーが実際に体験している
    パフォーマンスに関する情報を提供します。
    フィールドデータは、リアルな Web サイトパフォーマンスを把握する
    上で重要なものであり、ラボテストでは明らかにならない問題の特定に
    役立ちます。しかし、フィールド データはさまざまな要因に影響される
    ため、その収集や分析、問題への対処が難しい場合があります。
    サイバーエージェントの開発チームは、Google Search Console を使っ
    て問題のあるURLを確認し、 web-vitals.js を使って計算した値を 固有
    の要素名とともにFirebase、NewRelic などのツールに送っています。
    フィールド データの
    モニタリング
    セクション 01
    

    View Slide

11. 特定の期間内の目標を決める
    予算管理
    セクション 02
    

    View Slide

12. 12
    パフォーマンス バジェットとは、Web サイトやWeb アプリケー
    ションが達成すべき具体的なパフォーマンスの目標として開発チー
    ムが設定する一連の制約や限度値を指します。
    パフォーマンス バジェットを設定し、それを遵守することで、開発
    チームは開発プロセス全体を通じていつパフォーマンス改善に着手
    すべきかわかりやすく、チームに共有しやすくなります。
    サイバーエージェントの Web チームは、Core Web Vitals、リソー
    スサイズ、リクエスト数などいくつかの指標をパフォーマンスバ
    ジェットとして設定しています。
    セクション 02
    パフォーマンス バジェット
    

    View Slide

13. すべてのプルリクエストで Web サイトのパ
    フォーマンス バジェットが維持されている
    ことを保証するパフォーマンス テストを
    CI/CD パイプラインに組み込みます。
    サイバーエージェントの多くの Web チーム
    がプルリクエストごとのファイルサイズの
    違いをチェックしています。
    1 つ以上のパフォーマンス バジェットが設
    定値を超えた場合のアラートとして通知が送
    信されます。
    サイバーエージェントでは、SpeedCurve か
    ら Slack チャンネルに送信されるアラートを
    確認しているチームもあります。
    プルリクエスト 予算超過
    パフォーマンスレポートは（主に1日単
    位で）定期的に作成されます。
    チームによっては、 Chrome UX
    Report API や web-vitals.js で Core
    Web Vitals を計測するためのスクリプ
    トを書いています。
    デイリーレポート
    パフォーマン スアラート
    セクション 02
    

    View Slide

14. 14
    定期的なパフォーマンス レポートは、異常や問題の迅速な特定に役
    立ちます。なかでも中長期のトレンドデータは、Web サイトの継続
    的な改善を推進する上で重要な役割を果たします。
    Ameba の開発チームは、Core Web Vitals を含む Slack からの通知
    を毎日確認しています。そのため、トレンドが悪化し始めると、即座
    にアクションを起こすことができます。
    セクション 02
    パフォーマンス
    デイリーレポート
    

    View Slide

15. 求める成果のためのアウトラインを引く
    プランニング
    セクション 03
    

    View Slide

16. 16
    :yatteiki:
    プランニングは、潜在的な問題を予測し
    ながらパフォーマンス目標を設定し、そ
    れを達成するための戦略を策定するのに
    役立ちます。十分に練られた計画的なア
    プローチにより、成果をより迅速に、よ
    り効率的に達成できます。
    Ameba では、開発チームが「yatteiki」
    と呼ばれる定例会議を開催しています。
    各四半期始まりに目標を設定し、週単位
    で進捗を確認しています。
    セクション 03
    

    View Slide

17. 改善策を実行する
    実装
    セクション 04
    

    View Slide

18. 18
    A/B テストとは、1 つの Web ページの 2 つのバージョンを比較
    して、どちらのパフォーマンスが高いかを判断する方法です。異
    なるデザイン、レイアウト、コンテンツを比較することで、どち
    らのバージョンが求められるアウトカムをより効果的に達成でき
    るかを判断することができます。
    Ameba の Web チームは、パフォーマンス改善をリリースする際
    に A/B テストを実施しています。右図は、JS Lazy-loading と
    Native Lazy-loading のどちらのバージョンでより速く、より効
    果的かを示しています。
    セクション 04
    A/B テスト
    

    View Slide

19. 19
    プリレンダリングは、次に表示される可能性の高いページ
    をあらかじめレンダリングしておく機能です。リンクがク
    リックされると即座にそのページが表示されます。これに
    よってユーザーエクスペリエンスが大幅に向上します。
    AmebaNews では、Speculation Rules によるプリレンダリ
    ングで、 95 パーセンタイルの LCP を 2.2 秒から 1 秒短縮
    し、1.2 秒を達成しました。これは、ほぼすべてのユー
    ザーが 1 秒以内にニュースコンテンツを読み始められる速
    さに相当します。
    セクション 04
    プリレンダリング
    -1sec
    P95 LCP
    

    View Slide

20. 20
    View Transitions API を利用すると、Web アプリケーション内の
    異なるビューや状態へのスムーズかつ視覚的にも好ましい画面遷移
    を実装できます。
    Ameba の開発チームは、View Transitions API を使って Web ア
    プリケーション（SPA、MPA）にシームレスな遷移を付加し、ネイ
    ティブアプリのようなエクスペリエンスを提供しています。
    セクション 04
    View Transitions
    

    View Slide

21. const transition =
    document.startViewTransition(
    async () => {
    await whenPageUpdated();
    }
    );
    transition.ready.then().catch();
    transition.finished.then().catch();
    

    View Slide

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;
    }
    

    View Slide

23. .header {
    contain: layout;
    view-transition-name: header;
    }
    

    View Slide

24. content="same-origin"
    name="view-transition"
    />
    

    View Slide

25. 25
    CLS を最適化するためには、フィールドでのデバッグ情報の
    収集が重要です。CLS は各ページのライフスパン全体を通し
    て測定され、ユーザーによるページへのインタラクションに
    よって、レイアウトシフトが起きるかどうか、あるいはどの
    要素にずれが生じるかが大きく変わります。
    ページ内でレイアウトの安定性が確保されていれば、ユー
    ザーは簡単にリンクを見つけることができ、クリックにつな
    がります。Ameba マンガでは、CLS スコアを 10 倍向上させ
    ることでコミックの読了数が 2～3 倍に増加しました。この
    事例は、 2022 年の Google I/O で成功事例として紹介され
    ました。
    セクション 04
    レイアウトシフトの
    修正
    2-3x
    Comic Read
    

    View Slide

26. 26
    CLS の改善策は、Web ページに影響を与える問題の中
    身によって比較的シンプルなものから複雑なものまで
    多岐にわたります。簡単に改善できる場合もあれば、
    より詳細な分析や開発作業が必要になる場合もありま
    す。
    目指すべきは、ユーザーで発生するレイアウトシフト
    をすべて特定して修正するのではなく、最も多くの
    ユーザーに影響を与えるレイアウトシフトを特定し、
    そのページの CLS の 75 パーセンタイルを達成するこ
    とに最大限の努力を割くことです。
    セクション 04
    最大レイアウト
    シフト数
    

    View Slide

27. 27
    実際のユーザーがどのように Web サイトを体験しているか
    を知るためには、フィールド データを収集することが重要
    です。web-vitals.js は、ターゲット要素、イベントタイ
    プ、開始時間などのアトリビューションを収集し、インタ
    ラクションの遅延を発見するのに役立ちます。
    INP を最適化する方法の１つが、イベント コールバックを
    最適化し、表示遅延を最小化することです。Ameba では、
    イベント コールバックのフローを改善することで、next
    paint time の 50％ を短縮できました。
    セクション 04
    INP の最適化
    -50%
    Interaction to Next Paint
    

    View Slide

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');
    });
    

    View Slide

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 = '';
    });
    

    View Slide

30. 実行された改善策を評価する
    検証
    セクション 05
    

    View Slide

31. セクション 01
    (モニタリング)に戻る
    セクション 05
    01 モニタリング 02 パフォーマンス 03 プランニング 04 実装 05 検証
    

    View Slide

32. Two more things…
    セクション 05
    

    View Slide

33. それぞれの経験を文書化して共有することに
    よって、知識を伝達し、ベストプラクティスを
    見出し、工程や効率性を改善していけます。
    また、継続的な改善、情報に基づいた意思決定
    といったチームの文化醸成にもつながります。
    Ameba では、Spindle というデザインシステ
    ムにパフォーマンスに関する文書を追加してい
    ます。
    ストーリーを
    共有する
    セクション 05
    

    View Slide

34. たとえ小さな修正であっても、あなたが手掛けた改善が製
    品の品質とユーザー エクスペリエンスの向上に大きく貢献
    します。
    小さな改善の積み重ねこそ、目標達成に重要な役割を果た
    すのです。
    Be Proud
    セクション 05
    

    View Slide

35. Web performance is a long and winding road.
    セクション 05
    

    View Slide

36. 原 一成　Kazunari Hara He/Him
    株式会社サイバーエージェント Tech Lead
    Thank You
    

    View Slide