フロントエンドパフォーマンス2021:テストとモニタリング
公開: 2022-03-10このガイドは、フロントエンドのパフォーマンスモニタリング、セッションの再生、および製品分析を組み合わせて、より良いカスタマーエクスペリエンスを構築するのに役立つ、LogRocketの友人から親切にサポートされています。 LogRocketは、主要なメトリックを追跡します。 DOM完了、最初のバイトまでの時間、最初の入力遅延、クライアントのCPUとメモリの使用量。 今すぐLogRocketの無料トライアルを入手してください。
目次
- 準備:計画と指標
- 現実的な目標の設定
- 環境の定義
- 資産の最適化
- ビルドの最適化
- 配信の最適化
- ネットワーキング、HTTP / 2、HTTP / 3
- テストと監視
- クイックウィン
- 1ページのすべて
- チェックリストをダウンロードする(PDF、Apple Pages、MS Word)
- 次のガイドを見逃さないように、メールマガジンを購読してください。
テストとモニタリング
- 監査ワークフローを最適化しましたか?
大したことではないように聞こえるかもしれませんが、適切な設定を指先で行うことで、テストにかかる時間を大幅に節約できる可能性があります。 WebPageTestのパブリックインスタンスにテストを送信するには、TimKadlecのAlfredWorkflow forWebPageTestを使用することを検討してください。 実際、WebPageTestには多くのあいまいな機能があるため、時間をかけてWebPageTestウォーターフォールビューチャートを読み取る方法と、WebPageTest接続ビューチャートを読み取ってパフォーマンスの問題をより迅速に診断および解決する方法を学習してください。また、GoogleスプレッドシートからWebPageTestを駆動し、アクセシビリティ、パフォーマンス、SEOスコアをLighthouse CIを使用してTravisセットアップに組み込むか、Webpackに直接組み込むこともできます。
最近リリースされたAutoWebPerfをご覧ください。これは、複数のソースからパフォーマンスデータを自動的に収集できるモジュラーツールです。 たとえば、重要なページに毎日テストを設定して、CrUX APIからフィールドデータをキャプチャし、PageSpeedInsightsからLighthouseレポートからラボデータをキャプチャすることができます。
また、何かをすばやくデバッグする必要があるが、ビルドプロセスが非常に遅いように思われる場合は、「空白の削除とシンボルのマングリングは、複雑なコード変換ではなく、ほとんどのJavaScriptの縮小コードのサイズ縮小の95%を占めることに注意してください。圧縮を無効にするだけで、Uglifyのビルドが3〜4倍高速化されます。」
- プロキシブラウザとレガシーブラウザでテストしましたか?
ChromeとFirefoxでのテストだけでは不十分です。 プロキシブラウザとレガシーブラウザでWebサイトがどのように機能するかを調べます。 たとえば、UCBrowserとOperaMiniは、アジアで大きな市場シェアを持っています(アジアでは最大35%)。 将来の大きな驚きを避けるために、関心のある国の平均インターネット速度を測定します。 ネットワークスロットリングでテストし、高DPIデバイスをエミュレートします。 BrowserStackは、リモートの実際のデバイスでのテストに最適であり、オフィス内の少なくともいくつかの実際のデバイスで補完することもできます。それだけの価値があります。
- 404ページのパフォーマンスをテストしましたか?
通常、404ページに関しては二度と考えません。 結局のところ、クライアントがサーバーに存在しないページを要求すると、サーバーは404ステータスコードと関連する404ページで応答します。 そんなに多くはありませんね。404応答の重要な側面は、ブラウザーに送信される実際の応答本文のサイズです。 Matt Hobbsによる404ページの調査によると、404応答の大部分は、ファビコンの欠落、WordPressアップロード要求、壊れたJavaScript要求、マニフェストファイル、CSSおよびフォントファイルからのものです。 クライアントが存在しないアセットをリクエストするたびに、404レスポンスを受け取ります。多くの場合、そのレスポンスは膨大です。
404ページのキャッシュ戦略を調べて最適化してください。 私たちの目標は、ブラウザがHTML応答を期待する場合にのみ、ブラウザにHTMLを提供し、他のすべての応答に対して小さなエラーペイロードを返すことです。 Mattによると、「CDNをオリジンの前に配置すると、404ページの応答をCDNにキャッシュする機会があります。これがないと、404ページをヒットするとDoS攻撃ベクトルとして使用される可能性があるため便利です。 CDNにキャッシュされたバージョンで応答させるのではなく、オリジンサーバーにすべての404要求に応答するように強制します。」
404エラーはパフォーマンスに悪影響を与える可能性があるだけでなく、トラフィックにコストがかかる可能性があるため、Lighthouseテストスイートに404エラーページを含めて、そのスコアを経時的に追跡することをお勧めします。
- GDPR同意プロンプトのパフォーマンスをテストしましたか?
GDPRとCCPAの時代には、EUの顧客が追跡をオプトインまたはオプトアウトするためのオプションを提供するために、サードパーティに依存することが一般的になっています。 ただし、他のサードパーティスクリプトと同様に、それらのパフォーマンスは、パフォーマンスの取り組み全体に非常に大きな影響を与える可能性があります。もちろん、実際の同意によって全体的なパフォーマンスに対するスクリプトの影響が変わる可能性が高いため、Boris Schapiraが指摘したように、いくつかの異なるWebパフォーマンスプロファイルを調査することをお勧めします。
- 同意は完全に拒否されました、
- 同意は部分的に拒否されました、
- 同意は完全に与えられました。
- ユーザーが同意プロンプトに対応していません(またはプロンプトがコンテンツブロッカーによってブロックされました)、
通常、Cookieの同意プロンプトはCLSに影響を与えるべきではありませんが、影響を与える場合もあるため、無料のオープンソースオプションであるOsanoまたはcookie-consent-boxの使用を検討してください。
一般に、マウスイベントの水平方向または垂直方向のオフセットを決定し、アンカーに対してポップアップを正しく配置する必要があるため、ポップアップのパフォーマンスを調べる価値があります。 Noam Rosenthalは、Webパフォーマンスのケーススタディ:ウィキペディアのページプレビュー(ビデオおよび議事録としても利用可能)の記事でウィキメディアチームの学習を共有しています。
- パフォーマンス診断CSSを保持していますか?
パフォーマンスの低いコードがデプロイされていることを確認するためにあらゆる種類のチェックを含めることができますが、簡単に解決できるいくつかの簡単な成果をすばやく把握しておくと便利なことがよくあります。 そのために、Tim Kadlecの優れたパフォーマンス診断CSS(遅延読み込み画像、サイズなし画像、レガシー形式の画像、同期スクリプトを強調表示するHarryRobertsのスニペットに触発されたもの)を使用できます。たとえば、折り目の上の画像が遅延ロードされないようにすることができます。 必要に応じてスニペットをカスタマイズできます。たとえば、使用されていないWebフォントを強調表示したり、アイコンフォントを検出したりできます。 デバッグ中に間違いが表示されるようにするため、または現在のプロジェクトを非常に迅速に監査するための優れた小さなツール。
/* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
- アクセシビリティへの影響をテストしましたか?
ブラウザがページの読み込みを開始すると、DOMが構築され、スクリーンリーダーのような支援技術が実行されている場合は、アクセシビリティツリーも作成されます。 次に、スクリーンリーダーは、ユーザー補助ツリーにクエリを実行して情報を取得し、ユーザーが利用できるようにする必要があります。デフォルトの場合もあれば、オンデマンドの場合もあります。 そして時々それは時間がかかります。インタラクティブへの高速時間について話すとき、通常、ユーザーがリンクやボタンをクリックまたはタップすることによってページを操作できる時間の指標を意味します。 スクリーンリーダーでは、コンテキストが少し異なります。 その場合、インタラクティブへの高速時間とは、スクリーンリーダーが特定のページのナビゲーションをアナウンスでき、スクリーンリーダーのユーザーが実際にキーボードを押して操作できるようになるまでにどれだけの時間が経過するかを意味します。
Leonie Watsonは、アクセシビリティパフォーマンス、特に読み込みが遅いことがスクリーンリーダーのアナウンスの遅延に与える影響について目を見張るような話をしました。 スクリーンリーダーは、ペースの速いアナウンスと迅速なナビゲーションに慣れているため、目の見えるユーザーよりも忍耐力が低い可能性があります。
大きなページとJavaScriptを使用したDOM操作により、スクリーンリーダーのアナウンスが遅れます。 スクリーンリーダーは文字通りすべてのプラットフォーム(Jaws、NVDA、Voiceover、Narrator、Orca)で利用できるため、注意とテストを使用できる、かなり未踏の領域です。
- 継続的な監視が設定されていますか?
WebPagetestのプライベートインスタンスを持つことは、迅速で無制限のテストに常に役立ちます。 ただし、自動アラート機能を備えた継続的な監視ツール(Sitespeed、Calibre、SpeedCurveなど)を使用すると、パフォーマンスの詳細を把握できます。 独自のユーザータイミングマークを設定して、ビジネス固有のメトリックを測定および監視します。 また、自動パフォーマンス回帰アラートを追加して、時間の経過に伴う変化を監視することを検討してください。RUMソリューションを使用して、時間の経過に伴うパフォーマンスの変化を監視することを検討してください。 自動化された単体テストのような負荷テストツールの場合、スクリプトAPIでk6を使用できます。 また、SpeedTracker、Lighthouse、Calibreも調べてください。
目次
- 準備:計画と指標
- 現実的な目標の設定
- 環境の定義
- 資産の最適化
- ビルドの最適化
- 配信の最適化
- ネットワーキング、HTTP / 2、HTTP / 3
- テストとモニタリング
- クイックウィン
- 1ページのすべて
- チェックリストをダウンロードする(PDF、Apple Pages、MS Word)
- 次のガイドを見逃さないように、メールマガジンを購読してください。