ホームページ > 記事 > ウェブフロントエンド > Web ページのリソース読み込みの最適化について簡単に説明します_html/css_WEB-ITnose
モバイル開発の非常に重要な部分は、リソース読み込みの最適化です。ネットワーク速度が遅い、帯域幅が大きい、遅延が長い、モバイル デバイスのメモリが少ない、プロセッサのパフォーマンスが低いなどの理由から、モバイル開発では、Web ページの読み込みに対するユーザーの期待に応えるために、フロントエンド ページのパフォーマンスを最適化する必要があることがよくあります。
少し前に関連する側面でいくつかの最適化を行ったところ、インターネット上に中国語のチュートリアルが比較的少ないことがわかり、それらはすべて Chrome 開発者の Web サイトを段階的にフォローし、解決すべき問題を見つけたので、いくつかの有用な Web ページを整理して翻訳しました。 。
Web ページの読み込み時間はネットワーク速度の影響を受けます。一般に、テスト前に結果をより正確に比較できるように、ブラウザを使用して特定のネットワーク速度をシミュレートします。そして最適化後。
方法: デバッグ パネルを開き、ネットワーク速度を選択します。通常、モバイル テストには通常の 3G を使用し、ページを更新してページの読み込み時間の確認を開始します。
リソースの読み込み順序と消費時間が順に表示されます。赤い線は DOM の読み込み時間を示します。
リソースリクエストのライフサイクルは次のとおりです:
リダイレクト - アプリケーションキャッシュ - DNS - TCP - リクエスト - レスポンス
特定のリソースについては、リソースをクリックしますロード進行状況バーで、各ステージの具体的なロード時間を確認します。または、コンソール パネルのタイミング API を通じて取得することもできます。
performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))
具体的な説明は次のとおりです:
キューイング: ブラウザーには接続制限があり、前のリソースがロードされて解放されるまでキューイングされたリソースは開始できません。聞く。重要なリソース (JavaScript や CSS など) よりも優先度の低いリクエストは、ブラウザーによって延期されます。通常、画像は延期されます。多くのリソースが同時にリクエストされた場合、ブラウザーはデフォルトで最初に CSS を読み込み、次に JavaScript、最後に画像を読み込みます。
停止: リクエストは送信される前にブロックされます。ブロックには、キューイングやプロキシ ネゴシエーションなど、さまざまな理由があります。
DNS ルックアップ: Web リソースでリクエストされた新しいドメインごとに完全な DNS クエリが必要です。
初期接続: 初めて接続を確立するのにかかる時間。
送信されたリクエスト: ネットワーク リクエストが送信された時刻。
Waiting(TFFB): サーバーの初期応答を待つ時間。
コンテンツのダウンロード (ダウンロード時間): リソースのダウンロードにかかる時間。
Chrome ネットワーク パネルからデバッグすると、読み込み時間が毎回異なることがよくわかりますが、読み込みが遅い原因はたくさんあります。フロントエンドを最適化する必要がありますが、多くの場合、それはバックエンドまたはネットワークの問題です。
最も一般的な問題は、リソースのキューの問題です。 HTTP1.0/1.1 接続では、Chrome は同時に同じホストへの接続を 6 つまで許可します。Web ページに 12 個のリソースがある場合、リクエストを開始するには、前のダウンロードが完了するまで次の 6 個のリソースをキューに入れる必要があります。順序。この問題を解決するには、まず CSS スプライト、JS/CSS 圧縮、キャッシュ、オンデマンド読み込みなどの Web ページリクエストを減らす必要があります。
リソースを異なるサブドメインに配置する別の方法もあります。たとえば、画像リソースを静的リソースから分離すると、Web ページの読み込み時間を大幅に短縮できますが、この方法は HTTP2 接続には適用できません。
TFFB 時間は通常 200 ミリ秒未満であることが推奨され、推奨値を超えると、キュー内の他のリソースのダウンロードが遅くなります。 TFFB が高くなる主な理由は 2 つあります。1 つは、クライアントとサーバー間のネットワーク状態が比較的悪かったことです。2 つ目は、サーバー アプリケーションの応答が比較的遅かったことです。まずネットワーク要因を排除し、ローカル環境に TFFB がまだ存在するかどうかを確認します。存在する場合は、データベース クエリの最適化、リソース バッファリングの実装、Web サーバー構成の変更など、アプリケーションの応答時間を最適化する必要があります。ネットワークが原因の場合、サーバーとクライアント間のすべてのノードでこの問題が発生する可能性があります。最も簡単な方法は、アプリケーションを他のサーバーに移行して、この問題が存在するかどうかを確認し、ノードごとに原因を見つけることです。
ダウンロードに多くの時間が費やされる場合、サーバーの応答を改善するのは無駄であり、ファイルは圧縮されたままにする必要があります。
フロントエンドの最適化への道のりは長いです。敵はミリ秒ですが、征服するには 18 の武道が必要です。ただやってみて、考えてみてください。
参考: https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/ Understanding-resource-timing#diagnosing-network-issues