Yahoo Fourteen: Web サイトのフロントエンド Web ページの最適化に関する 14 の原則

Web アプリケーションのパフォーマンス最適化の黄金律: まず、フロントエンド プログラム (フロントエンド) のパフォーマンスを最適化します。これは、エンドユーザーの応答時間の 80% 以上がここに費やされるためです。

ルール1. HTTPリクエストの数を減らす

エンドユーザーの応答時間の 80% はフロントエンド プログラムに費やされ、この時間のほとんどは、画像、スタイル シート、スクリプト、Flash などのさまざまなページ要素のダウンロードに費やされます。ページ要素を減らすと、HTTP リクエストの数が減ります。これはページを素早く表示するための鍵です。

ページ要素の数を減らす 1 つの方法は、ページのデザインを簡素化することです。しかし、豊富なコンテンツと高速な応答時間の両方を実現する別の方法はあるのでしょうか?そのようなテクニックをいくつか紹介します:

画像マップ複数の画像を 1 つの画像に結合します。合計ファイル サイズはあまり変わりませんが、HTTP リクエストの数が減り、ページの表示が速くなります。この方法は連続画像にのみ適していますが、同時に座標の定義は面倒で間違いが発生しやすい作業です。

CSS スプライト の方が良い方法です。ページの画像を 1 つのファイルに結合し、CSS のbackground-image プロパティとbackground-position プロパティを使用して画像の必要な部分を実装します。

インライン画像は、data: URL スキームを使用してページに画像を埋め込みます。これにより、HTML ファイルのサイズが大きくなります。インライン画像を (キャッシュされた) スタイルシートに結合することは、HTTP リクエストを削減し、HTML ファイルのサイズの増加を回避する方法です。

結合ファイルは、複数のスクリプト ファイルを 1 つのファイルに結合することで HTTP リクエストの数を減らします。スタイルシートも同様の方法で扱うことができます。この方法は単純ですが、大規模には使用されていません。米国の上位 10 の Web サイトには、ページごとに平均 7 つのスクリプト ファイルと 2 つのスタイル シートがあります。スクリプトとスタイルシートがページごとに大幅に異なる場合、このアプローチは困難になる可能性がありますが、これを実行すると応答時間を短縮できます。

HTTP リクエストの数を減らすことがパフォーマンス最適化の出発点です。これは、初回訪問の効率を向上させる上で重要な役割を果たします。 Tenni Theurer の記事「ブラウザ キャッシュの使用状況 - 暴露!」によると、毎日の訪問の 40 ～ 60% が初回訪問であるため、初回訪問者のページ アクセスを高速化することがユーザー エクスペリエンスの鍵となります。

私たちのアプリ:

外国貿易: ホームページ上の多数の小さなアイコンを 1 つに結合し、CSS を通じて表示を制御し、HTTP リクエストの数を減らします。

ルール 2. CDN (コンテンツ配信ネットワーク、コンテンツ配信ネットワーク) を使用する

Web サーバーからのユーザーの距離も、応答時間に大きな影響を与えます。ユーザーの観点から見ると、地理的に分散した複数のサーバーにコンテンツを展開すると、ページの読み込み速度が効果的に向上します。しかし、どこから始めればよいのでしょうか?

コンテンツの地理的配布に向けた最初のステップとして、配布アーキテクチャに合わせて Web アプリケーションをリファクタリングしようとしないでください。スキーマを変更すると、セッション状態の同期や複数のサーバー間でのデータベース トランザクションの複製など、複数の定期的なタスクが発生します。ユーザーとコンテンツの間の距離を縮めようとするこのような試みは、アプリケーション アーキテクチャの変更によって遅延またはブロックされる可能性があります。

また、エンドユーザーの応答時間の 80 ～ 90% が、画像ファイル、スタイルシート、スクリプト、Flash など、ページ内のさまざまな要素のダウンロードに費やされていることも覚えています。システムのリファクタリングという困難な作業に時間を費やす代わりに、まず静的コンテンツを配布します。これにより応答時間が大幅に短縮されるだけでなく、CDN のおかげで静的コンテンツの配布が非常に簡単に実装できます。

CDN は、コンテンツをより効率的に公開するために使用される地理的に分散された Web サーバーのコレクションです。特定のユーザーにサービスを提供する Web サーバーは、通常、ネットワークの距離に基づいて選択されます。

一部の大規模な Web サイトには独自の CDN がありますが、Akamai Technologies、Mirror Image Internet、Limelight Networks などの CDN サービス プロバイダーのサービスを使用するとコスト効率が高くなります。 Yahoo! では、静的コンテンツを CDN に配信することで、ユーザーへの影響時間が 20% 以上短縮されました。コードを変更して CDN に切り替えるのは簡単ですが、Web サイトの速度を向上させることができます。

私たちのアプリ:

まだ使用されていませんが、お客様の報告によると、広東省、山東省などのネットワーク状況が比較的悪いとのことで、メインの帯域幅を占有している静的リソースを CDN 経由で解放できれば、この問題を大幅に軽減できると思います。現在のウェブサイトのアクセス速度の問題。

ルール 3. Expires ヘッダーを追加する

Web コンテンツはますますリッチになり、スクリプト ファイル、スタイル シート、画像ファイル、Flash が増えています。初めて訪問する人は複数の HTTP リクエストに直面する必要がありますが、Expires ヘッダーを使用することでこれらの要素をクライアント側でキャッシュできます。これにより、その後のアクセス時に不要な HTTP リクエストが回避されます。 Expires ヘッダーは画像ファイルに最も一般的に使用されますが、スクリプト ファイル、スタイルシート、および Flash にも使用する必要があります。

ブラウザ (およびプロキシ) はキャッシュを使用して HTTP リクエストの数とサイズを減らし、Web ページの読み込みを高速化します。 Web サーバーは、Expires ヘッダーを通じて要素をキャッシュできる期間をクライアントに伝えます。

サーバーが Apache の場合は、ExpiresDefault を使用して、次のように現在の日付に基づいて有効期限を設定できます:

ExpiresDefault「アクセスプラス 10 年」は、有効期限をリクエスト時から 10 年に設定します。

長い有効期限を使用すると、コンテンツが変更されたときにファイル名を変更する必要があることに注意してください。 Yahoo! では、リリース プロセスのステップとして名前を変更することがよくあります。バージョン番号は yahoo_2.0.6.js のようにファイル名に埋め込まれます。

私たちのアプリ:

外国貿易: JS、CSS、および画像のキャッシュは Apache で構成されており、静的リソースを更新する必要がある場合は、クライアントが最新バージョンを取得できるようにファイルのバージョン番号を変更するソリューションが採用されます。

E-Network: E-Networkのプローブルール(JS)はお客様の設定に応じて生成されますが、基本的に長期間変更されないため、ルール生成時にexpiresレスポンスが付加されます。クライアント要求とプローブ ルール生成の数を最小限に抑えます。

ルール 4. ページ要素を圧縮する

HTTP 応答コンテンツを圧縮することで、ページの応答時間を短縮します。 HTTP/1.1 以降、Web クライアントは、次のような HTTP リクエストの Accept-Encoding ヘッダーを通じて、サポートされている圧縮タイプを示します。 Accept-Encoding: gzip、deflate。

Web サーバーが Accept-Encoding ヘッダーをチェックする場合、クライアントによってサポートされているメソッドを使用して HTTP 応答を圧縮し、Content-Encoding: gzip などの Content-Encoding ヘッダーを設定します。

Gzip は現在最も人気があり効果的な圧縮方法です。 deflate などの他の方法は効果が低く、十分に普及していません。 Gzip を使用すると、通常、コンテンツを 70% 削減できます。 Apache の場合、バージョン 1.3 では mod_gzip モジュールを使用する必要があり、バージョン 2.x では mod_deflate を使用する必要があります。

Webサーバーはファイルの種類に基づいて圧縮するかどうかを決定します。ほとんどの Web サイトは HTML ファイルを圧縮します。ただし、スクリプト ファイルやスタイルシートを圧縮することも価値があります。実際、XML や JSON などのタスクのテキスト情報を圧縮することには価値があります。画像ファイルと PDF ファイルは本質的に圧縮されているため、圧縮しないでください。圧縮すると CPU を浪費するだけでなく、ファイル サイズが増加する可能性があります。

そのため、できるだけ多くのファイル タイプを圧縮することが、ページ サイズを削減し、ユーザー エクスペリエンスを向上させる簡単な方法です。

私たちのアプリ:

外国貿易、E-net、K プラン: 600K を超える ext2 パッケージを圧縮することを考えるでしょう。圧縮効果は悪くありませんが、150K を超えるだけです。さらに、JS、CSS、HTML も可能な限り圧縮されています。当社の顧客の多くは依然として 1M ADSL を使用していることを知っておく必要があります。

ルール 5. スタイルシートを頭の上に置きます

スタイルシートを HEAD セクションに移動するとインターフェースの読み込み速度が向上することがわかり、これによりページ要素を順番に表示できるようになります。

IE などの多くのブラウザーでは、スタイル シートをドキュメントの下部に配置すると、Web コンテンツの連続表示が妨げられるという問題があります。ブラウザーはページ要素の再描画を避けるために表示をブロックし、ユーザーには空白のページのみが表示されます。 Firefox は表示をブロックしませんが、スタイルシートのダウンロード後に一部のページ要素を再描画する必要がある可能性があり、ちらつきの問題が発生する可能性があります。

HTML 仕様

では、スタイル シートを HEAD で定義することが明示的に要求されているため、空白の画面やちらつきの問題を回避するには、HTML 仕様に従い、スタイル シートを HEAD に配置することが最善の方法です。 私たちのアプリ:

文書の最後にスタイルシートを配置する状況に遭遇したことがありますか?

ルール6. スクリプトファイルを一番下に置く

スタイル ファイルと同様に、スクリプト ファイルの場所に注意する必要があります。それらをページの下部に配置して、順番に表示して最大限の並列ダウンロードを実現できるようにする必要があります。

スタイルシートがダウンロードされるまでブラウザは表示をブロックするので、スタイルシートをHEADセクションに置く必要があります。スクリプトの場合、スクリプトの後ろにあるコンテンツの連続表示がブロックされるため、スクリプトをできるだけ下に配置すると、より多くのコンテンツをすばやく表示できます。

このスクリプトによって引き起こされる 2 番目の問題は、並列ダウンロードの数がブロックされることです。 HTTP/1.1 仕様では、ブラウザーがホストごとに並行ダウンロードを 2 つまでにすることを推奨しています。したがって、イメージ ファイルを複数のマシンに配布すると、2 つを超える並列ダウンロードを実現できます。ただし、スクリプト ファイルがダウンロードされるとき、ブラウザは他の並行ダウンロードを開始せず、他のホストからのダウンロードも開始しません。

場合によっては、スクリプトを一番下に移動するのが難しい場合があります。たとえば、スクリプトは document.write メソッドを使用してページ コンテンツを挿入します。ドメインの問題も考えられます。ただし、多くの場合、いくつかの方法があります。

別の方法は、遅延スクリプトを使用することです。 DEFER 属性は、スクリプトに document.write が含まれていないことを示し、ブラウザーに直ちに表示を続けるよう指示します。残念ながら、Firefox は DEFER 属性をサポートしていません。 IE では、スクリプトが遅延する場合がありますが、必ずしも必要なだけ遅延するわけではありません。しかし、別の観点から見ると、スクリプトを遅らせることができる場合は、最下位に配置することができます。

私たちのアプリ:

これまで気づかなかったかもしれませんが、このルールを XCube XUI に実装しました。これにより、ページ アクセスのパフォーマンスがさらに向上すると信じています。

ルール 7. CSS 式を避ける

CSS 式は、CSS プロパティを動的に設定する強力な (そして危険な) 方法です。 IE バージョン 5 以降では、backgourd-color:expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”) などの CSS 式がサポートされています。つまり、背景色の切り替えです。毎時 。

CSS 式の問題は、多くの人が望むよりも多くの回数実行されることです。式は、ページが表示されサイズ変更されたときだけでなく、ページがスクロールされたときやマウスがページ上に移動したときも評価されます。

CSS 式の実行回数を減らす 1 つの方法は、初回実行時に式を明示的な値に置き換えるワンショット式を使用することです。動的に設定する必要がある場合は、代わりにイベント ハンドラーを使用できます。 CSS 式を使用する必要がある場合は、CSS 式が何千回も実行され、ページのパフォーマンスに影響を与える可能性があることに注意してください。

私たちのアプリ:

現在、CSSのメンテナンス作業は主にUI担当者が担当しており、この状況を避けるために最善を尽くしています。

ルール8. JavaScriptとCSSを外部ファイルに入れる

上記のパフォーマンス最適化ルールの多くは、外部ファイルに基づいて最適化されます。ここで、JavaScript と CSS は外部ファイルに含めるべきか、それともページ ファイル内に含めるべきかという質問をする必要があります。

現実の世界では、外部ファイルはブラウザによってキャッシュされるため、外部ファイルを使用するとページの表示が高速化されます。 JavaScript と CSS がページに組み込まれている場合、HTTP リクエストの数は減りますが、ページのサイズは増加します。一方、外部ファイルを使用するとブラウザによってキャッシュされるため、HTTP リクエストの数を増やすことなくページ サイズが削減されます。

したがって、一般的に言えば、外部ファイルを使用する方がより現実的な方法です。唯一の例外は、Yahoo! と My Yahoo! などのホームページではインライン方式の方が効果的です。一般に、セッション中は現時点ではホームページへのアクセスが少ないため、インライン方式の方がユーザーの応答時間を短縮できます。

私たちのアプリ:

外国貿易、E-net、K プラン: ext2 コードは優れたガイドを提供します。現在、フロントエンド開発者はクライアント モジュールのカプセル化と再利用に細心の注意を払っており、外部 JS を通じてコードの再利用を改善しようとしています。もちろん、外部リソースを持ち込みすぎないように注意してください。これはルール 1 に違反します。
現在の CSS のカプセル化も優れていますが、主に IE シリーズ向けのソリューションであり、ブラウザーの互換性の問題を簡単に解決するために YAML やブループリントなどの CSS フレームワークの導入を検討できます。

ルール 9. DNS クエリの数を減らす

DNS は、ホスト名と IP アドレスのマッピングに使用されます。通常、解決には 20 ～ 120 ミリ秒かかります。より高いパフォーマンスを実現するために、DNS 解決は通常、ISP または LAN によって維持されるキャッシュ サーバー、ローカル マシンのオペレーティング システム (Windows 上の DNS クライアント サービスなど) のキャッシュ、ブラウザーなどの複数のレベルでキャッシュされます。 IE のデフォルトの DNS キャッシュ時間は 30 分、Firefox のデフォルトのバッファ時間は 1 分です。

ホスト名を減らすとDNSクエリの数を減らすことができますが、並列ダウンロードの数が減る可能性があります。 DNS クエリを回避すると応答時間が短縮される可能性がありますが、並列ダウンロードの数を減らすと応答時間が長くなる可能性があります。実行可能な妥協策は、コンテンツを少なくとも 2 つ、最大 4 つの異なるホスト名に分散することです。

私たちのアプリ:

外国貿易: ブラウザーのダウンロード スレッド数の制限を回避するために、静的リソースに対して複数のドメイン名を有効にしましたが、これはこのルールに違反します。ただし、Windows IE の場合は、DNS キャッシュによってこの問題を軽減できます。

ルール 10. JavaScript コードを最小限に抑える

JavaScript コードを最小限に抑えるとは、JS コード内の不要な文字を削除することを意味し、それによってダウンロード時間を短縮します。人気のある 2 つのツールは、#JSMin と YUI Compressor です。

難読化は、ソース コードを最小限に抑える別の方法です。 minify と同様に、コメントや空白を削除してソース コードのサイズを削減し、コードを難読化することもできます。難読化の一環として、関数名と変数名が短い文字列に置き換えられるため、コードがよりコンパクトになり、読みにくくなり、リバース エンジニアリングが困難になります。 Dojo Compressor (ShrinkSafe) は、最も一般的な難読化ツールです。

最小化は安全で簡単なプロセスですが、難読化はより複雑で問題が発生しやすくなります。米国の上位 10 の Web サイトの調査によると、最小化によりファイルを 21% 削減し、難読化を 25% 削減できます。

外部スクリプト ファイルを最小限に抑えることに加えて、埋め込みスクリプト コードも最小限に抑える必要があります。ルール 4 に従ってスクリプトが送信用に圧縮されている場合でも、スクリプトを最小化するとファイル サイズが 5% 以上削減されます。

私たちのアプリ:

JS 圧縮を直接使用しませんが、ext2、jquery など、使用する多くのコンポーネントはすでにこのルールを実践しています。

ルール 11. リダイレクトを避ける

リダイレクト機能は、次のような 2 つの HTTP ステータス コード 301 および 302 によって完了します。 リーリー リーリー リーリー

ブラウザは、Location で指定された URL にリクエストを自動的にリダイレクトします。リダイレクトの主な問題は、ユーザー エクスペリエンスが低下することです。

最もリソースを消費し、頻繁に見落とされやすいリダイレクトの 1 つは、URL の末尾に / がないことです。たとえば、http://astrology.yahoo.com/astrology にアクセスすると http:// にリダイレクトされます。 astrology.yahoo.com/astrology/。 Apache では、この問題は Alias、mod_rewrite、または DirectorySlash によって解決できます。

私たちのアプリ:

経験豊富な SA がこの問題をすでに検討しています。興味のある学生は、オンライン環境の Apache 設定ファイル httpd.conf を参照してください。

ルール12. 重複したスクリプトファイルを削除する

ページに重複した JS スクリプト ファイルを含めると、パフォーマンスに影響します。つまり、不要な HTTP リクエストや追加の JS 実行が作成されます。

IEでは不要なHTTPリクエストが発生しますが、Firefoxでは不要なHTTPリクエストが生成されません。追加の JS の実行は、IE または Firefox のどちらで実行されているかに関係なく発生します。

スクリプト ファイルの重複を避ける 1 つの方法は、テンプレート システムを使用してスクリプト管理モジュールを作成することです。このモジュールは、スクリプト ファイルの重複を防ぐだけでなく、依存関係チェックも実装し、スクリプト ファイル名にバージョン番号を追加するため、有効期限を非常に長くすることができます。

私たちのアプリ:

この問題は Xplatform の古いバージョンでより深刻ですが、XCube の新しいバージョンでは同じ間違いは繰り返さないと私は信じています。

ルール 13. ETag を設定する

ETags は、ブラウザー キャッシュ内の要素が Web サーバー内の要素と一致するかどうかを判断するために使用されるメカニズムであり、最終更新日よりも柔軟な要素検証メカニズムです。 ETag は要素のバージョンを一意に表す文字列であり、引用符で囲む必要があります。 Web サーバーは最初に応答で ETag を指定します:

リーリー リーリー リーリー リーリー

その後、ブラウザは要素を検証する必要がある場合、If-None-Match ヘッダーを使用して ETag を Web サーバーに返します。ETag が一致すると、サーバーは 304 コードを返すため、ダウンロード時間が節約されます。 リーリー リーリー リーリー リーリー リーリー

ETag の問題は、ETag が Apache1.3 や 2.x などのサーバー固有の属性に基づいて構築され、その形式が inode-size-timestamp であるのに対し、IIS5.0 および 6.0 では形式が Filetimestamp であることです。 :変更番号。このように、異なる Web サーバー上の同じ要素の ETag は異なります。このように、マルチ Web サーバー環境では、ブラウザは最初にサーバー 1 に要素を要求し、次にサーバー 2 で要素を検証します。ETag が異なるため、キャッシュは無効になり、再度ダウンロードする必要があります。

したがって、ETags システムが提供する柔軟な検証メカニズムを使用しない場合は、ETag を削除することが最善です。 ETag を削除すると、HTTP 応答と後続の要求の HTTP ヘッダーのサイズが削減されます。 Microsoft のサポート記事には、ETag を削除する方法が説明されています。Apache では、構成ファイルで FileETag none を設定するだけです。

私たちのアプリ:

E-Network: ETag 生成戦略をカスタマイズして、プローブ ルールの生成回数を最小限に抑えます。サーバーのデフォルトの ETag は使用されないため、この問題は存在しません。

その他の製品ライン: Apache の設定をすぐに確認する人はいません。

ルール 14. Ajax のキャッシュ

パフォーマンス最適化ルールは Web 2.0 アプリケーションにも適用されます。 Ajax のパフォーマンスを向上させる最も重要な方法は、「ルール 3: Expires ヘッダーの追加」で説明したように、応答をキャッシュ可能にすることです。以下の他のルールも Ajax に適用されます。もちろんルール 3 が最も効果的な方法です:

ルール 4. ページ要素を圧縮する

ルール 9. DNS クエリの数を減らす

ルール 10. スクリプト ファイルを最小限に抑える

ルール 11. リダイレクトを避ける

ルール 13.ETag を設定する

私たちのアプリ:

現時点では、Ajax リクエストをキャッシュしたくない場合は、各 Ajax リクエストの URL にタイムスタンプを追加するだけです。