01. HTTP リクエストを最小限に抑える HTTP リクエストを減らす
画像、CSS、スクリプト、Flash などの要素の数を減らすと、応答時間が短縮される可能性があります。可能であれば、複数の JS と CSS を 1 つのファイルに記述します。また、画像を CSS に直接記述し、CSS スプライトを使用して小さな画像を組み立ててから、背景を使用して位置を見つけることも推奨されません。 「イメージ マップ」を使用します (同じ画像に異なる URL を配置することで、この方法により画像のリクエストの数を減らすことができます。テスト後、イメージ マップを取得する時間は、個々の画像を取得する時間より 56% 速くなりました。イメージ マップ2つの方法があり、1つは「サーバーサイドイメージマップ」、もう1つは「クライアントサイドイメージマップ」です。サーバーサイドの実装は、ユーザーがクリックしたXY座標をサーバーに渡し、その後サーバーに渡します。サイドは対応する操作をマップします。フォアグラウンドで MAP タグを使用すると、プログラミングのメンテナンスがはるかに困難になります)。
02. CDN テクノロジーを使用したコンテンツ配信ネットワークを使用する
「コンテンツ配信ネットワーク」。その目的は、既存のインターネットにネットワーク アーキテクチャの新しい層を追加することにより、Web サイトのコンテンツをユーザーに最も近いネットワーク「エッジ」に公開することです。
CDN の特徴:
1. ローカル キャッシュの高速化 – 企業サイト (特に、大量の画像や静的ページを含むサイト) のアクセス速度が向上し、上記の性質のサイトの安定性が大幅に向上します。
2. ミラーリング サービス – 異なる通信事業者間の相互接続のボトルネックの影響を排除し、通信事業者間のネットワークの高速化を実現し、異なるネットワークのユーザーが良好なアクセス品質を確保できるようにします。
3. リモート アクセラレーション – リモート アクセス ユーザーは、DNS 負荷分散テクノロジに基づいてキャッシュ サーバーをインテリジェントかつ自動的に選択し、最速のキャッシュ サーバーを選択してリモート アクセスを高速化します。
4. 帯域幅の最適化 – サーバー用のリモート ミラー キャッシュ サーバーを自動的に生成し、リモート ユーザーがアクセスするときにキャッシュ サーバーからデータを読み取り、リモート アクセスの帯域幅を削減し、ネットワーク トラフィックを共有し、元のサイトの WEB サーバーの負荷を軽減します。 、など。
5. クラスター攻撃対策 – 広範囲に分散された CDN ノードとノード間のインテリジェントな冗長性メカニズムにより、ハッカーの侵入を効果的に防止し、Web サイトに対するさまざまな DDOS 攻撃の影響を軽減しながら、良好なサービス品質を確保できます。
03. Expires または Cache-Control ヘッダーを追加して、「ヘッダー ファイルの有効期限」または「静的キャッシュ」を設定します。
ブラウザはキャッシュを使用して HTTP リクエストの数を減らし、ページの読み込み時間を短縮します。ページのヘッダーに長い有効期限が追加されている場合、ブラウザーは常にページ内の要素をキャッシュします。ただし、ページ上の何かが変更された場合は、名前を変更する必要があります。変更しないと、クライアントはアクティブに更新されません。
(1) コンセプト
Cache-control は HTTP キャッシュを制御するために使用されます (HTTP/1.0 では部分的に実装されていない可能性があります。Pragma: no-cache のみが実装されています)。
形式: キャッシュ制御: キャッシュディレクティブ
キャッシュディレクティブは次のようになります。
以下をリクエストするときに使用されます。
| 「キャッシュなし」
| 「無店舗」
| “max-age” “=” デルタ秒
| "max-stale" [ "= デルタ秒 ]
| “min-fresh” “=” デルタ秒
| 「変換なし」
| 「キャッシュされた場合のみ」
| "キャッシュ拡張"
応答で使用されます:
|「公共」
| "プライベート" [ "=" <"> フィールド名 <"> ]
| "キャッシュなし" [ "=" <"> フィールド名 <"> ]
| 「無店舗」
| 「変換なし」
| 「再検証する必要があります」
| "プロキシの再検証"
| “max-age” “=” デルタ秒
| “s-maxage” “=” デルタ秒
| "キャッシュ拡張"
部分的な説明:
キャッシュできるかどうかで分ける
Public は、応答を任意のキャッシュにキャッシュできることを示します。
プライベートは、単一ユーザーの応答メッセージの全部または一部が共有キャッシュで処理できないことを示します。これにより、サーバーは、他のユーザーのリクエストには無効なユーザーからの部分的な応答のみを記述することができます。
no-cache は、リクエストまたは応答メッセージをキャッシュできないことを示します (HTTP/1.0 は Pragma の no-cache に置き換えられます)。
キャッシュできる内容に基づいて
no-store は、重要な情報が意図せずに公開されるのを防ぐために使用されます。リクエスト メッセージで送信すると、リクエスト メッセージと応答メッセージの両方でキャッシュが使用されます。
キャッシュタイムアウトに基づく
max-age は、クライアントが指定された時間（秒）以下の存続期間を持つ応答を受信できることを示します。
min-fresh は、クライアントが現在時刻に指定された時刻を加えた時間よりも短い応答時間で応答を受信できることを示します。
max-stale は、クライアントがタイムアウト期間を超えて応答メッセージを受信できることを示します。 max-stale メッセージの値が指定されている場合、クライアントは次のことを行うことができます。
指定されたタイムアウト期間内の応答メッセージを受信します。
Expires は存在時間を表し、クライアントがこの時間より前にチェック (リクエストの送信) できないようにします。これは max-age に相当します。
効果。ただし、同時に存在する場合は、Cache-Control の max-age によって上書きされます。
形式: Expires = "Expires" ":" HTTP-date
例: 有効期限: 1994 年 12 月 1 日木曜日 16:00:00 GMT (GMT 形式である必要があります)
(2) 申請
HTTP META を介して有効期限とキャッシュ制御を設定します。
<meta http-equiv=”キャッシュ制御” content=”max-age=7200″ />
<meta http-equiv=”Expires” content=”Mon, 20 Jul 2009 23:00:00 GMT” />
上記の設定は一例であり、実際にはどの設定でも使用可能です。このように記述した場合、Web ページに対してのみ有効となり、Web ページ内の画像やその他のリクエストには使用されず、キャッシュも行われません。また、クライアントからのリクエストも増えていますが、Last-modifiedステータスをチェックしているだけですが、リクエストの増加はブラウジング速度に影響を与えるはずです。
ファイルにキャッシュを追加したい場合は、Apache の mod_expire モジュール ( http://httpd.apache.org/docs/2.2/mod/mod_expires.html ) を使用できます。これは次のように記述されます。
<IfModule mod_expires.c>
有効期限切れアクティブ日
Expiresデフォルト「アクセスプラス1日」
</Ifモジュール>
ExpiresActive が On に設定されていたことを覚えています。最初は On に設定していなかったように思います。YSlow はどうやってもキャッシュ機構を見つけることができないようです。この方法で追加すると、デフォルトで組み込まれます。個々の MIME タイプをターゲットにしたい場合は、次のことができます。
ExpiresByType 画像/gif 「アクセスプラス 5 時間 3 分」
さらに、ブラウザで [更新] をクリックすると、クライアントから送信されるリクエストはすべて max-age=0 となり、キャッシュを確認するリクエストをサーバーに送信してからキャッシュを更新することを示します。 304 Not Modified を取得します。これは、変更がないことを意味します。
04. Gzip コンポーネント Gzip 圧縮
Gzip 形式は非常に一般的な圧縮テクノロジであり、ほとんどすべてのブラウザに Gzip 形式を解凍する機能があり、圧縮できる圧縮率は非常に高く、一般的な圧縮率は 85% です。圧縮かどうかは、ここでテストできます。
05. スタイルシートを先頭に置く CSSを先頭に置く
LINK タグを使用してスタイル シートをドキュメントの HEAD に配置すると、閲覧者は Web サイトの完全なスタイルをできるだけ早く確認できるようになります。
HTML ページは段階的にレンダリングされます。ユーザーがページを開くときは、ユーザー エクスペリエンス、つまり Web ページを開く速度を考慮する必要があります。ページを表示するための最初の要件は HTML ですが、HTML は 1 つずつ DIV で構成されており、CSS がすべての基礎となります。
06. スクリプトを一番下に置く JSを一番下に置く
Web サイトがレンダリングされた後、これらの JS が読み込みプロセス中のコンテンツのパフォーマンスに影響を与えてはなりません。
ページは徐々にレンダリングされるため、スクリプトより下のコンテンツはブロックされます。スクリプトの読み込みが完了するまで、ページのレンダリングは続行されません。正しい配置
(1) 最悪のシナリオ: スクリプトを先頭に置きます。後続のコンテンツのレンダリングと後続のコンポーネントのダウンロードがブロックされます。
(2) 最良のシナリオ: スクリプトを一番下に置きます。ページのレンダリングを妨げません。
07. CSS 式を避ける CSS 式を避ける
CSS 式はひどいもので、IE でのみサポートされており、実行時に非常に大量の計算が必要になります。ただし、ブラウザの互換性のためにこれを使用する必要がある場合があります。
08. JavaScriptとCSSを外部化する
キャッシュについては以前に説明しましたが、より一般的な JS と CSS の一部では、Google からの Jquery ファイルのリンクなどの外部リンクを使用できます。
09. DNS ルックアップを減らす DNS ルックアップを減らす
外部からの Web サイト呼び出しリソースを削減します。
インターネットは IP アドレスによってサーバーを見つけます。 DNS にもオーバーヘッドがあります。通常の状況では、ブラウザが特定のホスト IP アドレスを見つけるのにかかる時間は 20 ～ 120 ミリ秒です。 DNS ルックアップ プロセスにかかる時間を短縮するには、次のテクニックのいくつかを採用する必要があります。
(1) DNSキャッシュ
DNS ルックアップをキャッシュしてパフォーマンスを向上させることができます。ユーザーのコンピュータでは、ホスト名が解決された後、対応する DNS 情報がオペレーティング システムの DNS キャッシュに保存されるため、その後の使用に必要な時間を短縮できます。他の一部のブラウザにも、対応する DNS キャッシュ機能があります。ただし、キャッシュされた DNS の数には制限があります。通常、オペレーティング システムは TTL 値を考慮し、ブラウザはこの値を無視して独自の時間を設定します。
(2)TTL
DNS キャッシュはシステムをある程度消費しますが、サーバーの IP アドレスは必ずしも変更されません。サーバーはレコードをキャッシュできる期間を示すことができ、ルックアップによって返される DNS レコードには、クライアントがレコードをキャッシュできる期間を示す存続時間 (TTL) 値が含まれています。通常は 1 日に設定できます。
10. JavaScript と CSS を縮小する JS と CSS のサイズを削減する
同じ機能を実現するために最小限のコードを使用する、空白を減らす、ロジックを強化する、略語を使用するなど、JS と CSS を作成するスキルが必要です。もちろん、これを実現するのに役立つツールはたくさんあります。
11. リダイレクトを避ける
リンクを再度書き込むと、「http://xxx.com」と「http://xxx.com/」の最後の「/」の違いは 1 つだけですが、サーバーは時間をかけて結果が異なります。前者の Redirect を後者に変換してからジャンプする必要があります。これを解決するには、Alias または mod_rewrite を使用することもできます。
さらに、リダイレクトの用途には、さまざまな Web サイトの接続、Web サイトの訪問の追跡、URL の美化などが含まれます。
12. 重複したスクリプトの削除 重複したスクリプトを削除します
ブラウザは繰り返し呼び出されるコードを認識せず無視しますが、再度計算します。これは当然ながら非常に無駄です。
13. ETag の構成 ETag の構成
何が起こったのかわかりませんが、htaccessで削除しました。
14. Ajax をキャッシュ可能にする Ajax キャッシュ
Ajax はリアルタイムで応答し、ブラウザーが新しいデータを受信する前に古いデータがキャッシュされるため、効率が向上します。
15. バッファを早期にフラッシュする できるだけ早くバッファを解放します。
ユーザーがページ要求を行うと、サーバーは HTML を組み立て、ヘッダーとボディの間に書き込み、バッファーを解放するのに 200 ～ 500 ミリ秒かかる必要があります。これにより、ファイル ヘッダーが最初に送信され、次に送信されます。ファイルの内容を送信して効率を向上させることができます。
16. AJAX リクエストに GET を使用する AJAX リクエストに GET を使用する
Get メソッドはサーバーと 1 回対話するだけ (データの送信) ですが、Post メソッドは 2 回の対話 (ヘッダーとデータの送信) を必要とします。
17. ポストロードコンポーネント コンポーネントの遅延ロード
最初にページの初期化に必要なコンポーネントをロードし、次に他のコンポーネントをロードします。具体的な実装方法としては、「hidden IFRAME」または JavaScript を使用できます。 「YUI Image Loader」がその好例です。
18. プリロードコンポーネント プリロードコンポーネント
後で使用する可能性のあるものをロードすることは、遅延ロードと競合しません。その目的は、後続のリクエストに対する応答を高速化することです。Google ホームページの CSS スプライト アプリケーションを参照してください。
19. DOM 要素の数を減らす DOM 要素の数を減らす
ページ構造が複雑になると、ダウンロード時間と応答時間が長くなり、ページのレンダリングが遅くなります。タグをより合理的かつ効率的に使用してページを構造化することは、優れたフロントエンドの前提条件です。
20. コンポーネントをドメイン間で分割する
主な目的は、ページ コンポーネントの並列ダウンロード機能を向上させることですが、2 ～ 4 個を超えるドメイン名を使用しすぎると、前述の DNS 検索の無駄が発生するので注意してください。 IE は、同じドメインに対して同時に 2 つのリクエストのみを持つことができます。実装では、CDN ネットワークまたはその他の分散コンピューティング ネットワークを利用できます。
21. iframe の数を最小限に抑える IFrame の数を減らします。
IFrame は SEO にとってタブーであり、IFrame をより効果的に使用する必要があります。
IFrame の利点: 広告、セキュリティ サンドボックス、並列ダウンロード スクリプトなどの遅いサードパーティ コンテンツのダウンロードに適しています。
IFrame の欠点: たとえ空であっても、大量のリソースを消費し、セマンティックではないページのオンロードを妨げます。
22. No 404s 404 ページには表示されません
404 ページは (検索結果ではなく) サイト自体に表示されます。意味のない 404 ページはユーザー エクスペリエンスに影響を与え、サーバー リソースを消費します。
23. クッキーのサイズを減らす クッキーを減らす
Cookie はファイル ヘッダーを介してサーバーとブラウザ間で交換されるため、Cookie のサイズが可能な限り削減され、適切な有効期限が設定されるため、効率が大幅に向上します。
24. コンポーネントに Cookie フリー ドメインを使用する コンポーネントに Cookie フリー ドメイン名を使用する
静的コンポーネントの Cookie を読み取るのは無駄です。静的コンポーネントを保存するには、Cookie のない別のドメイン名を使用するのが良い方法です。または、Cookie に www を含むドメイン名のみを保存できます。
25. DOM アクセスの最小化 DOM アクセスの数を減らす
JS は DOM へのアクセスが非常に遅いため、ページ レイアウトの設定には JS を使用しないようにしてください。
26. スマート イベント ハンドラーの開発 柔軟なイベント ハンドラーの開発
DOM ツリー内の要素がイベント ハンドラーに追加されすぎると、応答効率が確実に低下します。YUI イベント ツールには、DOM イベント ハンドラーを柔軟に設定できる onAvailable メソッドがあります。
27. @import ではなく <link> を選択します @import の代わりに <link> を使用します
IE で @import を使用することは、ページの下部にある <link> を使用することと同じです。
28. フィルターを避ける フィルターの使用を避ける
アルファ透明度が必要な場合は、AlphaImageLoader を使用しないでください。これは非効率であり、IE6 以下の画像にのみ適用されます。どうしても使用しなければならない場合は、IE7 以降のユーザーへの影響を避けるために _filter を追加してください。
29. 画像の最適化 画像の最適化
GIF を PNG8 に変換することは、サイズを削減する良い方法です。最適化の結果を得るために JPG および PNG 画像を処理する方法は数多くあります。
30. CSS スプライトの最適化 CSS スプライトの最適化
CSSスプライト内の画像を縦にできるだけコンパクトに配置したり、同系色の画像をできるだけまとめて配置したりすると、画像自体のサイズが小さくなり、ページ画像の表示速度が向上します。
31. HTML で画像を拡大縮小しないでください HTML で画像を拡大縮小しないでください
怠惰にしないで、好きなだけ大きな画像を使用してください。
32. favicon.ico を小さくしてキャッシュ可能にする favicon.ico のサイズを小さくしてキャッシュします
サイトのブラウザ ICO は頻繁に変更すべきではないため、長期間キャッシュし、1K 未満に制御することが最善です。
33. コンポーネントを 25K 未満に保つ
iPhone は、圧縮前の 25K を超えるコンポーネントをキャッシュできません。
34. コンポーネントをマルチパート ドキュメントにパックする コンポーネントをマルチパート ドキュメントにパックする
電子メールに添付ファイルを追加するのと同じように、HTTP リクエストで十分ですが、この手法はプロキシでサポートされている必要があり、iPhone ではサポートされていません。
インライン画像:
実際のページに画像データを埋め込むには「data:URLスキーム」を使用します。私たちが一般的に目にするのは、http、ftp、mailto およびその他のモードです。実際、data:URL モードは 1995 年に提案されています。これは、小さなデータがリンク URL に直接統合されることを意味します。パターンは次のとおりです: data: [<mediatype>][;base64],<data>
最初のパラメータは、image/gif などのファイル形式を示します。
残念ながら、IE は現在このモードをサポートしていません。また、データサイズにも制限があります。
声明: このコンテンツはインターネットから取得したもので、Yahoo の 34 件の記事に基づいています。