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%減少しました。難読化により高度な削減が可能になりますが、圧縮よりもリスクが高くなります。 外部スクリプトとスタイルの圧縮に加えて、インライン <script> および <span style="font-family: 宋体"></span><style> ブロックも圧縮できます。 <span style="font-family: Calibri"></span>gzip<span style="font-family: 宋体"></span>モジュールが有効になっている場合でも、最初に圧縮するとサイズを<span style="font-family: Calibri"></span>5%<span style="font-family: 宋体"></span>以上削減できます。 <span style="font-family: Calibri"></span>JavaScript<span style="font-family: 宋体"></span>と<span style="font-family: Calibri"></span>CSS<span style="font-family: 宋体"></span>はますます便利になっているので、コードを圧縮すると良い効果が得られます。 <span style="font-family: Calibri"></span><span style="font-family: 宋体"> </span></p>
<p>11.</p>リダイレクトを避ける<p><strong><span style="font-family: 宋体"></span> </strong></p>
<p>カテゴリ</p>: <p>コンテンツ<span style="font-family: 宋体"></span><span style="font-family: 宋体"> </span></p>
<p> </p>301<p>でリダイレクト<span style="font-family: 宋体"> </span>302<span style="font-family: 宋体"></span> ステータス コード、以下は <span style="font-family: Calibri"> </span>301 のステータス コードです<span style="font-family: 宋体"></span> ステータス コード <span style="font-family: Calibri"></span>HTTP<span style="font-family: 宋体"></span> ヘッダー: <span style="font-family: Calibri"></span><span style="font-family: 宋体"> </span></p>HTTP/1.1 301 Moved Permanently<p></p> Location:<p></p> Content-Type: text/html<p></p> <p> ブラウザは自動的に </p> Location にジャンプします<p> <span style="font-family: 宋体">URL </span><span style="font-family: 宋体">は</span>ドメインによって指定されます。リダイレクトに必要な情報はすべて <span style="font-family: Calibri"></span>HTTP<span style="font-family: 宋体"></span> ヘッダーに含まれており、応答本文は通常は空です。実際、<span style="font-family: Calibri"></span>Expires <span style="font-family: 宋体"></span> や <span style="font-family: Calibri"></span>Cache-Control <span style="font-family: 宋体"></span> などの追加の <span style="font-family: Calibri"></span>HTTP<span style="font-family: 宋体"></span> ヘッダーもリダイレクトを表します。さらに、他のリダイレクト方法: <span style="font-family: Calibri"></span>refresh<span style="font-family: 宋体"></span> メタタグと <span style="font-family: Calibri"></span>JavaScript<span style="font-family: 宋体"></span> がありますが、リダイレクトを行う必要がある場合は、主に標準の <span style="font-family: Calibri"></span>3xxHTTP<span style="font-family: 宋体"></span> ステータス コードを使用するのが最善です。戻るボタンは正常に動作します。 <span style="font-family: Calibri"></span><span style="font-family: 宋体"> </span></p>
<p> リダイレクトはユーザー エクスペリエンスを低下させる可能性があることに注意してください。ユーザーと </p>HTML<p> ドキュメントの間にリダイレクトを挿入すると、ページ上のすべての処理が遅延し、ページがレンダリングされず、コンポーネントのダウンロードが開始されなくなります。 <span style="font-family: 宋体"></span>HTML<span style="font-family: 宋体">まで </span>ドキュメントがブラウザに表示されます。 <span style="font-family: Calibri"></span><span style="font-family: 宋体"> </span></p>
<p> リソースを非常に無駄にする一般的なリダイレクトがあり、</p>ウェブ<p>開発者は一般にこれに気づいていません。これは、<span style="font-family: 宋体"></span>URL<span style="font-family: 宋体"></span>の末尾にスラッシュが欠けている場合です。たとえば、<span style="font-family: Calibri"></span> <span style="font-family: 宋体"></span> にジャンプすると、<span style="font-family: Calibri"></span> <span style="font-family: 宋体"></span> にリダイレクトする <span style="font-family: Calibri"></span>301<span style="font-family: 宋体"></span> 応答が返されます (末尾のスラッシュに注意してください)。 <span style="font-family: Calibri"></span>Apache<span style="font-family: 宋体"></span>では、<span style="font-family: Calibri"></span>Alias<span style="font-family: 宋体"></span>、<span style="font-family: Calibri"></span>mod_rewrite<span style="font-family: 宋体"></span>、または<span style="font-family: Calibri"></span>DirectorySlash<span style="font-family: 宋体"></span>コマンドを使用して、不要なリダイレクトをキャンセルできます。 <span style="font-family: Calibri"></span><span style="font-family: 宋体"></span></p>
<p><span style="font-family: 宋体"> リダイレクトの最も一般的な用途は、古いサイトを新しいサイトに接続することです。また、同じサイトの異なる部分に接続し、ユーザーのさまざまな状況 (ブラウザーの種類、ユーザー アカウントの種類など) に応じて何らかの処理を実行することもできます。 。）。リダイレクトを使用して 2 つの Web サイトを接続するのが最も簡単で、必要な追加コードはほんの少量だけです。このようなときにリダイレクトを使用すると、開発者の開発の複雑さは軽減されますが、ユーザー エクスペリエンスは低下します。別の方法は、両方のコード パスが同じサーバー上にある場合、</span> Alias <span style="font-family: 宋体"> と </span><span style="font-family: Calibri">mod_rewrite </span><span style="font-family: 宋体"> を使用することです。ドメイン名の変更によりリダイレクトが使用される場合は、</span><span style="font-family: Calibri">エイリアス </span><span style="font-family: 宋体"> または </span><span style="font-family: Calibri"> と組み合わせた </span><span style="font-family: 宋体">CNAME</span><span style="font-family: Calibri"> (別のドメイン名をエイリアスとして指す </span><span style="font-family: 宋体">DNS</span><span style="font-family: Calibri"> レコードを作成する) を作成できます。 mod_rewrite </span><span style="font-family: 宋体"> コマンド 。 </span></p>
<p> </p>
<p><strong>12.<span style="font-family: 宋体">重複したスクリプトを削除する</span></strong></p>
<p> </p>
<p><span style="font-family: 宋体">カテゴリ</span>: javascript</p>
<p></p>
<p><span style="font-family: 宋体"> 重複したスクリプトファイルを含むページはパフォーマンスに影響を及ぼしますが、それはあなたが思っているものと異なる場合があります。米国のトップ </span><span style="font-family: 宋体">web</span><span style="font-family: Calibri"> サイトのレビューでは、</span><span style="font-family: 宋体">2</span><span style="font-family: Calibri"> サイトのみに重複したスクリプトが含まれていることが判明しました。単一ページに重複したスクリプトが存在する可能性が高まる主な理由は 2 つあります。それは、チームの規模とスクリプトの数です。この場合、重複したスクリプトにより不要な </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> リクエストが作成され、無駄な </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri"> コードが実行され、ページのパフォーマンスに影響を与えます。 </span><span style="font-family: 宋体"></span> </p>
<p>IE</p> は不要な <p><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> リクエストを生成しますが、</span><span style="font-family: 宋体">Firefox</span><span style="font-family: Calibri"> は生成しません。 </span><span style="font-family: 宋体">IE</span><span style="font-family: Calibri"> では、キャッシュ不可能な外部スクリプトがページによって 2 回導入されると、ページの読み込み時に 2 つの </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> リクエストが生成されます。スクリプトがキャッシュ可能であっても、ユーザーがページをリロードすると、追加の </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> リクエストが生成されます。 </span><span style="font-family: 宋体"></span> </p>
<p></p> 無意味な <p>HTTP<span style="font-family: 宋体"> リクエストを生成するだけでなく、スクリプトを複数回評価することも時間の無駄になります。スクリプトがキャッシュ可能かどうかに関係なく、冗長な </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri"> コードが </span><span style="font-family: 宋体">Firefox</span><span style="font-family: Calibri"> と </span><span style="font-family: 宋体">IE</span><span style="font-family: Calibri"> で実行されるためです。 </span><span style="font-family: 宋体"></span> </p>
<p></p> 同じスクリプトを誤って 2 回導入することを避ける 1 つの方法は、テンプレート システムにスクリプト管理モジュールを実装することです。スクリプトを導入する一般的な方法は、<p>HTML<span style="font-family: 宋体"> ページで </span><span style="font-family: 宋体">SCRIPT</span><span style="font-family: Calibri"> タグを使用することです: </span><span style="font-family: 宋体"></span> </p>
<p><script type="text/javascript" src="menu_1.0.17.js?1.1.11 "> </script> 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 要素が多数あることはその兆候です。ページ上にクリーンアップする必要がある無関係なタグがいくつかあります。レイアウトにネストされたテーブルを使用していますか?それとも、レイアウトの問題を解決するためだけに は、レイアウトに非常に役立ちます: grids.css 全体的なレイアウトについては、fonts.css と reset.css を使用してブラウザのデフォルトを削除できますフォーマット。これは、改行をレンダリングするためではなく、意味的に意味がある場合にのみ 要素の数は簡単にテストできます。 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 を理解することです仕組みと効率的な使用方法。 <?php insertScript("menu.js?1.1.11") ?>... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
