Webフロントエンド性能&SEO最適化(一)
5605 ワード
移動先:https://www.2cto.com/kf/201604/498725.html && https://www.cnblogs.com/EnSnail/p/5671345.html
ブラウザアクセスの最適化
ブラウザ要求処理の流れは下図の通り:
1.http要求を減らし、HTTPキャッシュを合理的に設定する
httpプロトコルは無状態のアプリケーション層プロトコルであり、httpリクエストのたびに通信リンクを確立し、データ伝送を行う必要があることを意味し、サーバ側では、httpごとに独立したスレッドを起動して処理する必要がある.これらの通信およびサービスのオーバーヘッドはいずれも高価であり、httpリクエストの数を減らすことでアクセス性能を効果的に向上させることができる.
httpを減らす主な手段はCSSのマージ、javascriptのマージ、ピクチャのマージです.ブラウザの1回のアクセスに必要なjavascriptとCSSを1つのファイルに統合することで、ブラウザは1回のリクエストしか必要ありません.画像を合成することもでき、複数の画像を1枚に合成することもでき、各画像に異なるハイパーリンクがあれば、CSSオフセットでマウスのクリック操作に応答し、異なるURLを構築することができます.キャッシュの力は強く、適切なキャッシュ設定でHTTPリクエストを大幅に削減できます.あるウェブサイトのトップページを仮定すると、ブラウザがキャッシュされていない場合、アクセスは合計78件、合計600件以上のKデータを発行し、2回目のアクセス、すなわちブラウザがキャッシュされた後にアクセスすると10件の要求、合計20件以上のKデータしかありません.(ここで説明する必要があるのは、直接F 5でページをリフレッシュすると効果が異なる場合であり、この場合もリクエスト数は同じであるが、キャッシュされたリソースのリクエストサーバは304応答であり、HeaderのみBodyがなく、帯域幅を節約できる)
どのようにして合理的に設定しますか?原則は簡単で、キャッシュできるものが多ければ多いほど、キャッシュできるものが長ければ長いほどいいです.例えば、ほとんど変化しない画像リソースは、HTTPヘッダのExpiresを通じて長い期限切れヘッダを直接設定することができる.変更が頻繁ではなく、変更される可能性のあるリソースは、Last-Modifedを使用してリクエスト検証を行うことができます.可能な限り、リソースをキャッシュに長く滞在させることができます.HTTPキャッシュの具体的な設定と原理についてはここでは詳述しない.
2、ブラウザキャッシュを使う
1つのWebサイトでは、CSS、javascript、logo、アイコンなどの静的リソースファイルの更新頻度が低く、これらのファイルはhttpリクエストのたびにほとんど必要であり、ブラウザにキャッシュすれば、パフォーマンスを向上させることができます.httpヘッダのcache-controlとexpiresのプロパティを設定することで、ブラウザキャッシュを設定できます.キャッシュ時間は数日、数ヶ月です.
静的リソースファイルの変更は、クライアントブラウザにタイムリーに適用する必要がある場合があります.この場合、javascriptファイルを更新することは、javascriptファイルの内容を更新するのではなく、新しいJSファイルを生成し、HTMLファイルの参照を更新することによって実現できます.ブラウザキャッシュポリシーを使用するウェブサイトは、静的リソースを更新する際に、10個のアイコンファイルを更新する必要があるなど、量単位で更新する方法を採用しなければならない.サーバ負荷が急増し、ネットワークが詰まっている場合.
3、圧縮を有効にする
サーバ側でファイルを圧縮し、ブラウザ側でファイルを解凍することで、通信伝送のデータ量を効果的に減らすことができます.できれば、できるだけ外部のスクリプト、スタイルを統合し、複数を1つにします.テキストファイルの圧縮効率は80%以上になるため、HTML、CSS、javascriptファイルはGZip圧縮を有効にすると良い効果が得られます.しかし,圧縮はサーバとブラウザに一定の圧力を生じ,通信帯域幅が良好であり,サーバリソースが不足している場合に考慮しなければならない.
4、 CSS Sprites
CSSピクチャをマージして、リクエスト数を減らすもう一つの良い方法です.
5、Lazy Load Images
このポリシーは、実際にはHTTPリクエスト数を減らすとは限らないが、いくつかの条件やページがロードされたばかりのときにHTTPリクエスト数を減らすことができる.画像の場合、ページがロードされたばかりのときに第1の画面のみをロードすることができ、ユーザーが画面をスクロールし続けるときに後続の画像をロードすることができます.これにより,ユーザが第1画面のコンテンツにのみ興味を持っている場合,残りのピクチャリクエストは節約される.
6、CSSはページの一番上に、javascriptはページの一番下に
ブラウザは、すべてのCSSをダウンロードしてからページ全体をレンダリングするので、CSSをページの一番上に置いて、ブラウザができるだけ早くCSSをダウンロードできるようにするのが最善です.BODYなどの他の場所にCSSを配置すると、ブラウザがCSSをダウンロードして解析せずにページのレンダリングを開始している可能性があります.これにより、ページがCSSなし状態からCSS状態に遷移し、ユーザー体験が悪くなるため、HEADにCSSを配置することが考えられます.
Javascriptは逆に、ブラウザがjavascriptをロードした直後に実行すると、ページ全体がブロックされ、ページの表示が遅くなる可能性があるので、javascriptはページの一番下に置くのが望ましい.しかし、ページ解析でjavascriptを使用する必要がある場合は、下部に置くのは適切ではありません.
Lazy Load Javascript(ロードが必要な場合にのみロードされ、一般的には情報コンテンツはロードされません.)Javascriptフレームワークの流行に伴い、ますます多くのサイトがフレームワークを使用しています.しかし、1つのフレームワークには多くの機能実装が含まれています.これらの機能はすべてのページに必要ではありません.不要なスクリプトをダウンロードすると、リソースの浪費となります.帯域幅を浪費し、実行にかかる時間を浪費します.現在のやり方は、特にトラフィックの大きいページのために専用のmini版フレームワークをカスタマイズすることと、Lazy Loadをカスタマイズすることの2つがあります.
7、非同期要求Callback
一部のページでは、scriptラベルを使用して非同期のリクエストデータを使用する必要がある場合があります.類似:
以上のようにページに直接書きます
8、クッキーの伝送を減らす
一方、クッキーは各リクエストと応答に含まれており、クッキーが大きすぎるとデータ伝送に深刻な影響を及ぼすため、クッキーに書き込む必要があるデータは慎重に考慮し、クッキーで伝送されるデータ量をできるだけ減らす必要がある.一方、CSS、scriptなどの静的リソースへのアクセスについては、クッキーを送信する意味がなく、静的リソースが独立したドメイン名アクセスを使用することを考慮して、静的リソースを要求する際にクッキーを送信することを回避し、クッキーの伝送回数を減らすことができる.
9、Javascriptコードの最適化
(1). DOM a.HTML Collection(HTMLコレクタ、配列コンテンツ情報を返す)はスクリプト中でdocument.images、document.forms、getElementsByTagName()は、HTML Collectionタイプのコレクションを返します.lengthプロパティがあるため、インデックスを使用して各要素にアクセスすることもできます.ただし、このセットのマージは静的な結果ではなく、特定のクエリーのみを表し、そのセットにアクセスするたびにクエリーを再実行してクエリー結果を更新するため、アクセスパフォーマンスは配列よりも劣っています.いわゆる「アクセス・コレクション」には、コレクションのlength属性を読み出し、コレクション内の要素にアクセスする要素が含まれます.したがって、HTML Collectionを巡回する必要がある場合は、できるだけ配列に変換してアクセスし、パフォーマンスを向上させます.配列に変換しなくても、ループ時にlengthプロパティ、メンバーをローカル変数に保存してからローカル変数を使用するなど、できるだけアクセスを少なくしてください.b.Reflow&Repoint上記の点に加えて、DOM操作はブラウザのReflowとRepointを考慮する必要があります.これらはリソースを消費する必要があるからです.
(2). 慎重にwith with(obj){p=1};コードブロックの動作は,実際にはコードブロック内の実行環境を修正し,objをその役割ドメインチェーンの最前端に配置し,withコードブロック内で非局所変数にアクセスするにはobj上から先に検索を開始し,それ以上順番に役割ドメインチェーン上を検索しなければ,withを使用することは役割ドメインチェーン長を増加させることに相当する.一方、役割ドメインチェーンを検索するたびに時間がかかり、役割ドメインチェーンが長すぎると検索性能が低下します.したがって、withコードでobjのプロパティのみにアクセスできると確信していない限り、withを慎重に使用し、ローカル変数を使用してアクセスする必要があるプロパティをキャッシュすることができます.
(3). evalとFunctionを使用して、文字列で表されるソースコードにevalまたはFunctionコンストラクタが作用するたびに、スクリプトエンジンがソースコードを実行可能コードに変換する必要があることを回避します.これは、単純な関数呼び出しよりも通常100倍以上遅いリソースを消費する操作です.eval関数の効率は特に低く、evalに渡される文字列の内容が事前に分からないため、evalはそのコンテキストで処理するコードを解釈し、つまりコンパイラはコンテキストを最適化できないため、ブラウザが実行時にコードを解釈するしかない.これはパフォーマンスに大きな影響を及ぼします.Functionコンストラクション関数はevalよりやや良いです.このコードを使用すると周囲のコードに影響しないからです.しかし、その速度はまだ遅い.また、evalおよびFunctionの使用はJavascript圧縮ツールの圧縮にも不利です.
ブラウザアクセスの最適化
ブラウザ要求処理の流れは下図の通り:
1.http要求を減らし、HTTPキャッシュを合理的に設定する
httpプロトコルは無状態のアプリケーション層プロトコルであり、httpリクエストのたびに通信リンクを確立し、データ伝送を行う必要があることを意味し、サーバ側では、httpごとに独立したスレッドを起動して処理する必要がある.これらの通信およびサービスのオーバーヘッドはいずれも高価であり、httpリクエストの数を減らすことでアクセス性能を効果的に向上させることができる.
httpを減らす主な手段はCSSのマージ、javascriptのマージ、ピクチャのマージです.ブラウザの1回のアクセスに必要なjavascriptとCSSを1つのファイルに統合することで、ブラウザは1回のリクエストしか必要ありません.画像を合成することもでき、複数の画像を1枚に合成することもでき、各画像に異なるハイパーリンクがあれば、CSSオフセットでマウスのクリック操作に応答し、異なるURLを構築することができます.キャッシュの力は強く、適切なキャッシュ設定でHTTPリクエストを大幅に削減できます.あるウェブサイトのトップページを仮定すると、ブラウザがキャッシュされていない場合、アクセスは合計78件、合計600件以上のKデータを発行し、2回目のアクセス、すなわちブラウザがキャッシュされた後にアクセスすると10件の要求、合計20件以上のKデータしかありません.(ここで説明する必要があるのは、直接F 5でページをリフレッシュすると効果が異なる場合であり、この場合もリクエスト数は同じであるが、キャッシュされたリソースのリクエストサーバは304応答であり、HeaderのみBodyがなく、帯域幅を節約できる)
どのようにして合理的に設定しますか?原則は簡単で、キャッシュできるものが多ければ多いほど、キャッシュできるものが長ければ長いほどいいです.例えば、ほとんど変化しない画像リソースは、HTTPヘッダのExpiresを通じて長い期限切れヘッダを直接設定することができる.変更が頻繁ではなく、変更される可能性のあるリソースは、Last-Modifedを使用してリクエスト検証を行うことができます.可能な限り、リソースをキャッシュに長く滞在させることができます.HTTPキャッシュの具体的な設定と原理についてはここでは詳述しない.
2、ブラウザキャッシュを使う
1つのWebサイトでは、CSS、javascript、logo、アイコンなどの静的リソースファイルの更新頻度が低く、これらのファイルはhttpリクエストのたびにほとんど必要であり、ブラウザにキャッシュすれば、パフォーマンスを向上させることができます.httpヘッダのcache-controlとexpiresのプロパティを設定することで、ブラウザキャッシュを設定できます.キャッシュ時間は数日、数ヶ月です.
静的リソースファイルの変更は、クライアントブラウザにタイムリーに適用する必要がある場合があります.この場合、javascriptファイルを更新することは、javascriptファイルの内容を更新するのではなく、新しいJSファイルを生成し、HTMLファイルの参照を更新することによって実現できます.ブラウザキャッシュポリシーを使用するウェブサイトは、静的リソースを更新する際に、10個のアイコンファイルを更新する必要があるなど、量単位で更新する方法を採用しなければならない.サーバ負荷が急増し、ネットワークが詰まっている場合.
3、圧縮を有効にする
サーバ側でファイルを圧縮し、ブラウザ側でファイルを解凍することで、通信伝送のデータ量を効果的に減らすことができます.できれば、できるだけ外部のスクリプト、スタイルを統合し、複数を1つにします.テキストファイルの圧縮効率は80%以上になるため、HTML、CSS、javascriptファイルはGZip圧縮を有効にすると良い効果が得られます.しかし,圧縮はサーバとブラウザに一定の圧力を生じ,通信帯域幅が良好であり,サーバリソースが不足している場合に考慮しなければならない.
4、 CSS Sprites
CSSピクチャをマージして、リクエスト数を減らすもう一つの良い方法です.
5、Lazy Load Images
このポリシーは、実際にはHTTPリクエスト数を減らすとは限らないが、いくつかの条件やページがロードされたばかりのときにHTTPリクエスト数を減らすことができる.画像の場合、ページがロードされたばかりのときに第1の画面のみをロードすることができ、ユーザーが画面をスクロールし続けるときに後続の画像をロードすることができます.これにより,ユーザが第1画面のコンテンツにのみ興味を持っている場合,残りのピクチャリクエストは節約される.
6、CSSはページの一番上に、javascriptはページの一番下に
ブラウザは、すべてのCSSをダウンロードしてからページ全体をレンダリングするので、CSSをページの一番上に置いて、ブラウザができるだけ早くCSSをダウンロードできるようにするのが最善です.BODYなどの他の場所にCSSを配置すると、ブラウザがCSSをダウンロードして解析せずにページのレンダリングを開始している可能性があります.これにより、ページがCSSなし状態からCSS状態に遷移し、ユーザー体験が悪くなるため、HEADにCSSを配置することが考えられます.
Javascriptは逆に、ブラウザがjavascriptをロードした直後に実行すると、ページ全体がブロックされ、ページの表示が遅くなる可能性があるので、javascriptはページの一番下に置くのが望ましい.しかし、ページ解析でjavascriptを使用する必要がある場合は、下部に置くのは適切ではありません.
Lazy Load Javascript(ロードが必要な場合にのみロードされ、一般的には情報コンテンツはロードされません.)Javascriptフレームワークの流行に伴い、ますます多くのサイトがフレームワークを使用しています.しかし、1つのフレームワークには多くの機能実装が含まれています.これらの機能はすべてのページに必要ではありません.不要なスクリプトをダウンロードすると、リソースの浪費となります.帯域幅を浪費し、実行にかかる時間を浪費します.現在のやり方は、特にトラフィックの大きいページのために専用のmini版フレームワークをカスタマイズすることと、Lazy Loadをカスタマイズすることの2つがあります.
7、非同期要求Callback
一部のページでは、scriptラベルを使用して非同期のリクエストデータを使用する必要がある場合があります.類似:
class="hljs javascript"> Javascript:
/*Callback */
function myCallback(info){
//do something here
}
HTML:
Callback :
myCallback('Hello world!');code>以上のようにページに直接書きます
8、クッキーの伝送を減らす
一方、クッキーは各リクエストと応答に含まれており、クッキーが大きすぎるとデータ伝送に深刻な影響を及ぼすため、クッキーに書き込む必要があるデータは慎重に考慮し、クッキーで伝送されるデータ量をできるだけ減らす必要がある.一方、CSS、scriptなどの静的リソースへのアクセスについては、クッキーを送信する意味がなく、静的リソースが独立したドメイン名アクセスを使用することを考慮して、静的リソースを要求する際にクッキーを送信することを回避し、クッキーの伝送回数を減らすことができる.
9、Javascriptコードの最適化
(1). DOM a.HTML Collection(HTMLコレクタ、配列コンテンツ情報を返す)はスクリプト中でdocument.images、document.forms、getElementsByTagName()は、HTML Collectionタイプのコレクションを返します.lengthプロパティがあるため、インデックスを使用して各要素にアクセスすることもできます.ただし、このセットのマージは静的な結果ではなく、特定のクエリーのみを表し、そのセットにアクセスするたびにクエリーを再実行してクエリー結果を更新するため、アクセスパフォーマンスは配列よりも劣っています.いわゆる「アクセス・コレクション」には、コレクションのlength属性を読み出し、コレクション内の要素にアクセスする要素が含まれます.したがって、HTML Collectionを巡回する必要がある場合は、できるだけ配列に変換してアクセスし、パフォーマンスを向上させます.配列に変換しなくても、ループ時にlengthプロパティ、メンバーをローカル変数に保存してからローカル変数を使用するなど、できるだけアクセスを少なくしてください.b.Reflow&Repoint上記の点に加えて、DOM操作はブラウザのReflowとRepointを考慮する必要があります.これらはリソースを消費する必要があるからです.
(2). 慎重にwith with(obj){p=1};コードブロックの動作は,実際にはコードブロック内の実行環境を修正し,objをその役割ドメインチェーンの最前端に配置し,withコードブロック内で非局所変数にアクセスするにはobj上から先に検索を開始し,それ以上順番に役割ドメインチェーン上を検索しなければ,withを使用することは役割ドメインチェーン長を増加させることに相当する.一方、役割ドメインチェーンを検索するたびに時間がかかり、役割ドメインチェーンが長すぎると検索性能が低下します.したがって、withコードでobjのプロパティのみにアクセスできると確信していない限り、withを慎重に使用し、ローカル変数を使用してアクセスする必要があるプロパティをキャッシュすることができます.
(3). evalとFunctionを使用して、文字列で表されるソースコードにevalまたはFunctionコンストラクタが作用するたびに、スクリプトエンジンがソースコードを実行可能コードに変換する必要があることを回避します.これは、単純な関数呼び出しよりも通常100倍以上遅いリソースを消費する操作です.eval関数の効率は特に低く、evalに渡される文字列の内容が事前に分からないため、evalはそのコンテキストで処理するコードを解釈し、つまりコンパイラはコンテキストを最適化できないため、ブラウザが実行時にコードを解釈するしかない.これはパフォーマンスに大きな影響を及ぼします.Functionコンストラクション関数はevalよりやや良いです.このコードを使用すると周囲のコードに影響しないからです.しかし、その速度はまだ遅い.また、evalおよびFunctionの使用はJavascript圧縮ツールの圧縮にも不利です.