Zalando のウェブチームは、Lighthouse CI を統合することで、パフォーマンスに対する先行型のアプローチが可能になり、自動ステータス チェックで現在の commit をメインブランチと比較してパフォーマンスの低下を防ぐことができると判断しました。
3,500 万人を超えるアクティブ ユーザーを抱える Zalando は、ヨーロッパを代表するオンライン ファッション プラットフォームです。この記事では、Lighthouse CI の使用を開始した理由、実装の容易さ、チームへのメリットについて説明します。
Zalando は、ウェブサイトのパフォーマンスと収益の関係を把握しています。過去に、カタログ ページの読み込み時間を人為的に長くした場合に、直帰率、コンバージョン率、ユーザーあたりの収益にどのような影響があるかをテストしました。結果は明らかでした。ページの読み込み時間が 100 ミリ秒短くなると、エンゲージメントが向上し、直帰率が低下し、1 回のセッションあたりの収益が 0.7% 増加しました。
100ミリ秒
ページの読み込み時間の短縮
0.7%
セッションあたりの収益の増加
企業の賛同が必ずしも業績につながるとは限らない
社内でパフォーマンスに対する強い支持があっても、パフォーマンスがプロダクトの提供基準として設定されていないと、簡単に見落とされてしまいます。2020 年に Zalando ウェブサイトを再設計した際は、優れたユーザー エクスペリエンスを維持しながら、カスタム フォントとより鮮やかな色を使用してウェブサイトのデザインを一新し、新機能を提供することに重点を置きました。しかし、再設計されたウェブサイトとアプリがリリースの準備ができたとき、早期導入者の指標から、新しいバージョンが遅いことがわかりました。First Contentful Paint は最大で 53% 遅くなり、測定された Time to Interactive は最大で 59% 遅くなりました。
Zalando のウェブ
Zalando ウェブサイトは、フレームワークを開発するコアチームによって作成され、15 を超える機能チームがフロントエンド マイクロサービスに貢献しています。新しいリリースをサポートするとともに、ウェブサイトの一部をより一元化されたアーキテクチャに移行しました。
以前のアーキテクチャ（Mosaic）には、社内指標でページのパフォーマンスを測定する方法が含まれていました。ただし、内部ラボのパフォーマンス モニタリング ツールがないため、実際のユーザーにリリースする前にパフォーマンス指標を比較することは困難でした。毎日デプロイしていたにもかかわらず、パフォーマンス改善に取り組むデベロッパーには 1 日ほどフィードバック ループがありました。
ウェブバイタルと Lighthouse の活用
社内指標は新しい設定に適応しなかったため、完全に満足できるものではありませんでした。さらに重要なのは、カスタマー エクスペリエンスを重視していなかったことです。Core Web Vitals は、簡潔でありながら包括的でユーザー重視の指標セットを提供するため、これに切り替えました。
リリース前にパフォーマンスを改善するには、適切なラボ環境を作成する必要がありました。これにより、フィールドデータの 90 パーセンタイルを代表するテスト条件に加えて、再現可能な測定値が得られました。パフォーマンスの改善に取り組んでいるエンジニアは、最大限の効果を発揮するためにどこに重点を置くべきかを知ることができました。すでに Lighthouse 監査レポートをローカルで使用していた。最初の反復処理では、Lighthouse ノード モジュールに基づいてサービスを開発し、ステージング環境から変更をテストできるようにしました。これにより、約 1 時間の信頼できるパフォーマンス フィードバック ループが確立され、パフォーマンスを同等に引き上げてリリースを救うことができました。
pull リクエストでデベロッパーにパフォーマンスに関するフィードバックを提供する
Google は、パフォーマンスに対する事後対応だけでなく、事前対応も行えるようにしたいと考えていました。Lighthouse ノード モジュールから Lighthouse CI（LHCI）サーバーへの移行は、それほど難しくありませんでした。既存の社内サービスとの統合を強化するため、セルフホスト ソリューションを選択しました。LHCI サーバー アプリケーションは Docker イメージとしてビルドされ、PostgreSQL データベースとともに Kubernetes クラスタにデプロイされ、GitHub にレポートされます。
Google のフレームワークでは、すでにデベロッパーにパフォーマンスに関するフィードバックを提供していました。コンポーネント バンドルのサイズは、コミットごとにしきい値と比較されていました。Lighthouse 指標を GitHub ステータス チェックとしてレポートできるようになりました。パフォーマンスのしきい値を満たしていない場合、CI パイプラインは失敗し、次の画像に示すように、詳細な Lighthouse レポートへのリンクが表示されます。
パフォーマンス カバレッジの拡大
私たちは非常に実用的なアプローチから始めました。現在、Lighthouse は、最も重要な 2 つのページ（ホームページと商品の詳細ページ）でのみ実行されます。幸い、Lighthouse CI では、実行構成を簡単に拡張できます。ウェブサイトの特定のページを担当する機能チームは、一致する URL パターンとアサーションを設定できます。これにより、パフォーマンスの対象範囲が拡大されることは間違いありません。
大規模なリリースを構築する際には、より高い信頼性を得られるようになりました。また、デベロッパーはコードのパフォーマンスに関するフィードバック ループを大幅に短縮できます。