SpeedCurveは最近、ウェブパフォーマンスツールスイートの大幅なアップデートを発表した。特に、プルリクエストの自動パフォーマンステストを容易にするためにGitHubとの統合を強化することに重点を置いている。この新機能は、パフォーマンスフィードバックを開発ワークフローに直接組み込むことを目的としており、開発者がユーザー エクスペリエンスに影響を与える前に、潜在的なリグレッションを簡単に特定して対処できるようにする。
この統合は、SpeedCurve内の監視対象サイトをGitHubリポジトリーにリンクすることで機能する。この接続が確立されると、プルリクエストとして送信されるサイトのコードベースへの変更により、自動パフォーマンステストがトリガーされる。これらのテストは、TBT（サーバー初期応答時間 ）や、LCP（最大視覚コンテンツの表示時間）、FID（初回入力までの遅延時間）、CLS（累積レイアウトシフト数）を含むコアウェブバイタルなどの主要なパフォーマンス指標に対する変更の影響を評価するために設計されている。
SpeedCurveが提供する例は、この統合の実際の応用を示している。開発者は、デモサイトでのメインヒーローイメージの読み込み速度を遅くすることを目的として、変更を加えたプルリクエストを送信。デプロイメントが成功し、パフォーマンステストがSpeedCurveのDeploymentsダッシュボードのキューに自動的に追加され、完了すると、結果はGitHubのプルリクエストのコメントセクションに直接投稿され、即時のレビューとアクションが可能になった。
テストの結果は、開発者にとっていくぶん驚くべきものだった。意図的な減速にも関わらず、LCPメトリックには大きな変化はなく、SpeedCurve内でさらに調査を行ったところ、LCP要素は予想されたヒーロー画像ではなく、画像の上にあるテキスト要素であり、モバイルデバイスではサイズが大きいことが判明した。ユーザー エクスペリエンス指標はデスクトップビューとモバイルビューで大きく異なる可能性があるため、さまざまなフォームファクター間でテストすることの重要性が強調された。
このアップデートから得られることは多面的だ。まず、SpeedCurveによるGitHubの統合は、開発プロセスにパフォーマンステストを組み込むことの重要性を強調している。また、一貫したユーザーエクスペリエンスを確保するために、開発者がさまざまなデバイスで変更をテストする必要性も強調している。さらに、この例は、LCPおよびその他のパフォーマンス指標が常に予想通りに動作するとは限らないことを示しており、開発者は変更の影響を完全に理解するためにさまざまな指標を採用する必要がある。
さらに、この統合は、タイミングに関連する側面だけでなく、サイトのさまざまな側面に対してパフォーマンスバジェットを設定することの価値を示唆している。例えば、画像または動画のサイズに予算が設定されていれば、この例のような後退が本番環境に到達するリスクは軽減された可能性がある。
SpeedCurveの新しいGitHub統合は全てのアカウントで利用できるようになり、同社は開発者にパフォーマンステストをワークフローに統合することを奨励している。SpeedCurveアカウントを持たない人向けに、同社はパフォーマンステストツールを使い始めるための無料トライアルを提供している。このアップデートは、SpeedCurveによる広範な取り組みの一環であり、ウェブサイトのパフォーマンスを維持および向上させるために必要なリソースを開発者に提供し、全てのデバイスのユーザーに高速でシームレスなエクスペリエンスを保証する。
出典：SpeedCurve
この製品の詳細については、SpeedCurve製品ページをご覧ください。
