Lowe's のウェブサイトは、パフォーマンスが最速の e コマースサイトの 1 つです

Lowe's のサイト速度チームは、自動化されたパフォーマンステストとモニタリングシステムを構築することで、パフォーマンスバジェットに対して pull リクエストをテストし、パフォーマンスの低下が本番環境に移行しないようにしています。

Abhimanyu Raibahadur

Ashish Choudhury

Dhilip venkatesh Uvarajan

Dinakar Chandolu

Garima Mimani

Safwan Samla

Lowe's は、約 2,200 店舗を運営し、30 万人以上の従業員を雇用する、約 900 億ドル規模のホームセンターです。Lowe's のサイト速度チームは、本番環境へのデプロイでパフォーマンスの低下を防ぐ自動テストとモニタリングシステムを構築することで、ウェブサイトのパフォーマンスを改善し、小売サイトの上位にランクインしました。

問題

サイト速度チームの目標は、ページ読み込みのパフォーマンスにおいて、Lowe's サイトを最速の e コマースサイトの 1 つにすることを目指しています。自動テストとモニタリングシステムを構築する前は、Lowe's のウェブサイトデベロッパーは、本番環境前の環境でパフォーマンスを自動的に測定できませんでした。既存のツールでは、本番環境でのみテストが行われていました。その結果、品質の低いビルドが本番環境に紛れ込み、ユーザーエクスペリエンスが低下しました。これらの低品質なビルドは、サイト速度チームによって検出され、作成者によって元に戻されるまで本番環境に残ります。

解決策

サイト速度チームは、オープンソースツールを使用して、本番前環境用の自動パフォーマンステストとモニタリングシステムを構築しました。システムはすべてのプルリクエスト（PR）のパフォーマンスを測定し、サイト速度チームのパフォーマンスバジェットと指標の基準を満たしていない PR は本番環境へのリリースをブロックします。また、SEO と ADA のコンプライアンスも測定されます。

影響

1 チームのサンプルで 16 週間に 102 件のビルドをデプロイしたところ、自動パフォーマンステストとモニタリングシステムにより、パフォーマンスが低い 32 件のビルドが本番環境に移行されませんでした。

以前は、パフォーマンスの低下が本番環境にリリースされたことをデベロッパーに通知するのに、サイト速度チームが 3 ～ 5 日かかっていましたが、現在は、本番前環境でプルリクエストを送信してから 5 分後に、システムがパフォーマンスの問題をデベロッパーに自動的に通知します。

パフォーマンスの低下が報告されるプルリクエストが減っていることから、コードの品質は時間とともに向上しています。また、サイト速度チームは、サイトの品質を継続的に改善するために、ガバナンス予算を段階的に引き締めています。

一般的に、問題のあるコードの明確な所有権を持つことで、エンジニアリング文化が変化しました。問題を実際に導入した人物が不明であるために、事後的な修正を渋るのではなく、問題のあるコードの所有権を客観的に特定して、事前に最適化を実施できます。

実装

サイト速度ガバナンス（SSG）アプリの中心は Lighthouse CI です。SSG アプリは Lighthouse を使用して、すべてのプルリクエストのページパフォーマンスを検証し、監査します。

SSG アプリのプロセス図。図に示す手順については、この記事の後半で説明します。

SSG アプリでは、サイト速度チームが定義したパフォーマンスバジェットと指標の目標に達しなかった場合、ビルドが失敗します。読み込みパフォーマンスだけでなく、SEO、PWA、ユーザー補助も強化されます。ステータスを作成者、審査担当者、SRE チームにすぐに報告できます。例外が必要な場合はチェックをバイパスするように構成することもできます。

自動速度管理（ASG）プロセスフロー

Spinnaker

開始地点。デベロッパーがコードを本番前環境にマージします。

CDN アセットを使用して本番前環境をデプロイする。
デプロイが成功したことを確認します。
Docker コンテナを実行して ASG アプリケーションのビルドを開始するか、（デプロイに失敗した場合に）通知を送信します。

Jenkins と Lighthouse

Jenkins を使用して ASG アプリケーションをビルドします。
Chrome と Lighthouse がインストールされているカスタム Docker コンテナを実行します。SSG アプリから lighthouserc.json を pull して、lhci autorun --collect-url=https://example.com を実行します。

Jenkins と SSG アプリ

lhci から assertion-results.json を抽出し、budgets.json で事前定義された予算と比較します。出力をテキストファイルとして保存し、Nexus にアップロードして、今後の比較に使用します。
現在の assertion-results.json を、最後に正常にビルドされたビルド（Nexus からダウンロードしたビルド）と比較し、テキストファイルとして保存します。
成功または失敗に関する情報を含む HTML メールを作成します。
Jenkins を使用して、関連する配信リストにメールを送信します。