Web ページのリソース読み込みの最適化について簡単に説明します_html/css_WEB-ITnose

モバイル開発の非常に重要な部分は、リソース読み込みの最適化です。ネットワーク速度が遅い、帯域幅が大きい、遅延が長い、モバイル デバイスのメモリが少ない、プロセッサのパフォーマンスが低いなどの理由から、モバイル開発では、Web ページの読み込みに対するユーザーの期待に応えるために、フロントエンド ページのパフォーマンスを最適化する必要があることがよくあります。

少し前に関連する側面でいくつかの最適化を行ったところ、インターネット上に中国語のチュートリアルが比較的少ないことがわかり、それらはすべて Chrome 開発者の Web サイトを段階的にフォローし、解決すべき問題を見つけたので、いくつかの有用な Web ページを整理して翻訳しました。 。

1. Web ページの読み込み速度を確認します

Web ページの読み込み時間はネットワーク速度の影響を受けます。一般に、テスト前に結果をより正確に比較できるように、ブラウザを使用して特定のネットワーク速度をシミュレートします。そして最適化後。

方法: デバッグ パネルを開き、ネットワーク速度を選択します。通常、モバイル テストには通常の 3G を使用し、ページを更新してページの読み込み時間の確認を開始します。

リソースの読み込み順序と消費時間が順に表示されます。赤い線は DOM の読み込み時間を示します。

2. リソース読み込みのシーケンスと説明

リソースリクエストのライフサイクルは次のとおりです:

リダイレクト - アプリケーションキャッシュ - DNS - TCP - リクエスト - レスポンス

特定のリソースについては、リソースをクリックしますロード進行状況バーで、各ステージの具体的なロード時間を確認します。または、コンソール パネルのタイミング API を通じて取得することもできます。

performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))

具体的な説明は次のとおりです:

• キューイング: ブラウザーには接続制限があり、前のリソースがロードされて解放されるまでキューイングされたリソースは開始できません。聞く。重要なリソース (JavaScript や CSS など) よりも優先度の低いリクエストは、ブラウザーによって延期されます。通常、画像は延期されます。多くのリソースが同時にリクエストされた場合、ブラウザーはデフォルトで最初に CSS を読み込み、次に JavaScript、最後に画像を読み込みます。

• 停止: リクエストは送信される前にブロックされます。ブロックには、キューイングやプロキシ ネゴシエーションなど、さまざまな理由があります。

• DNS ルックアップ: Web リソースでリクエストされた新しいドメインごとに完全な DNS クエリが必要です。

• 初期接続: 初めて接続を確立するのにかかる時間。

• 送信されたリクエスト: ネットワーク リクエストが送信された時刻。

• Waiting(TFFB): サーバーの初期応答を待つ時間。

• コンテンツのダウンロード (ダウンロード時間): リソースのダウンロードにかかる時間。

3. 診断原因と解決策

Chrome ネットワーク パネルからデバッグすると、読み込み時間が毎回異なることがよくわかりますが、読み込みが遅い原因はたくさんあります。フロントエンドを最適化する必要がありますが、多くの場合、それはバックエンドまたはネットワークの問題です。

1. キューの問題

最も一般的な問題は、リソースのキューの問題です。 HTTP1.0/1.1 接続では、Chrome は同時に同じホストへの接続を 6 つまで許可します。Web ページに 12 個のリソースがある場合、リクエストを開始するには、前のダウンロードが完了するまで次の 6 個のリソースをキューに入れる必要があります。順序。この問題を解決するには、まず CSS スプライト、JS/CSS 圧縮、キャッシュ、オンデマンド読み込みなどの Web ページリクエストを減らす必要があります。

リソースを異なるサブドメインに配置する別の方法もあります。たとえば、画像リソースを静的リソースから分離すると、Web ページの読み込み時間を大幅に短縮できますが、この方法は HTTP2 接続には適用できません。

2. TFFB 時間が遅い

TFFB 時間は通常 200 ミリ秒未満であることが推奨され、推奨値を超えると、キュー内の他のリソースのダウンロードが遅くなります。 TFFB が高くなる主な理由は 2 つあります。1 つは、クライアントとサーバー間のネットワーク状態が比較的悪かったことです。2 つ目は、サーバー アプリケーションの応答が比較的遅かったことです。まずネットワーク要因を排除し、ローカル環境に TFFB がまだ存在するかどうかを確認します。存在する場合は、データベース クエリの最適化、リソース バッファリングの実装、Web サーバー構成の変更など、アプリケーションの応答時間を最適化する必要があります。ネットワークが原因の場合、サーバーとクライアント間のすべてのノードでこの問題が発生する可能性があります。最も簡単な方法は、アプリケーションを他のサーバーに移行して、この問題が存在するかどうかを確認し、ノードごとに原因を見つけることです。

3. ダウンロードに時間がかかりすぎる

ダウンロードに多くの時間が費やされる場合、サーバーの応答を改善するのは無駄であり、ファイルは圧縮されたままにする必要があります。

最後に

フロントエンドの最適化への道のりは長いです。敵はミリ秒ですが、征服するには 18 の武道が必要です。ただやってみて、考えてみてください。

参考: https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/ Understanding-resource-timing#diagnosing-network-issues