高負荷の情報ポータルの例を使用して、フロントエンドアプリケーションの技術監査を実施する方法

サイト監査は通常、検索エンジンでの可視性に影響を与える要因の包括的な分析、つまりSEO監査として理解されます。また、ユーザーインターフェイスの有効性、使いやすさ、ロジックを測定するUX監査も人気を博し始めています。



サイトの速度をチェックし、遅延の原因を特定するために、技術監査があります。システムが正常に動作しているように見え、パフォーマンスの問題がない場合でも、これを実行することをお勧めします。実際には、それでも改善できる可能性があります。インフラストラクチャの最適化によりコードの配信が高速化され、コードベースをリファクタリングすることでメンテナンスコストを削減できます。



この記事では、1時間に数万人のユーザーがアクセスする人気のあるニュースリソースの例を使用して、Webサイトの技術監査がどのように行われるかを示します。検証と分析の独立した段階について考えてみましょう。その結果、プロジェクトを改善し、ページの読み込みを遅くするボトルネックを排除する方法を明確に示します。

メトリックの収集と静的サイトリソースの分析

必ずメトリックを収集し、Google Page Speed、Lighthouse、Web.devなどの既製のツールを使用して可能なすべてを測定してください。これは、調査の開始点となるメトリックを取得するための最速の方法です。彼らの助けを借りて、あなたは最初に注意を払う価値があるもの、最適化できるものを理解するでしょう。



広告ブロッカーをオンまたはオフにして分析を実行することをお勧めします。その結果、コンテンツの最初のレンダリングがどれだけ速く行われるか、およびサイトに接続されているサードパーティのスクリプトの数がわかります。







この段階では、サイトをレンダリングするときに発生する基本的な操作の数も確認できます。







収集されたメトリックは、静的サイト資産（画像、ビデオ、スクリプト、スタイル、およびフォント）を改善するためのスペースを示している可能性があります。このデータを分析し、一般的な静的リソースの慣行に従っていることを確認してください。ただし、これらは単なるガイドラインであり、厳密な要件ではないことに注意してください。



この例では、すべての画像がjpg形式で保存されています。ブラウザで完全にサポートされているwebpを使用すると、ファイルサイズが平均20％削減されます。自動webp圧縮は、高解像度の画像に対してのみ構成できます。この形式をサポートするブラウザでは、高解像度のビデオをwebmに変換することをお勧めします。ネットワークの負荷を軽減するために、表示されていないビデオの自動再生を無効にすることをお勧めします。これは、Intersection ObserverAPIを使用して実行できます。



サイトにプログレッシブダウンロードがあることを確認し、可能であればどこにでも圧縮を追加します。 brotli、gzip、deflateなどの最新のスクリプト圧縮技術を使用してください。



使用されていないものはロードしないでください。これは、コード、スタイル、シンボル、画像に適用できます。たとえば、ウェブサイトに1000のケースの1つに表示されるボタンがある場合、それを処理するスクリプトはオンデマンドでのみ接続する必要があります。







上記の例では、コード全体の約93％が使用されていないことがわかります（約340 kb）。ページをリロードせずにすべてのケースをカバーしながら、カバレッジが100％の場合、コードを含むバンドルは理想的と見なされます。これは、コードがまったく使用されていない場合、コード分割が正しく構成されていない場合、または使用されているが他のページで使用されている場合、または特定のシナリオに達した場合に発生する可能性があります。



この問題の解決策は、再利用可能なコンポーネントを個別のファイル（チャンク）に移動し、それらが必要な場所でのみ接続されるようにすることです。



前述したように、これらの要件はオプションですが、ユーザーが最初に気付くため、静的リソースの最適化は重要です。



例としてフォントを取り上げましょう。このプロジェクトでは、フォントの読み込みに時間がかかりすぎました。ユーザーに標準フォントを表示させたくないので、最初に、critical-cssセクションでそれらをロードします。この問題を解決する方法は？コードレベルでフォントを最適化し、接続順序を変更し、ttfをwoff2に置き換えることができます。



使用するフォントの数を減らすこともできます。これには再設計が必要ですが、これが常に正当化されるとは限りません。サイトでGoogleFontsライブラリを使用している場合は、ファイルから未使用の文字を削除してください。これは著作権で禁止されていません。



しかし、物事をそのままにして、他の可能性に焦点を合わせる方が簡単な場合もあります。

HTTPリクエストの調査

この段階で、フロントエンドがバックエンドと正しく相互作用するかどうかを確認します。

• APIリクエストの設定済み圧縮。
• 接続をロードする寄生クエリはなく、その結果はどこにも使用されません。
• ユーザーが特定のビジネスケースを完了せずにエラーで返される要求はありません。
• ページが最初にロードされるとき、ブラウザはAPIにリクエストを送信しません（この例のように、サイトがサーバー側のレンダリングを使用している場合）。
• 重複するリクエストはありません。いずれかのページに移動するときにリクエストが行われた場合は、一度送信してデータを保存して再利用することをお勧めします。
• pending , . , , , . , — , .

ブロックされたリクエストは赤で強調表示されますが、サイトは引き続き機能します。



また、リクエストを分析すると、バグが見つかる場合があります。これが、フロントエンドアプリケーションの誤った操作に遭遇した方法であり、1秒あたり100を超える要求を送信する可能性があり、サーバーに大きな負荷がかかりました。画面が点滅したり、ローダーが際限なく回転したりします。その理由は、誤って実装されたスクロールに隠されていました。新しい要素が表示されたとき、ブラウザはページの下部にその位置を維持しました。つまり、ページをスクロールすると、ローダーが起動したため、ページが下に移動しました。 Javascriptハンドラーがリクエストを再送信しました。これにより、ローダーアニメーションが再度発生し、ページサイズが変更されたなど、無限に続きました。





ローダーの誤動作により、リクエスト数は無限に増加します

外部スクリプトとリソースの分析

この段階で、サードパーティサイトのどのリソースの読み込みに最も時間がかかるかを判断する必要があります。



最新のWebでは、ダウンロードに優先順位を付けることができます。多くの場合、指標と広告はページが表示される前に読み込まれますが、ユーザーは引き続き広告を表示できませんが、サイトの読み込みに時間がかかるため、それ自体は意味がありません。サイトをレンダリングした直後に広告を表示することをお勧めします。これは統計にまったく影響しません。そうしないと、ユーザーにしばらくの間白い画面が表示されます。

プロファイリングページ

chrome devツールを使用してサイトページのプロファイルを作成し、長いリクエストと増加したCPU使用量を追跡します。その結果、サイトを明確にロードするものが表示されます。







スクリーンショットは、Jqueryのロードに19ミリ秒かかることを示していますが、現時点では必要ありません。メインリソースの後で、できればロードイベントが成功した後（onload、domcontentloadedなど）にjqueryをロードすることをお勧めします。

リクエストの数と期間の分析

この段階で、フロントエンドがバックエンドとどのように相互作用するかを調べます。これを行うには、すべてのリクエストの数と期間を分析する必要があります。より完全な全体像を把握するには、1つのリクエストと並列リクエストの平均応答時間を測定する必要があります。



わかりやすくするために、取得したデータを要約チャートにまとめます。このようにして、どのクエリが他のクエリよりもはるかに時間がかかっているかをすばやく特定できます。



サイトが強力なサーバーにインストールされている場合、100の並列要求の実行時間は、1つの要求の実行時間を大幅に超えてはなりません。この例では、30回の違いが見られます。最長のクエリを最初に調査する必要があります。







このプロジェクトでは、一部のリクエストでゲートウェイタイムアウトが発生しました。つまり、サーバーからの応答がまったく届きませんでした。



高負荷プロジェクトでのオーバーヘッドは正常です。ただし、1つのリクエストが複数のアクションを担当する場合は、可能な限り、リクエストをコンポーネントパーツに分割するようにしてください。これらの部分を並列スレッドで実行します。



サーバーを改善するために何ができるでしょうか？サーバーを監視してアプリケーションを再起動するためにライブラリを接続します（node.jsの場合、これはpm2です）。Sentryなどのエラー監視ツールを接続することもお勧めします。エラー出力と緊急シャットダウンログを構成します。このようにして、アプリケーションのダウンタイムを追跡できます。



理想的には、サイトでのアクティビティ（API要求、データベースへの要求、外部API、ファイルシステムまたはファイルシステムを操作するためのサービス）を監視する非同期ロガーを設定し、それらを別のデータベースに記録します。

ソースコードの静的分析

この分析は、間違ったコードを指摘し、「デッドコード」を取り除くのに役立つユーティリティによって実行されます。これらのツールは開発中に自動的に使用する必要があることに注意してください。ただし、開発者の整合性に常に依存する必要はないため、このチェックをスキップしないことをお勧めします。



静的分析を行うには、eslint linterや、コード違反を追跡するprettierやsonarなどの他のコードフォーマットユーティリティを使用する必要があります。



その結果、特定された違反に基づいて、ドキュメントを作成できます。







通常、このような違反はサイトのパフォーマンスに影響を与えませんが、コードの読み取りと書き込みが複雑になるため、保守に費用がかかります。たとえば、このプロジェクトでは、3つの引数があり、そのうちの1つは使用されていない関数が見つかりました。このような些細なことが一緒になって、プロジェクトの技術的負債が増加します。

ソースコードのセマンティック分析

この時点で、プログラマーはプロジェクトファイルを手動で調べる必要があります。ソースコードの動作の明らかなエラーのみが評価されることに注意してください。より詳細な分析を行うには、プロジェクトのロジックを十分に理解する必要があります。この段階で、1つの場所（クラス、関数、または定数）に移動して行数を減らすことができる反復コードを見つけることができます。バグの可能性を減らします。



この分析は、開発チームに問題があるかどうかを判断するのに役立つ場合があります。 Gitのコード行から、作成者が誰であるかを判別し、個々の従業員のパフォーマンスを判別できます。コメントの半分以上が1人の開発者に言及していることに気付くかもしれません。



たとえば、ここでは、データベースを更新する10個の非同期操作を特定しましたが、それらは一度に1つずつ実行され、相互に関連していませんでした。つまり、並列で実行することでパフォーマンスを2倍にすることができます。現在のPHPバージョンでも、システムパフォーマンスを向上させるために人工的な並列処理を設定できるため、可能な限り並列処理を使用してください。

結果

ソフトウェア開発には多くのリスクが伴います。実際には、プロジェクトを予定どおりに稼働させるために、妥協する必要があります。したがって、ドキュメントは通常遡及的に作成され、サイトの最適化は最後の瞬間まで延期されます。



しかし、パフォーマンスの向上に取り組むのに遅すぎることはありません。ウェブサイトをスピードアップすると、ユーザーエクスペリエンスが向上し、視聴者の反応が良くなります。技術監査の助けを借りて、サイトの作業の遅延の原因を特定できます-フロントエンドまたはバックエンドアプリケーション。フロントエンド監査の実施方法に関する推奨事項をまとめました。それらは本質的に一般的であり、あらゆるサイトのテストに適しています。



次回の出版物で、バックエンドの技術監査を実施する方法をすぐに説明します。