ホームページ > 記事 > ウェブフロントエンド > Yahoo の軍事規制の詳細な紹介
Yahoo の軍事規制の詳細な紹介
- 黄舟オリジナル
- 2017-07-24 13:52:031087ブラウズ
yahoo軍事規則は7カテゴリに分かれています合計35記事:
1.HTTPリクエストの数を減らすようにしてください
カテゴリ : コンテンツ
80%のエンドユーザー応答時間はフロントエンドで費やされており、そのほとんどはページ上のさまざまなコンポーネント(画像、スタイルシート、スクリプト、Flash)のダウンロードに費やされていますなど、お待ちください。コンポーネントの数を減らすと、必然的にページによって送信される HTTP リクエストの数も減ります。これがページを高速化するための鍵です。
ページのコンポーネントの数を減らす 1 つの方法は、ページのデザインを簡素化することです。しかし、応答時間を短縮しながら複雑なページを構築する方法はあるのでしょうか?確かに、ケーキを持って食べる方法もあります。ファイルをマージして、すべてのスクリプトを 1 つのファイルにまとめてリクエストの数を減らします。 もちろん、すべての CSS をマージすることもできます。各ページのスクリプトやスタイルが異なる場合、ファイルの結合は面倒な作業になる可能性がありますが、これをサイト公開プロセスの一部として実行すると、実際に応答時間を短縮できます。
CSS スプライトは、画像リクエストの数を減らすための推奨される方法です。すべての背景画像を 1 つの画像に統合し、CSS の background-image と background-position プロパティを使用して、表示する部分を配置します。
画像マッピング 複数の画像を 1 つの画像に結合できます。合計サイズは同じですが、リクエストの数が減り、ページの読み込みが高速化されます。イメージ マップは、ナビゲーション バーなど、ページ上でイメージが連続している場合にのみ役立ちます。 イメージマップの座標を設定するプロセスは退屈でエラーが発生しやすく、ナビゲーションにイメージマップを使用するのは簡単ではないため、この方法はお勧めできません。
インライン画像 (Base64エンコード) は、data: URL パターンを使用して画像をページに埋め込みます。これにより、HTML ファイルのサイズが増加します。(キャッシュされた) スタイル シートにインライン画像を配置すると、ページが「重くなる」ことを回避できます。ただし、現在の主流ブラウザはインライン画像を十分にサポートしていません。
ページの HTTP リクエストの数を減らすことは、サイトの最初のアクセス速度を向上させるための重要な指針です。 Tenni Theurerがブログに書いたように、ブラウザのキャッシュ使用量 – の訪問者の40%から60%がサイトにアクセスしている時間は、キャッシュです。空の。したがって、最初のページへのアクセスを高速化することは、ユーザーエクスペリエンスを向上させるために非常に重要です。 2.
CDNを使用する(コンテンツ配信ネットワーク) カテゴリ
:サーバー
ユーザーとサーバー間の物理的距離と応答時間影響もあります。地理的に分散した複数のサーバーにコンテンツを展開すると、ユーザーはページをより速く読み込むことができます。しかし、どうやってそれを行うのでしょうか？
地理的に分散されたコンテンツを実現するための最初のステップは、分散構造に対応するために web アプリケーションを再設計しようとしないことです。アプリケーションによっては、構造の変更には、セッション状態の同期やサーバー間でのデータベース トランザクションのレプリケーションなどの困難なタスクが含まれる場合があります (翻訳は正確ではない可能性があります)。ユーザーとコンテンツとの距離を縮めるための提案は、この困難のために遅れたり、単に通過できなかったりする可能性があります。
エンド ユーザー 80% から 90% までの応答時間は、画像、スタイル、スクリプト、 Flash などのページ コンポーネントのダウンロードに費やされることを忘れないでください。これはパフォーマンスの黄金律です。アプリケーション構造を最初から再設計するよりも、まず静的コンテンツを分散化することをお勧めします。これにより、応答時間が大幅に短縮されるだけでなく、CDNの貢献を示すことも容易になります。
コンテンツ配信ネットワーク (CDN) は、地理的に異なる場所に分散された一連の web サーバーであり、ユーザーにコンテンツをより効率的に配信するために使用されます。通常、コンテンツを配信するサーバーは、ネットワーク距離の尺度に基づいて選択されます。例: ホップ数が最小 (ホップ) または応答時間が最も速いサーバーを選択します。
一部の大手インターネット会社は独自の CDN を持っていますが、Akamai Technologies 、EdgeCast などの CDN サービスプロバイダーを使用する方がコスト効率が高くなります。 、または レベル 3 。始めたばかりの企業や個人のウェブサイトの場合、CDNサービスのコストは非常に高くなりますが、ユーザーベースがますます大きくなり、よりグローバルになっている場合は、CDNを使用する必要があります応答時間を短縮します。 Yahoo!では、静的コンテンツをアプリケーションのWebサーバーからCDN（には上記のサードパーティとYahoo自身のを含む）に移動します CDN ) により、エンド ユーザーの応答時間を 20% 以上改善できます。 CDN への切り替えは非常に簡単なコード変更ですが、サイトの応答性が大幅に向上します。
3.ExpiresまたはCache-Control HTTPHeader
Categoryを追加します。えー
このルールには 2 つの側面があります:
静的コンポーネントの場合:
Expires
として遠い未来の時間を設定することで期限切れになりません。 冗長動的コンポーネントの場合: 適切な Cache-Control HTTP ヘッダーを使用して、ブラウザーに条件リクエストを実行させます Web デザインはますますリッチになっており、ページ上にはより多くのスクリプト、画像、 Flash が存在します。サイトへの新規訪問者は、まだいくつかの HTTP リクエストを送信する必要があるかもしれませんが、有効期限を使用することでコンポーネントがキャッシュ可能になり、後続の閲覧セッション中に不必要な HTTP リクエストが回避されます。有効性 HTTP ヘッダーは通常画像で使用されますが、スクリプト、スタイル、Flash コンポーネントを含むすべてのコンポーネントで使用する必要があります。 ブラウザ (およびプロキシ) は、キャッシュを使用して HTTP リクエストの数とサイズを減らし、ページをより速く読み込めるようにします。 webサーバーは、有効期間HTTP応答ヘッダーを使用して、ページの各コンポーネントをキャッシュする期間をクライアントに伝えます。有効期間として遠い将来の時間を使用すると、この応答が 2010年4月15日まで変更されないことがブラウザに伝わります。 有効期限: Thu, 15 Apr 2010 20:00:00 GMT Apacheサーバーを使用している場合は、ExpiresDefaultコマンドを使用して、現在の日付を基準にして有効期限を設定します。次の例では、リクエスト時刻から 10 年の有効期間を設定します: ExpiresDefault "access plus 10 years" 有効期間に遠い将来の時刻を使用する場合は、覚えておいてください。コンポーネントを変更した後は、直ちにコンポーネントのファイル名を変更する必要があります。 Yahoo! では、ビルド プロセスの一部としてこれを行うことがよくあります。コンポーネントのファイル名にバージョン番号を埋め込みます。例: yahoo_2.0.6.js に遠い将来の時間を指定します。 Expiration HTTP ヘッダーは、ユーザーがすでにサイトにアクセスした後のページ ビューにのみ影響します。新しい訪問者であるか、ブラウザのキャッシュがクリアされている場合、HTTPリクエストの数には影響しません。したがって、このパフォーマンスの向上は、個々のコンポーネントをキャッシュしたユーザーがサイトにアクセスする頻度に依存します。これを Yahoo! で測定したところ、各コンポーネント (PV) のキャッシュされたページビューが 75% から 85% の範囲であることがわかりました。 HTTPヘッダーの有効期間として遠い未来の時間を使用することにより、ブラウザによってキャッシュされるコンポーネントの数が増加し、その後のページビューで送信するためにインターネット接続を使用する必要がなくなりますあと1バイトでも。 4.Gzipコンポーネント カテゴリ: サーバー ネットワーク上の送信を大幅に短縮する方法を見つけることができますHTTP リクエストとレスポンス時間。エンド ユーザーの帯域幅速度、ネットワーク サービス プロバイダー、ピア交換ポイントの距離などはすべて、開発チームの制御の範囲を超えていることに疑いの余地はありません。ただし、応答時間に影響を与える可能性のある要因は他にもあります。圧縮により HTTP 応答のサイズが削減され、応答時間が短縮されます。 HTTP/1.1 以降、web クライアントには、圧縮をサポートする Accept-Encoding HTTP リクエスト ヘッダーがあります。 Accept-Encoding: gzip、deflate webサーバーがこのリクエストヘッダーを認識すると、クライアントによってリストされたメソッドのいずれかを使用してレスポンスを圧縮します。 webサーバーは、Content-Encoding対応するヘッダーを通じてクライアントに通知します。 Content-Encoding: gzip Gzip は現在最も一般的で効率的な圧縮方法であり、GNU プロジェクトによって開発され、RFC 1952 によって標準化されています。他に見かける圧縮形式は deflate だけですが、あまり効率的ではなく、あまり一般的ではありません。 Gzipping は通常、応答を約 70% まで圧縮できます。現在、ブラウザーを介したネットワーク送信の約 90% が gzip をサポートしています。 Apacheサーバーの場合、gzipを設定するモジュールはバージョンによって異なります: Apache 1.3はmod_gzipを使用しますが、Apache 2.x はですmod_deflate モジュール。 ブラウザとプロキシの特定の要因により、ブラウザが期待する内容と受信する圧縮コンテンツの間に不一致が生じる可能性があります。幸いなことに、古いブラウザが廃止されるにつれて、このようなめったに起こらない状況は徐々に減少しており、Apache モジュールが適切な Vary 応答ヘッダーを自動的に追加することで、この問題に対処できます。 サーバーはファイルの種類に基づいて gzip圧縮を使用するかどうかを決定しますが、これは非常に限定的です。ほとんどの Web サイトは HTML ファイルを圧縮するために gzip を使用します。実際、スクリプトとスタイルシートを圧縮することも良い選択ですが、多くの Web サイトはこの機会を逃しています。実際、XMLやJSONを含むあらゆるテキストコンテンツは圧縮できますが、画像とPDFはすでにgzipを使用して圧縮されているため、圧縮する必要はありません。圧縮するのは無駄なだけではなく、CPUにますますストレスがかかる可能性があります。 gzip 圧縮をできるだけ使用すると、ページの軽量化が可能になります。これは、ユーザー エクスペリエンスを向上させる最も簡単な方法でもあります。 5.スタイルシートを一番上に置きます Category: css Yahoo!のパフォーマンスを調査しているときに、スタイルシートドキュメント HEAD セクションにより、ページの読み込みが速くなったように見えます。これは、head にスタイル シートを配置すると、ページが段階的にレンダリングされるためです。 パフォーマンスを懸念しているフロントエンド エンジニアは、ページが徐々にレンダリングされることを望んでいます。言い換えれば、ブラウザーには既存のコンテンツをできるだけ早く表示する必要があります。これは、ページ上に大量のコンテンツがある場合、またはユーザーのインターネット接続が非常に遅い場合に特に重要です。ユーザーにフィードバック (進捗状況インジケーターなど) を表示することの重要性については、広く調査されており、 文書化されています 。私たちの場合、HTML ページが進行状況インジケーターです。ブラウザーがページ ヘッダー、ナビゲーション バー、トップ ロゴ などを徐々に読み込むと、これらはすべて、ページの読み込みを待っているユーザーによるフィードバックとして使用され、全体的なユーザー エクスペリエンスを向上させることができます。 多くのブラウザ (IE を含む) では、スタイル シートを HTML ドキュメントの下部に配置すると、ページが徐々にレンダリングされなくなります。これらのブラウザは、スタイルの変更によるページ要素の再描画を避けるためにレンダリング プロセスをブロックし、ユーザーは空白のページを見つめたままになります。 HTML 公式ドキュメントでは、スタイル シートはページの HEAD 内に配置する必要があると明確に説明されています。「 A とは異なり、[LINK] はドキュメントの HEAD セクションにのみ表示されます。ただし、何度でも表示できます。" (aタグとは異なり、linkタグはHEADセクションにのみ表示されますが、何度でも表示できます) 。空白の画面やスタイルのない falsh コンテンツは受け入れられません。理想的な解決策は、HTML 公式ドキュメントに従い、スタイル シートを HTML ドキュメントの HEAD セクションに配置することです。 6. 脚 スクリプトを一番下に置きます カテゴリ : javascript は並列ダウンロードをブロックします、 公式ドキュメントでは、ブラウザーの名前はダウンロードしないことを示唆していますイメージが複数のホスト名から取得されている場合は、3 つ以上のコンポーネントを並行してダウンロードできます。スクリプトをダウンロードしている場合、ブラウザは、別のホスト名であっても他のダウンロード タスクを開始しません。 スクリプトを一番下に移動するのが難しい場合があります。たとえば、 を使用してスクリプトがページ コンテンツに挿入されている場合、それを下に移動する方法はありません。スコープに関する問題が発生する場合もありますが、ほとんどの場合は解決できます。 一般的な提案は、遅延 ( ) スクリプトを使用することです。DEFER 属性を持つスクリプトは、document.write を含めることができず、ブラウザに続行できることを通知することを意味します。レンダリング。残念ながら、FirefoxはDEFER属性をサポートしていません。 IE では、スクリプトが遅延する可能性がありますが、予想どおりではありません。スクリプトを延期できる場合は、スクリプトをページの下部に移動すると、ページの読み込みが速くなります。 7. CSS式の使用を避ける : css CSS式を使用してCSSプロパティを動的に設定するのは、強力かつ危険な方法です。 IE5からサポートされていますが、IE8からは非推奨になりました。たとえば、CSS式を使用して、背景色を時間ごとに交互に設定できます。 上記のコードでは、式メソッドはJavaScript式を受け入れることができます。 。 CSS プロパティは、式の計算結果に設定されます。 式 メソッドは他のブラウザでは無視されるため、IE と一貫したクロスブラウザ ユーザー エクスペリエンスを実現する方法を見つけることのみが役立ちます。 式の最大の問題は、私たちが思っているよりも頻繁に再計算されることです。式は、ページのレンダリングやサイズ変更のときだけでなく、ページのスクロール時や、ユーザーがページ上でマウスを移動したときにも再評価されます。 CSS 式にカウンターを追加して、いつ、どのくらいの頻度で再計算されるかを追跡します。ページ上でマウスを動かすと、10000 複数の再計算がトリガーされる可能性があります。 CSS 式の再計算を減らす 1 つの方法は、1 回限りの式を使用することです。つまり、式が初めて評価された後、style 属性を明示的な値に設定し、式を置き換えます。ページのライフサイクル全体を通じてスタイル プロパティを動的に設定する必要がある場合は、CSS 式の代わりにイベント ハンドラーを使用できます。 CSS 式を使用する必要がある場合は、式が何千回も再計算され、ページ全体のパフォーマンスに影響を与える可能性があることに注意してください。 8.JavaScriptとCSSを外側に置く カテゴリ: css パフォーマンス原則の多くは、外部との管理方法に関するものです。ただし、これらの懸念が生じる前に、より基本的な質問をする必要があります。JavaScript と CSS は外部ファイルに置くべきか、それともページに直接書き込むべきか? 実際、外部ファイルを使用すると、JavaScript および CSS ファイルがブラウザにキャッシュされるため、ページを高速化できます。 HTMLドキュメント内のインラインJavaScriptとCSSは、HTMLドキュメントがリクエストされるたびに再ダウンロードされます。そうすることで、必要な HTTP リクエストの数は減りますが、HTML ドキュメントのサイズは増加します。一方、JavaScriptとCSSが外部ファイルにあり、ブラウザによってキャッシュされている場合、サイズHTTPを増やすことなくHTMLドキュメントを小さくすることに成功しました。 リクエストの数。 重要な要素は、外部ファイルがキャッシュされる頻度とページリクエストの数との関係です。この要因を定量化することは困難ですが、さまざまな指標を使用して測定できます。ユーザーがセッションごとに複数のページにアクセスする場合、外部ファイルをキャッシュすると大きな利点が得られるため、複数のページにわたって同じスクリプトとスタイルシートを再利用できます。 多くのサイトは指標の点で中間に位置しており、これらのサイトの場合、通常、最良の解決策は JavaScript と CSS を外部ファイルとしてデプロイすることです。唯一の例外は、Yahoo!やMy Yahoo!のホームページなどのホームページのインラインモード優先です。セッションあたりの訪問数が少ないホームページでは、インライン JavaScript と CSS により、エンド ユーザーの応答時間が短縮されることがわかります。 HTTP リクエストを削減するために活用できるテクニックがたくさんあります。そのような手法の 1 つは、ホームページでインライン JavaScript と CSS を使用しますが、ページが読み込まれた後に外部ファイルを動的に読み込むことで、後続のページに必要な外部ファイルがすでにブラウザーに配置されているようにすることです。キャッシュ。 ReduceDNSLookup : コンテンツ IP アドレス間のマッピングは次のようになります電話帳の名前と番号のマッピングは同じです。ブラウザに www.yahoo.com と入力すると、ブラウザは DNS リゾルバーに接続してサーバーの IP アドレスを返します。 DNSにはコストがかかり、指定されたホスト名のIPアドレスを検索するには20から120ミリ秒かかります。 DNS検索が完了するまで、ブラウザはホスト名から何もダウンロードできません。 DNS ISP (インターネット サービス プロバイダー) またはローカル ネットワークがホストする特別なキャッシュ サーバーでより効率的にキャッシュされますが、個々のユーザーのコンピューターにキャッシュすることもできます。 DNS情報は、Windowsのオペレーティングシステム(Microsoft「DNSクライアントサービス」)のDNSキャッシュに保存されます。ほとんどのブラウザには、オペレーティング システムとは独立した独自の キャッシュ があります。ブラウザがこのレコードをキャッシュに保持している限り、オペレーティング システムDNSにクエリを実行しません。 IEデフォルトのキャッシュDNSルックアップ30分、DnsCacheTimeoutレジストリ設定に書き込まれます。 Firefoxcache1分、network.dnsCacheExpiration設定項目を使用して設定できます。 (Fasterfoxはキャッシュ時間を1時間に変更しました追伸。FasterfoxはFFの高速化プラグインです) クライアントの場合 DNS キャッシュ は空 (ブラウザーとオペレーティング システムを含む)、DNSルックアップの数は、ページ URL、画像、スクリプト ファイル、スタイル シートを含む、ページ上のさまざまなホスト名の数と同じです。 , Flash オブジェクトやその他のコンポーネントのホスト名、異なるホスト名を減らすと、DNSのルックアップを減らすことができます。 異なるホスト名の数を減らすと、ページが並行してダウンロードできるコンポーネントの数も減り、DNS ルックアップを回避すると応答時間が短縮され、並列ダウンロードの数が減ると応答時間が増加します。私の原則は、コンポーネントを 2 から 4 のホスト名に分散させることです。これは、同時に DNS ルックアップを減らし、高い同時ダウンロードを可能にする妥協案です。 10.圧縮JavaScriptとCSS カテゴリ: javascript, css 圧縮とは、具体的には、コードから不要な文字を削除してサイズを削減し、したがって、読み込み速度が向上します。コードの最小化とは、すべてのコメントと不要な空白文字 (スペース、改行、タブ) を削除することを意味します。これをJavaScriptで行うと、ダウンロードされるファイルが小さくなるため、応答性が向上します。最も一般的に使用される 2 つの JavaScript コード圧縮ツールは、JSMin と YUI Compressor です。YUI compressor は CSS も圧縮できます。 難読化はオプションのソースコード最適化手段であり、圧縮よりも複雑であるため、難読化プロセスではバグが発生する可能性も高くなります。米国のトップ 10 の Web サイトを対象とした調査では、圧縮によりサイズが21%減少し、難読化によりサイズが25%減少しました。難読化により高度な削減が可能になりますが、圧縮よりもリスクが高くなります。 外部スクリプトとスタイルの圧縮に加えて、インライン 3f1c4e4b6b16bbbd69b2ee476dc4f83a および c9ccee2e6ea535a969eb3f532ad9fe89 ブロックも圧縮できます。 gzipモジュールが有効になっている場合でも、最初に圧縮するとサイズを5%以上削減できます。 JavaScriptとCSSはますます便利になっているので、コードを圧縮すると良い効果が得られます。 11. カテゴリ コンテンツ でリダイレクト 302 ステータス コード、以下は 301 のステータス コードです ステータス コード HTTP ヘッダー: ブラウザは自動的に URL はドメインによって指定されます。リダイレクトに必要な情報はすべて HTTP ヘッダーに含まれており、応答本文は通常は空です。実際、Expires や Cache-Control などの追加の HTTP ヘッダーもリダイレクトを表します。さらに、他のリダイレクト方法: refresh メタタグと JavaScript がありますが、リダイレクトを行う必要がある場合は、主に標準の 3xxHTTP ステータス コードを使用するのが最善です。戻るボタンは正常に動作します。 リダイレクトはユーザー エクスペリエンスを低下させる可能性があることに注意してください。ユーザーと ドキュメントの間にリダイレクトを挿入すると、ページ上のすべての処理が遅延し、ページがレンダリングされず、コンポーネントのダウンロードが開始されなくなります。 HTMLまで ドキュメントがブラウザに表示されます。 リソースを非常に無駄にする一般的なリダイレクトがあり、 開発者は一般にこれに気づいていません。これは、URLの末尾にスラッシュが欠けている場合です。たとえば、 にジャンプすると、 にリダイレクトする 301 応答が返されます (末尾のスラッシュに注意してください)。 Apacheでは、Alias、mod_rewrite、またはDirectorySlashコマンドを使用して、不要なリダイレクトをキャンセルできます。 リダイレクトの最も一般的な用途は、古いサイトを新しいサイトに接続することです。また、同じサイトの異なる部分に接続し、ユーザーのさまざまな状況 (ブラウザーの種類、ユーザー アカウントの種類など) に応じて何らかの処理を実行することもできます。 。）。リダイレクトを使用して 2 つの Web サイトを接続するのが最も簡単で、必要な追加コードはほんの少量だけです。このようなときにリダイレクトを使用すると、開発者の開発の複雑さは軽減されますが、ユーザー エクスペリエンスは低下します。別の方法は、両方のコード パスが同じサーバー上にある場合、 Alias と mod_rewrite を使用することです。ドメイン名の変更によりリダイレクトが使用される場合は、エイリアス または と組み合わせた CNAME (別のドメイン名をエイリアスとして指す DNS レコードを作成する) を作成できます。 mod_rewrite コマンド 。 12.重複したスクリプトを削除する カテゴリ: javascript 重複したスクリプトファイルを含むページはパフォーマンスに影響を及ぼしますが、それはあなたが思っているものと異なる場合があります。米国のトップ web サイトのレビューでは、2 サイトのみに重複したスクリプトが含まれていることが判明しました。単一ページに重複したスクリプトが存在する可能性が高まる主な理由は 2 つあります。それは、チームの規模とスクリプトの数です。この場合、重複したスクリプトにより不要な HTTP リクエストが作成され、無駄な JavaScript コードが実行され、ページのパフォーマンスに影響を与えます。 IE HTTP リクエストを生成しますが、Firefox は生成しません。 IE では、キャッシュ不可能な外部スクリプトがページによって 2 回導入されると、ページの読み込み時に 2 つの HTTP リクエストが生成されます。スクリプトがキャッシュ可能であっても、ユーザーがページをリロードすると、追加の HTTP リクエストが生成されます。 HTTP リクエストを生成するだけでなく、スクリプトを複数回評価することも時間の無駄になります。スクリプトがキャッシュ可能かどうかに関係なく、冗長な JavaScript コードが Firefox と IE で実行されるためです。 HTML ページで SCRIPT タグを使用することです: cef325e6db3c5aadc8102a8841382fe3 2cacc6d41bbb37262a98f745aa00fbf0 PHP insertScript: 「永続的」有効性 HTTP ヘッダーをサポートするためのスクリプト ファイル名へのバージョン番号の追加など、その他のスクリプト関連の問題。 構成ETags : サーバー エンティティタグ (ETags) は、ブラウザキャッシュ内のコンポーネントがオリジンサーバーのコンポーネントと一致するかどうかを判断するためにサーバーとブラウザで使用されるメカニズムです (「エンティティ」とは、画像、スクリプト、スタイルシートなどのコンポーネントです)。 ETags を追加すると、最終変更日よりも柔軟なエンティティ検証メカニズムを提供できます。 ETag は、コンポーネントの特定のバージョンの一意の識別子として機能する文字列です。唯一の形式上の制約は、文字列を引用符で囲む必要があることです。オリジン サーバーは、対応するヘッダーを使用してコンポーネントの ETag を指定します。 4ab-457e1c1f" Content-Length: 12195その後、ブラウザはコンポーネントを検証する必要がある場合、 request ヘッダーを使用して ETag をオリジンサーバーに返します。 ETags が正常に一致すると、 304ステータスコードが返されるため、応答本文が12195バイト削減されます。 GET /i/yahoo.gif HTTP/1.1 ホスト: us.yimg.com If-Modified-From: 火曜日、12 Dec 2006 03:03:59 GMT If-None- Match : "10c24bc-4ab-457e1c1f" HTTP/1.1 304 Not Modified 問題は、それらが特定のサーバーによって構築されていることです。そのため、ブラウザがあるサーバーから初期コンポーネントを取得し、別のサーバーで認証したい場合サーバー ETags 上の同じコンポーネントは正常に一致できず、 web サイトではリクエストを処理するためにサーバーのグループを使用することが非常に一般的です。デフォルトでは、 Apache と IIS はデータを ETag に埋め込んで、マルチサーバー サイトでの妥当性テストが成功する可能性を大幅に減らします。 Apache 1.3および2.xのの形式は、inode-size-timestamp です。特定のファイルが複数のサーバー上の同じディレクトリにあり、ファイル サイズ、アクセス許可、タイムスタンプなどがすべて同じであっても、その i node (P.S. inode、UNIX) ) 内のインデックス ファイルもサーバーごとに異なります。 IIS5.0 と 6.0 にも同様の問題があります。 IISのETagsの形式は Filetimestamp:ChangeNumber です。ChangeNumberは、IISの構成変更を追跡するために使用されるカウンターです。 異なる IIS サーバー上のサイトの ChangeNumber を同じにすることはできません。 最終結果は、ApacheとIISによって生成された全く同じコンポーネントのETagsはブラウザ間で一致できず、ETagsが一致しない場合、ユーザーは一致しません。 ETagsを高速304レスポンシブデザインETagsを受け取ります。代わりに、コンポーネントのすべてのデータを含む 200通常の応答を受け取ります。サイトが単一サーバー上に展開されている場合、この問題はまったく存在しません。ただし、サイトが複数のサーバーにデプロイされており、Apache または IIS のデフォルトの ETags 構成を使用する予定の場合、ユーザーはページが遅くなり、サーバーの負荷が高くなり、帯域幅の消費が増加します。 、プロキシはページのコンテンツを効果的にキャッシュできません。コンポーネントに「永続的な」 Expires HTTP ヘッダーがある場合でも、ユーザーがクリックしてリロードまたは更新すると、条件付き ETags が提供する柔軟な検証モデルを使用したくない場合は、すべての Etag を削除し、コンポーネントベースのタイムスタンプ Last-Modified HTTP ヘッダーを使用することが最善です。検証を行い、ETagを削除すると、HTTPレスポンスヘッダーと後続のリクエストのサイズを削減できます。 Microsoft サポート記事 では、ETags を削除する方法について説明しています。 Apacheでは、次のコードを FileETag none14.Make Ajax : Ajax の利点の 1 つは、バックエンド サーバーから情報を非同期に要求できるため、ユーザーに即座にフィードバックを提供できることです。ただし、Ajaxでは、非同期のJavaScriptとXMLの応答を待つ間、ユーザーが退屈しないという保証はありません。多くのアプリケーションでは、ユーザーが待機できるかどうかは、Ajaxの使用方法に依存します。たとえば、web に基づく電子メール クライアントでは、ユーザーは検索条件に一致する電子メール メッセージを見つけるために、 パフォーマンスを向上させるには、これらの Ajax 応答を最適化することが重要です。 Ajax のパフォーマンスを向上させる最も重要な方法は、Expires または Cache-Control HTTP ヘッダーの追加で説明したように、応答をキャッシュ可能にすることです。次の追加ルールが 减少DNS查找 压缩JavaScript 避免重定向 配置ETags 我们一起看看例子，一个Web 2.0的电子邮件客户端用了Ajax来下载用户的通讯录，以便实现自动完成功能。如果用户从上一次使用之后再没有修改过她的通讯录，而且Ajax响应是可缓存的，有尚未过期的Expires或者Cache-Control HTTP头，那么之前的通讯录就可以从缓存中读出。必须通知浏览器，应该继续使用之前缓存的通讯录响应，还是去请求一个新的。可以通过给通讯录的Ajax URL里添加一个表明用户通讯录最后修改时间的时间戳来实现，例如 &t=1190241612 。如果通讯录从上一次下载之后再没有被修改过，时间戳不变，通讯录就将从浏览器缓存中直接读出，从而避免一次额外的HTTP往返消耗。如果用户已经修改了通讯录，时间戳也可以确保新的URL不会匹配缓存的响应，浏览器将请求新的通讯录条目。 即使Ajax响应是动态创建的，而且可能只适用于单用户，它们也可以被缓存，而这样会让你的Web 2.0应用更快。 15.尽早清空缓冲区 分类: 服务器 当用户请求一个页面时，服务器需要用大约200到500毫秒来组装HTML页面，在这期间，浏览器闲等着数据到达。PHP中有一个 flush() 函数，允许给浏览器发送一部分已经准备完毕的HTML响应，以便浏览器可以在后台准备剩余部分的同时开始获取组件，好处主要体现在很忙的后台或者很“轻”的前端页面上（P.S. 也就是说，响应时耗主要在后台方面时最能体现优势）。 比较理想的清空缓冲区的位置是HEAD后面，因为HTML的HEAD部分通常更容易生成，并且允许引入任何CSS和JavaScript文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。 例如： Yahoo!搜索 开创了这项技术，而且真实用户测试研究也证明了使用这种技术的诸多好处。 16.对Ajax用GET请求 分类: 服务器 Yahoo!mail チームは、XMLHttpRequest を使用する場合、ブラウザの POST リクエストは、最初に HTTP ヘッダーを送信し、次にデータを送信するという 2 段階のプロセスを通じて実装されることを発見しました。したがって、1 つの TCP メッセージを送信するだけで済む GET リクエストを使用するのが最善です ( cookie が多すぎる場合を除く)。 IEのURLの最大長は2Kなので、送信するデータが2Kを超える場合、GETは使用できません。 POST リクエストの興味深い副作用は、GET リクエストと同様に、実際にはデータが送信されないことです。 HTTP ドキュメントで説明されているように、GET リクエストは情報を取得するために使用されます。したがって、そのセマンティクスは GET リクエストでデータをリクエストするだけであり、サーバーに保存する必要があるデータを送信することではありません。 17. 遅延読み込みコンポーネント カテゴリ: コンテンツ ページを詳しく見て、ページをレンダリングするために何が必要かを自問してください。で最初の場所は？残りは待つことができます。 JavaScript は、onload イベントの前後を分離するのに最適です。たとえば、ドラッグ アンド ドロップとアニメーションをサポートする JavaScript コードとライブラリがある場合、これらは、ページが最初にレンダリングされた後にドラッグ アンド ドロップ要素が発生するまで待機する可能性があります。遅延読み込みできるその他のセクションには、非表示のコンテンツ (インタラクションの後に表示されるコンテンツ) や折りたたまれた画像などがあります。 ツールは作業負荷を軽減するのに役立ちます: YUI Image Loader は折りたたまれた画像の読み込みを遅らせることができ、YUI Get ユーティリティ は JS と CSS を導入する方法ですシンプル方法。 Yahoo!ホームページは、Firebugのネットワークパネルを開いて詳しく見ることができます。 パフォーマンス目標を、「プログレッシブ拡張」などの他の Web 開発のベスト プラクティスと調整することが最善です。クライアントが JavaScript をサポートしている場合、ユーザー エクスペリエンスを向上させることができますが、JavaScript がサポートされていない場合でもページが適切に動作できることを確認する必要があります。したがって、ページが適切に動作していることを確認したら、遅延読み込みスクリプトを使用してページを強化し、ドラッグ アンド ドロップやアニメーションなどの派手な効果をサポートできます。 18. コンポーネントのプリロード カテゴリ: コンテンツ プリロードは遅延読み込みの反対のように見えるかもしれませんが、実際には違う目標。コンポーネントをプリロードすると、ブラウザのアイドル時間を最大限に活用して、将来使用されるコンポーネント (画像、スタイル、スクリプト) をリクエストできます。ユーザーが次のページにアクセスするとき、ほとんどのコンポーネントはすでにキャッシュ内にあるため、ユーザーの観点からはページの読み込みが速くなります。 実際のアプリケーションでは次の種類のプリロードがあります: 無条件 プリロード – できるだけ早くロードを開始し、追加のコンポーネントを取得します。 google.com は、スプライト画像のプリロードの良い例です。このスプライト画像は、google.comホームページに必要なものではなく、検索結果ページのコンテンツです。 条件付き プリロード - ユーザーのアクションに基づいてユーザーがジャンプする場所を推測し、それに応じてプリロードします。 search.yahoo.com の入力ボックスに入力すると、これらの追加コンポーネントのロードがどのように要求されるかがわかります。 事前に プリロード – 新しいデザインを発売前にプリロードします。再設計後、「この新しい Web サイトは優れていますが、以前よりも遅いです。」という声をよく聞きます。その理由の 1 つは、ユーザーがアクセスした以前のページには古いキャッシュがあるのに、新しいページではエクスペリエンスが空になっていることが挙げられます。 。この悪影響は、新しいデザインが展開される前にいくつかのコンポーネントをプリロードすることで軽減できます。古いサイトはブラウザのアイドル時間を利用して、新しいサイトに必要な画像とスクリプトをリクエストできます。 19.DOM要素の数を減らす カテゴリ: コンテンツ 複雑なページはダウンロードするバイト数が増加します。 JavaScriptアクセス DOMも遅くなります。たとえば、イベント ハンドラーを追加する場合、ページ上の 500 DOM 要素をループすることと、5000 DOM 要素をループすることには違いがあります。 DOM 要素が多数あることはその兆候です。ページ上にクリーンアップする必要がある無関係なタグがいくつかあります。レイアウトにネストされたテーブルを使用していますか?それとも、レイアウトの問題を解決するためだけに dc6dce4a544fdca2df29d5ac0ea9906b を大量に追加しましたか?おそらく、より適切なセマンティック マークアップを使用する必要があります。 は、レイアウトに非常に役立ちます: grids.css 全体的なレイアウトについては、fonts.css と reset.css を使用してブラウザのデフォルトを削除できますフォーマット。これは、改行をレンダリングするためではなく、意味的に意味がある場合にのみ dc6dce4a544fdca2df29d5ac0ea9906b を使用するなど、マークアップについてクリーンアップして考え始める良い機会です。 要素の数は簡単にテストできます。 Firebugのコンソールに次のように入力するだけです: いくつドム Yahoo!Homepage など、よくマークされた他の同様のページを参照することができます。Homepage は非常に忙しいページですが、 700 要素 (HTML タグ) しかありません。 クロスドメイン分離コンポーネント : コンポーネントを分離すると、並列ダウンロードを最大化できますが、DNS検索のコストを考慮して、2〜4を超えるドメインのみを使用するようにしてください。たとえば、HTMLと動的コンテンツをwww.example.org にデプロイし、静的コンポーネントをstatic1.example.org とstatic2.example.org に分離できます。 詳細については、Tenni Theurer および Patty Chi: Carpool Lane での並列ダウンロードの最大化 21 の記事を参照してください。 できるだけ少なくiframe Category: Content HTML ドキュメントを親ドキュメントに挿入するには、iframe を使用します。重要なことは iframe を理解することです仕組みと効率的な使用方法。 d5ba1642137c3f32f4f4493ae923989c 長所: d5ba1642137c3f32f4f4493ae923989c 短所: 空の 22. Content リクエストは高価です HTTP リクエスト役に立たない応答 (404 Not Found など) を取得すると、ユーザー エクスペリエンスが低下するだけで何のメリットもありません。 404 を使用すると便利なサイトもあります - 「これはユーザー エクスペリエンスには良いですが、サーバー リソース (データベースなど) も浪費します。」待って）。最悪の部分は、リンクされている外部 JavaScript にエラーがあり、結果が 404 になることです。まず、このようなダウンロードは並列ダウンロードをブロックします。次に、ブラウザーは 404 応答本文を解析しようとします。これは JavaScript コードであり、そのどの部分が利用可能であるかを調べる必要があるためです。 23.Cookie減量 カテゴリ: Cookie を使用する理由クッキー エンパワーメントやパーソナライゼーションなど、たくさんあります。 HTTPcookie 内の情報は、 webサーバーとブラウザの間で交換されます。ユーザーの応答時間への影響を最小限に抑えるために、 cookie をできるだけ小さく保つことが重要です。 詳しくは、Tenni Theurer と Patty Chi の記事: When the Cookie Crumbles をご覧ください。関連する経験則は次のように要約できます: 不要な Cookie を削除する ユーザーの応答時間への影響を最小限に抑えるために、 Cookie をできるだけ小さくする Cookie の設定に注意する他のサブドメインに影響を与えないように、適切なドメイン レベルを設定します 適切な有効期間を設定するか、なしをより速く削除でき、ユーザーの応答時間を短縮できます24。 コンポーネントを配置します cookie を含まないドメインの下に配置します : cookie cookie Cookieを必要としません。したがって、これらは無意味なネットワーク トラフィックを引き起こすだけであり、静的コンポーネントへのリクエストには cookie が含まれていないことを確認する必要があります。サブドメインを作成し、そこにすべての静的コンポーネントをデプロイできます。 www.example.org static.example.org にデプロイできます。ただし、cookiesがトップレベルドメインexample.orgまたはwww.example.orgに設定されている場合、static.example.orgへのすべてのリクエストには次の内容が含まれます。これらのクッキー。現時点では、新しいドメイン名を購入し、すべての静的コンポーネントをデプロイし、新しいドメイン名に cookie を含まないようにすることができます。 Yahoo!はyimg.comを使用しています、YouTubeはytimg.comを使用しています、Amazonはimages-amazonを使用していますなど。 cookie cookie を含むコンポーネントのキャッシュを拒否する可能性があることです。注意すべき点が 1 つあります。ホームページとして example.org と www.example.org のどちらを使用するかわからない場合は、 cookie の影響を考慮することができます。 wwwを省略した場合、cookieを*.example.org に書き込むことしかできないため、パフォーマンス上の理由から、wwwサブドメインを使用し、cookieを置くことが最善です このサブドメインの下に書き込みます。 最小化 DOM訪問 カテゴリ: javascript JavaScriptを使用してDOM要素にアクセスするのは非常に遅いため、ページの応答をより速くするには、次のことを行う必要があります: インデックスにアクセスしました ノードをDOMツリーに追加する前に、まず「オフライン」で更新してください レイアウトの問題を修正するためにJavaScriptの使用を避けてください 詳細については、YUIをチェックしてください。 In Cinema Julien Lecomte の記事: 高性能 Ajax アプリケーション 26.スマート イベント ハンドラーを使用する カテゴリ: javascript 時々ページに反映されているように感じます DOM ツリーのさまざまな要素に追加される頻繁に実行されるイベント ハンドラーが多すぎるため、十分な注意が必要ではありません。これが、イベントの委任が推奨される理由です。 div に 10 ボタンがある場合、各ボタンにイベント ハンドラーを追加するのではなく、 div コンテナにイベント ハンドラーのみを追加する必要があります。イベントはバブルアップする可能性があるため、イベントをキャプチャして、どのボタンがイベントのソースであるかを知ることができます。 通常、DOMツリー内でターゲット要素にアクセスできる限り、onloadイベントを待つ必要はありません。すべての画像がダウンロードされるまで待つ必要はありません。 onload イベントの代わりに DOMContentLoaded を使用することを検討できますが、すべてのブラウザで利用できるようにするには、onAvailable メソッドを持つ YUI Event ツールを使用できます。 YUI Cinema Julien Lecomte の記事を参照してください: High Performance Ajax Applications Choose 18d523868433cba7fe9350e7e4453ad2 Discard @import : css CSS を先頭に配置する必要があります。 IE で @import を使用すると、下部の 2cdf5bf648cf2f33323966d7f58a7f3f を使用したのと同じ効果があるため、使用しないことをお勧めします。 28. カテゴリ IE 独自仕様 AlphaImageLoader フィルターはIE7を修正するために使用できます。このバージョンの半透明の PNG 画像に問題があります。画像の読み込みプロセス中に、このフィルターはレンダリングをブロックし、ブラウザをフリーズし、メモリ消費量を増加させます。また、各画像ではなく各要素に適用されるため、多くの問題が発生します。 最善の方法は、 AlphaImageLoader を使用せず、IE で十分にサポートされている PNG8 画像を使用するように正常にダウングレードすることです。 AlphaImageLoader を使用する必要がある場合は、 IE7 以降のバージョンのユーザーへの影響を避けるために、アンダースコア hack: _filter を使用する必要があります。 29.写真を最適化する カテゴリ: 写真 デザイナーが写真を作成したら、にアップロードしますweb サーバーの前に、私たちにできることがいくつかあります。 GIF 画像をチェックして、パレット サイズに対応する色の数が画像内で使用されているかどうかを確認します。簡単に確認するには、imagemagick を使用します。 4 カラー「スロット」を使用している場合は、改善の余地がありますGIF画像を に変換してみてください。サイズを縮小できる場合は、多くの場合、縮小できます。ブラウザーのサポートが限られているため、開発者は PNG 画像の使用を躊躇することがよくありましたが、それは過去のことです。本当の問題は、PNG画像はalphaの透明度を完全にサポートしているのに対し、GIF画像は透明度のグラデーションをサポートしていないため、GIFでできることは何でも、PNGはい(アニメを除く）。次の簡単なコマンドを使用すると、画像を安全に使用できます: convert image.gif image.png 「私たちが強調しているのは、PNGにチャンスを与えるということです。」 pngcrush 最適化ツール) は、すべての PNG pngcrush image.png -rem alla -reduce -brute result.png using jpegtran プロセスこのツールは、JPEG画像に対する回転などのロスレス操作をサポートしており、注釈やその他の不要な情報( jpegtran -copy none -optimize -perfect src.jpg dest.jpg30.最適化CSSスプライト分類 : 写真 Spriteでは、水平に配置された画像は、通常、垂直に配置された最終ファイルよりも小さくなります画像内のcombiningの類似の色は、色の数を低く抑えることができます。理想的には 256colorspng8format「モバイルフレンドリー」、絵とのギャップが大きい。画像ファイルのサイズには大きな影響はありませんが、これにより、画像をピクセル マップに解凍するときにユーザー エージェントが消費するメモリを節約できます。 100 1万ピクセル。 31.使用しないでくださいHTML写真をズーム カテゴリ: 写真使用しないHTML 幅と高さを設定できます では使用できませんが、この大きな画像が必要です。必要に応じて 1acf00d8da3c1b4d1e485bf03581baac 次に、画像自体 (mycat.jpg) 500x500px の画像を縮小するのではなく、100x100pxにするべきです。 32.小さなキャッシュ可能な お気に入りのアイコン)を使用してくださいカテゴリ: 写真 はサーバーのルート ディレクトリに配置された画像。無視してもブラウザが自動的に要求するため、404 Not Found 応答を返さないことが最善です。そして、同じサーバー上にある限り、cookieはリクエストされるたびに送信され、さらにこの画像は、例えばIEで追加のリクエストをしたときにダウンロード順序を妨げます。 onload コンポーネントをインストールすると、最初にfaviconがダウンロードされます。 したがって、favicon.ico の欠点を軽減するには、次のことを確認する必要があります: が十分小さい、できれば 1K 適切な有効期間を設定する HTTP ヘッダー (後で変更したい場合は名前を変更できません)。通常は、有効期間を数か月後に設定する方が安全です。最終変更日を確認することで、変更がブラウザーに認識されるようにすることができます。現在の favicon.ico の。 は、小さなお気に入りのアイコンを処理するために使用できます 33. 25K未満であることを保証します カテゴリ: モバイル 这个限制是因为iPhone不能缓存大于25K的组件，注意这里指的是 未压缩的 大小。这就是为什么缩减内容本身也很重要，因为单纯的gzip可能不够。 更多信息请查看Wayne Shea和Tenni Theurer的文章： Performance Research, Part 5: iPhone Cacheability – Making it Stick 34.把组件打包到一个复合文档里 分类: 移动 把各个组件打包成一个像有附件的电子邮件一样的复合文档里，可以用一个HTTP请求获取多个组件（记住一点：HTTP请求是代价高昂的）。用这种方式的时候，要先检查用户代理是否支持（iPhone就不支持）。 35.避免图片src属性为空 分类: 服务器 Image with empty string src 属性是空字符串的图片很常见，主要以两种形式出现： straight HTML JavaScript 这两种形式都会引起相同的问题：浏览器会向服务器发送另一个请求。 IE 向页面所在目录发起一个请求 Safari和Chrome 想当前页面本身发送一个请求 Firefox 3及更早版本与Safari和Chrome处理方式一样，但3.5解决了这个问题 [bug 444931] ，不会再发送请求了 Opera 遇到有空src属性的图片不做任何处理 为什么图片src属性为空不好？ 意外发送大量的通信量对服务器来说是很伤的，尤其是在每天有几百万访问量页面的时候。 浪费服务器资源去生成一个根本不可能被看到的页面 可能会污染用户数据，如果追踪请求状态，要么通过cookie要么是其它方式，可能会破坏用户数据。即使图片请求并没有返回图片，整个HTTP头部也会被浏览器接受并读取，包括所有的cookie。虽然其余部分会被丢弃，但这可能已经造成破坏了。 問題の根本原因は、RFC 3986 – Uniform Resource Identifiersドキュメントで明確に定義されているURIの処理方法におけるブラウザ間の違いです。 URIが空の文字列の場合、相対URIとして扱われ、セクション5.2で定義されたアルゴリズムに従って処理されます。実際の状況は、Firefox、Safari、Chromeはすべて、ドキュメントのセクション5.4に記載されている仕様に従って空の文字列を処理しますが、IEは処理しません。それらに正しく対処してください。古いバージョンの仕様書RFC 2396– Uniform Resource Identifiers (RFC 3986によって廃止) では、厳密な意味では、ブラウザは相対的なURIを処理すると言われています。 すべて正しいです。問題は、この場合、空の文字列が明らかに意図的ではないことです (追記 であり、相対的な URI ではありません)。 html5 4.8.2は、ブラウザが追加のリクエストを送信しなくなることを指定する＆lt; img＆gt; 要素のベース URI がドキュメントと同じである場合、src 属性が存在する必要があり、ページ化もスクリプト化もされていない、非インタラクティブでオプションでアニメーション化される画像リソースを参照する有効な URL が含まれている必要があります。 のアドレスの場合、src属性' の値は空の文字列であってはなりません。 （追記：要素のベースURIの場合、インタラクティブなアニメーションまたは画像リソースはページングできません。がドキュメント アドレスと同じである場合、src 属性の値を空の文字列にすることはできません。")。<?php insertScript("menu.js?1.1.11") ?>... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content --><img src=””>
var img = new Image();img.src =
“”
;
以上がYahoo の軍事規制の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。