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