フロントエンドのパフォーマンスの最適化-リソースのプリロード
フロントエンドのパフォーマンスの最適化に関しては、最初にファイルのマージ、圧縮、ファイルキャッシュ、サーバー側のgzip圧縮について考えます。これにより、ページの読み込みが速くなり、ユーザーはWebアプリケーションを使用してできるだけ早く目標を達成できます。 。
リソースのプリロードは別のパフォーマンス最適化手法です。この手法を使用して、特定のリソースが将来使用される可能性があることをブラウザーに通知できます。
パトリック・ハマンの説明を引用する：
プリロードは、ブラウザが将来使用する可能性のあるリソースへのヒントです。現在のページで使用されるリソースもあれば、将来使用される可能性のあるリソースもあります。開発者として、私たちはブラウザよりもアプリケーションをよく知っているので、このテクノロジーをコアリソースに使用できます。
この方法は、かつてはプリブラウジングと呼ばれていましたが、単一のテクノロジーではなく、DNSプリフェッチ、サブリソース、標準プリフェッチ、プリコネクト、プリレンダーなど、いくつかの異なるテクノロジーに細分化できます。
DNS事前解決DNS-プリフェッチ
は、DNS事前解決を通じて将来特定のURLからリソースを取得する可能性があることをブラウザに通知します。ブラウザが実際にドメイン内のリソースを使用する場合、できるだけ早くDNS解決を完了することができます。たとえば、将来example.comから画像や音声リソースを取得する可能性がある場合は、ドキュメントの上部にあるタグに次のコンテンツを追加できます。
ハリーロバーツの記事で言及：
簡単なコード行で、互換性のあるブラウザにDNS事前解決を実行するように指示できます。つまり、ブラウザが実際にドメイン内のリソースを要求したときに、DNS解決はすでに完了しています。
これは非常に小さなパフォーマンスの最適化のようで、それほど重要ではないようですが、そうではありません。Chromeは常に同様の最適化を行ってきました。ブラウザのアドレスバーにURLの短いセグメントを入力すると、ChromeはDNSの事前解決（またはページの事前レンダリング）を自動的に完了し、各リクエストの重要な時間を節約します。
事前接続
DNS事前解決と同様に、事前接続はDNS事前解決を完了するだけでなく、TCPハンドシェイクを実行し、トランスポート層プロトコルを確立します。これは次のように使用できます。
1 Ilya Grigorikの記事には、より詳細な紹介があります。最新のブラウザは、Webサイトが将来必要とする接続を予測し、ソケット接続を事前に確立して、高価なDNSルックアップ、TCPハンドシェイク、およびTLSラウンドトリップオーバーヘッドを排除しようとします。ただし、ブラウザは、各Webサイトのすべてのリンク前ターゲットを正確に予測するほどスマートではありません。幸い、Firefox39とChrome46では、事前接続を使用して、どの事前接続を行う必要があるかをブラウザに通知できます。
プリフェッチ
将来的に特定のリソースが使用されることが確実な場合は、事前にリソースを要求してブラウザのキャッシュに入れるようにブラウザに依頼することができます。たとえば、画像とスクリプト、またはブラウザでキャッシュできるリソースは次のとおりです。
1 DNSの事前解決とは異なり、実際のリクエストはプリフェッチされ、リソースがダウンロードされてキャッシュに保存されます。ただし、プリフェッチは条件によっても異なります。非常に遅いネットワークから巨大なフォントファイルをフェッチするなど、一部のプリフェッチはブラウザによって無視される場合があります。また、Firefoxは、ブラウザがアイドル状態のときにのみリソースをプリフェッチします。Bram Steinの投稿で述べたように、これはWebフォントのパフォーマンスの非常に明らかな改善です。現在、フォントファイルはダウンロードを開始する前にDOMとCSSがビルドされるまで待機する必要があります。プリフェッチを使用すると、このボトルネックを簡単に回避できます。
注：リソースのプリフェッチをテストするのは少し難しいですが、ChromeとFirefoxのネットワークパネルにリソースのプリフェッチの記録があります。また、プリフェッチされたリソースは同一生成元ポリシーによって制限されないことを覚えておく必要があります。
サブリソース
これは別のプリフェッチ方法です。この方法で指定されたプリフェッチされたリソースは最高の優先度を持ち、すべてのプリフェッチアイテムの前に実行されます。
1 Chromeのドキュメントによると：rel = prefetchは、将来のページに優先度の低いリソースのプリロード方法を提供し、rel = subresourceは、現在のページに優先度の高いリソースのプリロード方法を提供します。
したがって、現在のページにリソースが必要な場合、またはリソースをできるだけ早く使用可能にする必要がある場合は、プリフェッチではなくサブリソースを使用することをお勧めします。
事前レンダリング
prerenderはドキュメントのすべてのリソースをプリロードできるため、これは核兵器です。
1スティーブ・スーダーズは彼の記事の1つに次のように書いています。これは、非表示のタブページでリンクを開くのと似ています。すべてのリソースがダウンロードされ、DOM構造が作成され、ページレイアウトが完了し、CSSスタイルが適用され、JavaScriptスクリプトが実行されます。ユーザーが実際にリンクにアクセスすると、非表示のページが表示に切り替わり、ページがすぐに読み込まれたように見えます。グーグル検索は長年そのインスタント検索ページでこの技術を使用しており、マイクロソフトはまた、IE11でこの機能をサポートすると発表しました。
この機能を悪用しないでください。ユーザーがリンクをクリックすることがわかっている場合にのみ事前レンダリングを実行できます。そうしないと、ブラウザは事前レンダリングに必要なすべてのリソースを無条件にダウンロードします。
より関連する議論：
すべてのプリロードテクノロジーには潜在的なリスクがあります。リソースの予測が間違っており、プリロードのコスト（CPUリソースのプリエンプション、バッテリー消費、帯域幅の浪費など）が高いため、注意して進める必要があります。次のステップでユーザーがアクセスするリソースを決定することは困難ですが、信頼性の高いシナリオが存在します。
ユーザーが明らかな結果で検索を完了すると、結果ページが読み込まれる可能性があります。
ユーザーがランディングページに入ると、成功したランディングページが読み込まれる可能性があります。
ユーザーが複数ページの記事を読んだり、アクセスしたりすると、ページングされた結果セットの場合、次のページが読み込まれる可能性があります。
最後に、Page Visibility APIを使用すると、実際に表示される前にページが実行されるのを防ぐことができます。
プリロード
プリロードは新しい仕様です。プリフェッチ（無視される場合があります）とは異なり、ブラウザはリソースをプリロードする必要があります。
1仕様はすべてのブラウザと互換性があるわけではありませんが、その背後にある考え方は依然として非常に興味深いものです。総括する
ユーザーが次にアクセスするリソースを予測することは難しく、多くのテストが必要ですが、これによってパフォーマンスが向上することは明らかです。これらのプリフェッチ手法を試してみると、ユーザーエクスペリエンスが大幅に向上します。
-
ネットワークの待ち時間とネットワーク要求を減らします。
リダイレクトにランディングページを使用しないでください。
リダイレクトにより、追加のHTTPリクエストが発生し、ネットワーク遅延が発生し、Webページのレンダリングが遅くなります。リダイレクトにより、追加のDNSルックアップ、TCPハンドシェイク、およびTLSネゴシエーションが発生する場合もあります。
リソースを組み合わせてネットワーク要求を減らします
。リソースを組み合わせる最も一般的な方法はスプライトです。
さらに、CSSコードとJSコードをマージすることもできます。 -
リソースのダウンロード数の制御
Webページにアクセスするとき、要求されたリソースは、次のような無駄なリソース要求を回避するために役立つ必要があります。 -
余分な
jsファイル、cssファイル -
追加の写真リクエスト
-
追加のフォントリクエスト
-
リソース量の最適化
Webサイトで使用されるリソースは主に次のとおりです。
js、css、htmlなどのテキストリソース、
画像リソース、さまざまな画像
3.1テキストリソースの最適化
まず、もちろん、高品質で簡潔なコードを作成する必要があります。
次に、jsファイル、htmlファイル、およびcssファイルの場合、ファイルを最小化し、テキスト間のスペースと改行を削除し、変数名を置き換える必要があります。
これらのタスクは通常、次のようにフロントエンドプロジェクトがパッケージ化されたときに実行されます。
HTMLファイルはHTMLMinifierを使用し、
CSSファイルはWebpackにパッケージ化され、ローダーを最小化するように構成し
ます。JSファイルはUglifyJsPluginプラグインを使用します。
次のステップは、GZIPを使用してファイルをエンコードおよび圧縮することです。
最新のブラウザはgzip形式のファイルを受け入れることができ、サーバーを構成するだけです。
3.2
画像リソースの最適化適切な画像形式を選択する
png画像はjpge画像よりも写真画像をよりよく表すことができるとよく言われますが、多くの画像では、画像をわかりやすくするためにpng形式の画像をjpeg形式に変換します。大きな影響がありますが、ボリュームを大幅に減らすことができます。
不要なメタデータを削除する
撮影した写真の中には、データを説明するデータであるメタデータが含まれているものがあります。メタデータは、撮影した写真のデバイス情報、タイムスタンプ、画像サイズなどを記述します。これは、一部のWebページの写真ではそれほど重要ではないため、これらのメタデータを削除できます。
このウェブサイトVerExifをお試しください。
画像のサイズを小さく
する<img>タグやラベルの背景に大きな画像を使用しても、実際のWebページでのサイズも非常に小さい場合があります。この場合、大きな画像を使用すると、リソースの浪費。1200 x600ピクセルの画像を600x 300ピクセルに変更するなど、画像サイズをリセットすることができます。
画像の品質を低下させる
任意の視覚的な差が生じていない画像の品質を低下させる、いくつかのケースでは、それは、ボリュームの多くを減らすことができます。
次のような画質を扱う多くのソフトウェアがあります。
XNConvert
ImageOptim
Resizeltの
詳細については、こちらをご覧ください。
画像圧縮
gzip圧縮は画像には効果的ではありませんが、このWebサイトのように、画像のサイズや視覚的品質に影響を与えることなく画像を圧縮できるソフトウェアはまだたくさんあります。
その他のウェブサイトについては、[こちら]（
http：//enviragallery.com/9-be ... ）を参照してください。
- HTTPキャッシングの使用
厳密に言えば、これもリクエストの数を減らすと考えられていますが、実装は完全に異なります。
HTTPキャッシングの使用は、適切なキャッシング戦略を設定することです。これにより、ブラウザーがサーバーにリソースを繰り返し要求するのを防ぐことができます。
HTTPキャッシングは、主にサーバー側で正しい応答ヘッダー情報を設定することを目的としています。
キャッシングには、ストロングキャッシングとネゴシエーションキャッシングの2種類があります。
4.1強力なキャッシュ
強力なキャッシュとは、ブラウザがサーバーにリクエストを送信せずにローカルリソースを直接使用することを意味します。関連する2つの応答ヘッダーがあります：ExpiresとCache-control。
Expiresはhttp1.0のコンテンツであり、そのコンテンツはサーバーによって設定された特定の時間です。たとえば、Expires：Wed、21 Oct 2015 07:28:00 GMT、あまり知る必要はありません。
Cache-controlはhttp1.1によって追加された新しいヘッダーであり、その値は次のコマンドの1つまたは組み合わせです。
no-cache：ブラウザがコンテンツをキャッシュできることを示しますが、最初にサーバーに確認する必要があります。リソースが変更されていない場合は、ブラウザのキャッシュを直接使用できます。no-storeと相互に排他的;
no-store：ブラウザとプロキシサーバーなどの中間デバイスを含むコンテンツのキャッシュが許可されていないことを
示し、no-cacheと相互に排他的; public：キャッシュが可能であることを示しますブラウザと中間デバイスに存在し、privateは相互に排他的です
。private：キャッシュがクライアントのブラウザにのみ存在できることを示します
。max-age：キャッシュされたコンテンツの有効期限を示す時間範囲（秒単位）。有効期限が切れると、ブラウザはリソースを再度ダウンロードする必要があります。
強力なキャッシュを設定した後、ブラウザはローカルにキャッシュされたコンテンツを使用するか、各リクエストに対して返されたヘッダー情報に基づいてブラウザを確認します。
4.2ネゴシエーションキャッシュ
サーバーがリソースに強力なキャッシュを設定していない場合は、ネゴシエーションキャッシュを使用できます。ネゴシエーションキャッシュを有効にするには、次の2つの方法があります。
Last-ModifiedおよびIf-Modified-Since;
EtagおよびIf-None-Match;
2セットのヘッダー情報の名前は非常にセマンティックであるため、理解の難しさが軽減されます。
4.2.1 Last-ModifiedおよびIf-Modified-Since
サーバーは、Last-Modified応答ヘッダーを設定して、リソースが最後に変更された時刻を示します。この値は特定の時点です。ブラウザが要求すると、ヘッダーIf-Modified-Sinceが表示され、その値はLast-Modifiedの値になります。サーバーは、リソースの最終変更時刻をIf-Modified-Sinceで示される時刻と比較し、変更されていない場合は304を返します。
4.2.1 EtagとIf-None-Match
サーバーはEtag応答ヘッダーを設定して、リソースの一意の識別文字列を示します。リソースが変更されている限り、Etagは再生成されます。ブラウザが要求すると、ヘッダーIf-None-Matchが表示されます。このヘッダーの値は、Etagの値です。サーバーは、リソースの現在のEtag値とIf-None-Match値を比較し、それらが一致する場合は304を返します。