最近、私は「高性能ウェブサイトの建設のガイド」という本を勉強しています。この記事は調査メモです。後で簡単に視聴するために学んだことを整理します。
パフォーマンスゴールデンルールは、エンドユーザーの応答時間の10％から20％のみが要求されたユーザーHTMLドキュメントを受け入れ、残りの80％から90％の時間は、HTMLドキュメントで参照されるすべてのコンポーネント（画像、スクリプト、スタイルシートなど）のHTTP要求に費やされ、エンドユーザーの応答時間はポージに費やされます。
- スティーブサウンダー
1ファイルマージ（HTTPリクエストの数を減らす）
CSSスプライト
CSSスプライトを使用して、ウェブサイトで使用されている画像を1つの画像にマージし、背景ポジション、幅、高さを介してアイコンを使用して背景画像位置を制御します。この方法では、複数の画像要求を1回まで減らすことができます。 CSSスプライトを生成するための多くのツールがあります。 GruntとGulpには関連するプラグインがあり、Cssgagaも良いです。
JSとCSSをマージします
Spriteマップと同様に、CSSとJSファイルのマージもHTTP要求を減らす重要な方法です。現在、CSSファイルの合併に関する論争はありませんが、JSモジュール性の現在の有病率のために、すべてのJSファイルを1つのファイルに統合することは逆向きのようです。正しい方法は、コンパイルされた言語パターンを遵守し、JSのモジュール性を維持し、生成プロセス中に初期リクエストで使用されたJSファイルに対してのみターゲットファイルを生成することです。
2コンテンツを使用してネットワークを公開します（HTTP要求時間を短縮）
HTTP要求時間に影響を与えるもう1つの要因は、WebサイトWebサーバーからの距離です。明らかに、距離が長いほど、リクエストが長くなり、CDNを通じて大幅に改善できます。
CDNは、複数の地理的位置に配布されたWebサーバーであり、より効果的にユーザーにコンテンツを公開するために使用されます。 CDNの主な機能は、エンドユーザー向けの静的ファイルを保存することであり、ダウンロード、セキュリティサービス、その他の機能も提供します。
3ブラウザキャッシュを設定します（重複したHTTPリクエストを避けます）
有効期限/キャッシュ制御を使用します
ブラウザは、キャッシュを使用して、毎回繰り返されるリクエストを回避できます。 HTTP 1.0およびHTTP 1.1には、キャッシュの実装方法が異なり、有効期限（1.0）とキャッシュコントロール（1.1）があります。 Webサーバーは、有効期限が切れ、ファイルのすべてのキャッシュコピーが指定された時間内に使用され、たとえば次のように繰り返しサーバーにリクエストを行うことがないことをクライアントに伝えます。
期限切れ：木、2016年12月1日16:00:00 GMT（GMT形式）
この設定は、2016年12月1日の時点で、キャッシュされたコピーが利用可能であることを意味します。
期限切れには締め切りに制限があります。クライアントクロックとサーバークロック間の厳密な同期が必要です。一方、HTTP 1.1によって導入されたキャッシュコントロールは、数秒単位で時間を指定することでキャッシュ日付を指定します。
キャッシュコントロール：MAX-AGE = 31536000
この設定は、キャッシュ時間が1年であることを意味し、キャッシュコントロールを使用することをお勧めしますが、HTTP 1.1がサポートされる場合は、別のことに注意する必要があります。
ETAGを構成または削除します
Expire/Cache-Controlを使用すると、2回目の訪問を回避し、ローカルキャッシュを使用してHTTP要求の重複を避け、Webサイトの速度を向上させることができます。ただし、ユーザーがブラウザの更新または有効期限をクリックした場合、HTTP GETリクエストがサーバーに発行されます。現時点でファイルが変更されない場合、サーバーはファイル全体を返さず、304変更されていないステータスコードを返します。
サーバーには、ファイルが変更されたかどうかを判断するための2つのBasissがあります。既存修正（最新の変更日）とETAG（エンティティタグ）。
ETAG（エンティティタグ）はHTTP 1.1で導入され、ラスト修飾と同時に存在する場合、より高い優先度があります。サーバーは、クライアントが現在のETAGで送信したETAG（if-none-match）を比較し、同じことが真である場合は変更されていない304を返します。そうしないと、ファイル全体と200 OKが返されます。
ETAGには問題があります。ブラウザがGETリクエストを1つのサーバーに送信し、別のサーバーからコンポーネントを要求すると、ETAGは一致しません。もちろん、Webサイトが1つのサーバーでホストされていて、現在多くのWebサイトが複数のサーバーを使用している場合、ETAGの存在は検証の有効性の成功率を大幅に削減します。
この問題の解決策は、ETAGを構成し、サーバーイノード値を削除し、修正タイムスタンプとサイズをETAG値として保持するか、ETAGを直接削除し、ファイルの有効性を確認するためにラスト修飾を使用することです。
4つのコンポーネントを圧縮する（HTTP要求サイズを削減）
HTTPトランスメイトファイルを圧縮し、HTTP要求のサイズを縮小し、リクエスト速度を改善することにより、GZIPは現在最も一般的に使用され、最も効果的な圧縮方法です。
ただし、すべてのリソースファイルを圧縮する必要はありません。圧縮のコストには、サーバーがCPUサイクルを使用して圧縮する必要があることも含まれます。また、クライアントは、独自のWebサイトと組み合わせて計量する必要があります。現在、ほとんどのWebサイトはHTMLドキュメントを圧縮し、一部のWebサイトはJSとCSSを圧縮することを選択しています。写真、PDF、その他のファイルにGZIP圧縮を使用するWebサイトはほとんどありません。その理由は、これらのファイルが圧縮されており、HTTPを使用して圧縮されたものを圧縮することはそれを小さくすることができないからです。実際、ヘッダーを追加し、辞書を圧縮し、応答本体を確認すると、実際に大きくなり、CPUも無駄になります。
WebサイトでGZIPを有効にする方法には、Webサーバー（IIS、Nginx、Apacheなど）で設定する必要があります。
5つのCSSファイルが最初に配置されます
CSSファイルを最初と最後に配置しても、HTTP要求には影響しないため、リクエスト時間の観点から一貫しています。ただし、ユーザーエクスペリエンスの観点からは、CSSファイルを最初に配置すると、ユーザーエクスペリエンスが向上します。
その理由は、ブラウザがHTMLドキュメントを上から下まで解析し、CSSファイルをヘッドに配置するためです。ページは最初にCSSファイルにリクエストを行い、次にDOMツリーをロードしてレンダリングします。ページは徐々にユーザーに表示されます。
それどころか、CSSファイルが最後に配置されている場合、ページは完全なDOMをロードしてCSSファイルを要求し、DOMツリー全体をレンダリングしてユーザーに提示します。ユーザーの観点からは、CSSファイルが要求される前に、ページ全体が白い画面状態になります。白い画面はブラウザの動作です。デビッド・ハイアットの説明はこんな感じです
スタイルツリーが完全にロードされる前に、スタイルツリーがロードされた後に再びレンダリングされるため、DOMツリーをレンダリングすることは無駄です。
注意すべきもう1つのことは、@importの代わりにリンクを使用してCSS StyleSheetsを導入することです。 @Importによって導入されたスタイルがヘッダーに書かれている場合でも、ドキュメントの最後にロードされます。
6 JSファイルは最後に配置されます
HTTPリクエストは並行しており、異なるブラウザの並列ダウンロードの数は異なります（2、4、または8）。並列ダウンロードは、HTTPリクエストの速度を改善します。 JSファイルを最初に配置すると、後続のファイルのダウンロードをブロックするだけでなく、ページのレンダリングもブロックします。
なぜこれが起こっているのですか？ 2つの理由があります。
document.writeは、ページのコンテンツを変更するためにJSファイルに存在する可能性があるため、スクリプトが実行された後にページはレンダリングされません。
異なるJSファイルにはサイズに関係なく依存関係がある場合があるため、順番に実行する必要があるため、スクリプトをロードすると禁止されています。
したがって、最良の方法は、JSファイルを最後に配置し、ユーザーエクスペリエンスを改善するためのリクエストを行う前に、ページのすべての視覚コンポーネントがロードされるまで待つことです。
上記は、編集者があなたに紹介したJavaScriptによるWebサイトのパフォーマンスの改善に関するいくつかの提案です（1）。それがあなたに役立つことを願っています。もっと知りたい場合は、wulin.comに注意してください。次の記事では、編集者がJavaScript（II）のウェブサイトのパフォーマンスの最適化を改善するための提案を紹介します