Yahoo 14 のパフォーマンス最適化原則_html/css_WEB-ITnose

ウェブサイトのパフォーマンスを最適化し、ウェブサイトのアクセス速度を改善するための 14 のヒント

「Yahoo 14 のヒント」とも呼ばれる、1 年前、大学のフロントエンド面接のために愚かにも大学街に行った無知な自分のことを思い出します。当時、冬休みと夏休みに見ようと思って、始める前にビデオを 2 セット作りました。まあ、これは絶対的な位置です、まあ、これはフローティングクリアです...

当時私は私の叔父がその人を知りませんでした。彼は全身黒人でした。 Tシャツ、黒い肌、黒い帽子、そして少し黒い無精ひげを生やした彼は、テストの問題を終えた後、躊躇しながら彼と話しましたが、最初の質問はそれがまったく不可能であることがわかりました。 「ヤフー14ルール」？それで、聞いたこともなかったので混乱しましたが、家に帰ってからQQスペースにログを投稿しましたが、当時はそれについてあまり知りませんでした。今日は一日中、みんなと共有するために投稿しました:

インターネットは人々の生活にますます不可欠な部分になっていると思います。 AjaxやFlexなどのリッチクライアントアプリケーションでは、C/Sでしか実装できない機能を数多く体験できるので、人々はより「幸せ」になります。たとえば、Google は最も基本的なオフィス アプリケーションをすべてインターネットに移行しました。もちろん、便利ではありますが、ページの表示がどんどん遅くなるのは間違いありません。私はフロントエンドの開発者ですが、Yahoo の調査によると、パフォーマンスの点ではバックエンドが 5% しか占めていないのに対し、フロントエンドは 95% も占め、そのうち 88% は最適化できます。

上記は、Web2.0 ページのライフサイクル図です。エンジニアたちは、それを「妊娠、出産、卒業、結婚」の 4 つの段階に分けて生き生きと説明しています。 Web リンクをクリックしたときに、単純なリクエストとレスポンスではなくこのプロセスを認識できれば、パフォーマンスを向上させるための多くの詳細を掘り出すことができます。今日、Yahoo 開発チームによる Web パフォーマンス研究に関する Taobao Xiaoma Ge 氏の講義を聞いて、多くのことが得られたと感じたので、それをブログで共有したいと思います。

ウェブサイトのパフォーマンスを最適化するための 14 のルールについて聞いたことがある人は多いと思います。詳細については、developer.yahoo.com をご覧ください

1. HTTP リクエストの数をできる限り減らす [コンテンツ]

2. CDN (コンテンツ配信ネットワーク) を使用する [サーバー]

3. Expires ヘッダーを追加します。または Cache-control ) [server]

4. Gzip コンポーネント [server]

5. CSS スタイルをページの上部に配置します [css]

6. スクリプトを下部に移動します (インラインを含む)

7 . CSS での式の使用を避ける [css]

8. JavaScript と CSS を外部ファイルに分離する [javascript]

9. DNS クエリを削減する [content]

10. JavaScript と CSS を圧縮する (インラインを含む) [javascript] [css]

11. リダイレクトを回避する [server]

12. 重複したスクリプトを削除する [javascript]

13. AJAX キャッシュを有効にする

があります。 firebug に統合されている Firefox 上のプラグイン yslow を使用すると、これらの側面で Web サイトのパフォーマンスを簡単にチェックできます。

これは、yslow を使用して私の Web サイト Xifengfang を評価した結果です。残念ながら、スコアは 51 しかありません。ふふ。主要な中国のウェブサイトのスコアは高くありません。テストを受けたところ、Sina と NetEase は両方とも 31 でした。すると、Yahoo (USA) のスコアは実に 97 ポイントでした。これは、この点における Yahoo の努力を示しています。彼らがまとめた14のルールと新たに追加された20のポイントから判断すると、実際には私たちがまったく考えていない詳細がたくさんあり、いくつかの実践は少し「倒錯的」ですらあります。

1 つ目は、HTTP リクエストの数をできる限り減らすことです (HTTP リクエストの数を減らす)

http リクエストは高価であり、リクエストの数を減らす方法を見つけることで、自然に HTTP リクエストの速度を上げることができます。ウェブページ。一般的に使用される方法には、css、js のマージ (ページ内の css ファイルと js ファイルをそれぞれマージする)、イメージ マップ、CSS スプライトなどが含まれます。もちろん、css と js ファイルを複数のファイルに分割するのは、css の構造や共有などの考慮事項によるものかもしれません。当時のアリババの中国 Web サイトのアプローチは、Web サイトを個別に開発し、バックグラウンドで JS と CSS をマージすることでした。この方法では、ブラウザーに対するリクエストは 1 つでしたが、開発中に複数のリクエストに復元できるため、管理が容易になりました。繰り返しの参照。 Yahoo では、ホームページの CSS と JS を外部参照ではなくページ ファイルに直接書き込むことを推奨しています。ホームページへのアクセス数が多すぎるため、リクエストの数を 2 件減らすこともできます。実際、多くの国内ポータルがこれを行っています。

CSS スプライトは、ページ上の背景画像のみを使用して 1 つにマージし、CSS のbackground-position プロパティで定義された値を使用して背景を取得します。タオバオとアリババの中国サイトは現在これを行っています。興味があれば、タオバオとアリババの背景画像をご覧ください。

http://www.csssprites.com/ これは、アップロードした画像を自動的に結合し、対応する背景の位置座標を与えることができるツール Web サイトです。そして、結果を png および gif 形式で出力します。

第 2 条、CDN (コンテンツ配信ネットワーク) の使用: コンテンツ配信ネットワークを使用します

正直に言うと、CDN についてはあまり詳しくありません。簡単に言うと、既存のインターネットに新しいネットワーク アーキテクチャの層を追加することで、Web サイトのコンテンツがユーザーに最も近いキャッシュ サーバーに公開されます。 DNS 負荷分散テクノロジーは、ユーザーの出身地を判断し、近くのキャッシュ サーバーにアクセスして必要なコンテンツを取得します。杭州のユーザーは杭州近郊のサーバー上のコンテンツにアクセスし、北京のユーザーは北京近郊のサーバー上のコンテンツにアクセスします。これにより、ネットワーク上のデータ送信時間が効果的に短縮され、速度が向上します。さらに詳しい情報については、Baidu Encyclopedia の CDN の説明を参照してください。 Yahoo! は静的コンテンツを CDN に配信し、ユーザーの影響時間を 20% 以上短縮します。

CDN 技術図:

CDN ネットワーク図:

記事 3: Expire/Cache-Control ヘッダーの追加: Expires ヘッダーの追加

今ではますますページに埋め込まれる画像、スクリプト、CSS、Flash が増えると、それらにアクセスするときに行う http リクエストも増えます。実際、Expires ヘッダーを設定することで、これらのファイルをキャッシュできます。 Expire は実際には、ヘッダー メッセージを通じてブラウザー内の特定の種類のファイルのキャッシュ時間を指定します。 Flash 内のほとんどの画像は、キャッシュした後は頻繁に変更する必要がなく、今後、ブラウザーはこれらのファイルをサーバーからダウンロードする必要がなく、キャッシュから直接読み取るため、アクセスが高速化されます。ページが再び大幅に高速化されます。一般的な HTTP 1.1 プロトコルはヘッダー情報を返します:

HTTP/1.1 200 OK

Date: Fri, 30 Oct 1998 13:19:41 GMT

Server: Apache/1.3.3 (Unix)

Cache-Control : max -age=3600、要再検証

有効期限: Fri, 30 Oct 1998 14:19:41 GMT

Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT

ETag: “3e86-410 -3596fbbc ”

Content-Length: 1040

Content-Type: text/html

これは、サーバー側スクリプトを通じてキャッシュ制御と有効期限を設定することで実行できます。

たとえば、php で有効期限を 30 日後に設定します:

以下は引用された内容です:

ef906d604c79789194090d154f7332a8 andlt;link rel=”stylesheet” rev=”stylesheet” href=”http://www.space007.com/css/print.css” type=”text/css” ”media="print" />。メディアから、最初の CSS ファイルがブラウザー用で、2 番目の CSS ファイルが印刷スタイル用であることがわかります。ユーザーの行動習慣から判断すると、ページを印刷するというアクションは、ページが表示された後に発生するはずです。したがって、より良い方法は、ページが読み込まれた後に印刷デバイス用の CSS をこのページに動的に追加することです。これにより、速度が少し向上します。 (笑)

第6条 ページの一番下にスクリプトを置く(Put Scripts at the Bottom)

ページの下部にスクリプトを配置する目的は 2 つあります: 1. スクリプトの実行によってページのダウンロードがブロックされるのを防ぐため。ページの読み込みプロセス中に、ブラウザが js 実行ステートメントを読み取ると、それをすべて解釈して、次のコンテンツを読み取ります。信じられない場合は、js の無限ループを作成して、ページの下にあるものが表示されるかどうかを確認してください。 (setTimeout と setInterval の実行はマルチスレッドに似ており、次のコンテンツのレンダリングは対応する応答時間の前に続行されます。) これを行うブラウザーのロジックは、js がいつでも location.href を実行するか、そうでなければ完全に実行する可能性があるためです。このページを中断する プロセスの機能、つまり、ロードする前に実行されるまで待機する必要があります。したがって、これをページの最後に配置すると、ページの視覚要素の読み込み時間を効果的に短縮できます。 2. このスクリプトによって引き起こされる 2 番目の問題は、並列ダウンロードの数がブロックされることです。 HTTP/1.1 仕様では、ブラウザのホストあたりの並列ダウンロード数が 2 を超えないよう推奨しています (IE は 2 までしか指定できません。FF などの他のブラウザはデフォルトで 2 に設定されていますが、新しい IE8 では 6 に達する可能性があります)。したがって、イメージ ファイルを複数のマシンに配布すると、2 つを超える並列ダウンロードを実現できます。ただし、スクリプト ファイルのダウンロード中、ブラウザは他の並行ダウンロードを開始しません。

もちろん、各 Web サイトで、ページの下部にスクリプトを読み込む実現可能性には依然として疑問があります。アリババの中国語ウェブサイトのページと同じです。多くの場所にインライン JS があり、ページの表示はこれに大きく依存しています。これが非侵入型スクリプトの概念からはほど遠いことは認めますが、多くの「歴史的問題」はそう簡単には解決できません。

第 7 条: CSS での式の使用を避ける (CSS Expressions を避ける)

しかし、これにより無意味なネストが 2 層追加されることになり、これは明らかに良くありません。より良い方法が必要です。

第8条 JavaScriptとCSSの両方を外部ファイルに置く（Make JavaScript and CSS External）

これがわかりやすいと思います。これは、パフォーマンスの最適化の観点からだけでなく、コードのメンテナンスの容易さの観点からも行われます。ページコンテンツに css と js を記述すると 2 つのリクエストを減らすことができますが、ページのサイズも大きくなります。 CSS と JS がキャッシュされている場合、余分な http リクエストは発生しません。もちろん、前に述べたように、一部の特別ページ開発者は引き続きインライン css および js ファイルを選択します。

第 9 条、DNS ルックアップの削減

インターネットでは、ドメイン名と IP アドレスは 1 対 1 に対応しています。ドメイン名 (kuqin.com) は覚えやすいですが、コンピューターはそれを覚えています。コンピュータ間の「認識」もIPアドレスに変換する必要があります。ネットワーク上の各コンピュータは、独立した IP アドレスに対応します。ドメイン名と IP アドレス間の変換はドメイン名解決と呼ばれ、DNS クエリとも呼ばれます。 DNS 解決プロセスには 20 ～ 120 ミリ秒かかります。DNS クエリが完了するまで、ブラウザはドメイン名の下に何もダウンロードしません。したがって、DNS クエリの時間を短縮すると、ページの読み込み速度が向上します。 Yahoo では、1 ページに含まれるドメイン名の数を 2 ～ 4 に制限することを推奨しています。これには、ページ全体を適切に計画する必要があります。現時点ではこの点でうまくいっておらず、多くの広告配信システムの足を引っ張られています。

第 10 条、JavaScript と CSS を圧縮する (JavaScript を縮小する)

js と css を圧縮する効果は、明らかにページ上のバイト数を減らすことです。容量が小さいページは、当然のことながら読み込みが速くなります。圧縮は、ボリュームを減らすだけでなく、一定の保護も提供します。私たちはこれをうまくやっています。一般的に使用される圧縮ツールには、JsMin、YUI 圧縮ツールなどが含まれます。さらに、http://dean.edwards.name/packer/ は、非常に便利なオンライン圧縮ツールも提供します。圧縮された js ファイルと圧縮されていない js ファイルの容量の違いは、jQuery Web ページで確認できます。

もちろん、圧縮の欠点の 1 つは、コードの可読性が失われることです。フロントエンドの友人の多くはこの問題に遭遇したことがあると思います。Google を見ると素晴らしい効果が得られますが、そのソース コードを見ると、たくさんの文字が詰め込まれており、関数名さえ置き換えられています。このように独自のコードを保守するのは非常に不便ではありませんか?すべての Alibaba 中国 Web サイトで採用されている現在のアプローチは、リリース時にサーバー側で js と css を圧縮することです。これにより、独自のコードを保守するのが非常に便利になります。

第 11 条、リダイレクトの回避

少し前に ieblog で「Internet Explorer と接続制限」という記事を見ました。たとえば、http://www.kuqin .com/ と入力すると、サーバーはhttp://www.kuqin.com/ への 301 サーバー リダイレクトが自動的に生成されます。ブラウザのアドレス バーを見るとそれを確認できます。この種のリダイレクトには当然時間がかかります。もちろん、これは単なる例であり、リダイレクトにはさまざまな理由がありますが、リダイレクトが追加されるたびに Web リクエストが増加するため、可能な限り削減する必要があることは変わりません。

第12条 重複したスクリプトの削除

これはパフォーマンスの観点だけでなく、コードの仕様の観点からも考えなくてもわかります。しかし、処理が非常に速いため、繰り返しコードを追加することが多いことを認めなければなりません。おそらく、統合された css フレームワークと js フレームワークが問題をより良く解決できるでしょう。 Xiaozhu 氏の意見は正しいです。同じことを繰り返さないだけでなく、再利用できるようにする必要もあります。

第13条 エンティティタグ（ETag）の設定（Configure ETag）

これもよくわかりません（笑）。 infoQ で「ETags を使用して Web アプリケーションの帯域幅と負荷を軽減する」で詳細な説明を見つけました。興味のある学生はチェックしてください。

第 14 条 Ajax をキャッシュ可能にする

Ajax をキャッシュする必要がある場合、Ajax リクエストを行うとき、キャッシュされないようにタイムスタンプが追加されることがよくあります。 「非同期」は「即時」を意味するものではないことに留意することが重要です。 AJAX メッセージが動的に生成され、1 人のユーザーのみに影響を与える場合でも、キャッシュに保存できることに注意してください。

今できることは、CSS、パズル、冗長性を減らすための圧縮、CSS が YSlow で「A」として表示されるようにすることです。サーバーの種類に関しては、長い道のりがあります。行きましょう、ゆっくり学びましょう... 情熱があれば、遅かれ早かれ学びます...


14 項目が大幅に拡張されているので、後で追加します。この記事の詳細な分析:

http://uicss.cn/yslow/#more-12319

Yslow では 23 個のアイテムが表示されます。下の写真を参照してください:

HTTP リクエストの数を減らします
画像、CSS、JS を結合して、初めてのユーザーの待ち時間を短縮します。 CDN を使用します。 ==> インテリジェント ルーティング ==> 空の src および href を回避します。
link タグの href 属性が空の場合、 script タグが空です レンダリング時に、ブラウザは現在のページの URL を属性値として使用し、それによってページのコンテンツをその値として読み込みます。ファイル ヘッダー
に Expires を指定して、コンテンツをキャッシュ可能にするテストを行います。以降のページ訪問では不要な HTTP リクエストを避けてください。 gzip を使用してコンテンツを圧縮します
XML や JSON などのテキスト タイプの応答を圧縮することには価値があります。 CSS を上部に、JS を下部に配置して、JS の読み込みによって後続のリソースがブロックされるのを防ぎます。 CSS 式の使用を避け、CSS と JS を外部ファイルに配置します。目的はキャッシュですが、リクエストを減らすために、PV と IP の比率に応じてページに直接書き込む必要がある場合があります。 DNS ルックアップの数を比較検討する
ホスト名を減らすと、応答時間が節約されます。ただし同時に、ホストを減らすとページ内の並列ダウンロードの数も減ることに注意することが重要です。
IE ブラウザは、同じドメイン名から同時に 2 つのファイルしかダウンロードできません。 1 ページに複数の画像を表示すると、IE ユーザーの画像ダウンロード速度に影響します。したがって、Sina は写真を配置するために N 個の第 2 レベルのドメイン名を作成します。 CSS と JS を合理化してジャンプを回避します
同じドメイン: バックスラッシュ "/" によるジャンプを避けるように注意してください
クロスドメイン: エイリアスまたは mod_reirte を使用して CNAME (ドメイン名間の関係を保存する DNS レコード) を確立します 重複した JS を削除しますおよび CSS
スクリプトを繰り返し呼び出すと、追加の HTTP リクエストが追加されるだけでなく、複数の操作で時間が無駄になります。 IE と Firefox では、スクリプトがキャッシュ可能かどうかに関係なく、JavaScript の再評価という問題が発生します。 ETag を構成する
これは、ブラウザー キャッシュ内の要素が元のサーバー上の要素と一致しているかどうかを判断するために使用されます。たとえば、ファイルが 1 秒間に 10 回変更された場合、Etag は Inode (ファイルのインデックス ノード (inode) の数)、MTime (変更時刻) に基づいて正確に判断できます。これにより、UNIX での MTime の正確な記録が秒単位でしかできないという問題が回避されます。 サーバー クラスターを使用する場合は、最後の 2 つのパラメーターを使用できます。 ETags Cacheable AJAX を使用して Web アプリケーションの帯域幅と負荷を削減します
「非同期」は「即時」を意味しません: Ajax は、ユーザーが非同期 JavaScript および XML 応答の待機に時間を費やさないことを保証しません。 GET を使用して AJAX リクエストを完了します
XMLHttpRequest を使用する場合、ブラウザの POST メソッドは「2 段階」のプロセスです。最初にファイル ヘッダーを送信し、次にデータを送信します。したがって、GET を使用してデータを取得する方が合理的です。 DOM 要素の数を減らしてください
使用できるより適切なタグはありますか?意味のないタグの乱用を避け、404 を回避するためのセマンティック タグ
一部のサイトでは、404 エラー応答ページを「**をお探しですか?」に変更します。これによりユーザー エクスペリエンスは向上しますが、サーバー リソース (データベースなど) も浪費されます。 。最悪のシナリオは、外部 JavaScript へのリンクが誤動作し、404 コードを返すことです。まず、この読み込みにより並列読み込みが破壊されます。次に、ブラウザは、返された 404 応答コンテンツ内で、実行する JavaScript コードとして有用な部分を見つけようとします。 Cookie のサイズを減らし、画像 CSS などの Cookie を使用しないドメイン
を使用します。Yahoo! の静的ファイルはすべて yimg.com 上にあり、クライアントが静的ファイルをリクエストすると、メイン ドメインへの Cookie の繰り返し送信が減ります。名前 (yahoo.com) 影響力。 フィルターを使用しないでください
png24 は IE6 では半透明です。ランダムに使用せず、落ち着いて PNG8+jpg に切り分けてください。favicon.ico とキャッシュを削減します。HTTP リクエストを最小限に抑えます。
tag: content

エンドユーザーの応答時間の 80% は、ページ内のすべてのコンポーネント (画像、スタイルシート、スクリプト、Flash など) のダウンロードに費やされます。コンポーネントの数を減らす。ターンは、ページのレンダリングに必要な HTTP リクエストの数を減らします。これがページを高速化する鍵です。

ページ内のコンポーネントの数を減らす 1 つの方法は、ページのデザインを簡素化することです。リッチなページ デザインをサポートしながら、HTTP リクエストの数を減らすためのテクニックをいくつか紹介します。

結合ファイルは、すべてのスクリプトを 1 つのスクリプトに結合することで HTTP リクエストの数を減らす方法です。 、同様に、すべての CSS を 1 つのスタイルシートに結合することもできます。スクリプトとスタイルシートがページごとに異なる場合、ファイルの結合はより困難になりますが、これをリリース プロセスの一部にすると、応答時間が短縮されます。

CSS スプライトは、画像リクエストの数。背景画像を 1 つの画像に結合し、CSSbackground-image プロパティと background-position プロパティを使用して、目的の画像セグメントを表示します。

画像マップは、複数の画像を 1 つの画像に結合します。全体のサイズはほぼ同じですが、HTTP リクエストの数を減らすとページの速度が向上します。イメージ マップは、ナビゲーション バーなど、ページ内でイメージが連続している場合にのみ機能します。イメージ マップの座標を定義するのは面倒で、間違いが発生しやすい作業です。ナビゲーションに画像マップを使用することもアクセスできないため、お勧めできません。

インライン画像では、data: URL スキームを使用して画像データを実際のページに埋め込みます。これにより、HTML ドキュメントのサイズが増加する可能性があります。インライン画像を (キャッシュされた) スタイルシートに結合することは、HTTP リクエストを削減し、ページのサイズの増加を回避する方法です。インライン画像は、すべての主要なブラウザーでまだサポートされていません。

まずは、ページ内の HTTP リクエストの数を減らすことから始めます。これは、初めての訪問者のパフォーマンスを向上させるための最も重要なガイドラインです。 Tenni Theurer のブログ投稿「ブラウザ キャッシュの使用状況 - 暴露!」で説明されているように、サイトへの毎日の訪問者の 40 ～ 60% は空のキャッシュを持っています。このような初めての訪問者にとってページを高速にすることが、ユーザー エクスペリエンスを向上させる鍵となります。

top | このルールについて話し合う

コンテンツ配信ネットワークを使用する

tag: サーバー

ユーザーが Web サーバーに近いかどうかは、応答時間に影響します。地理的に分散した複数のサーバーにコンテンツを展開すると、ユーザーの観点からページの読み込みが速くなります。しかし、どこから始めるべきでしょうか?

地理的に分散したコンテンツを実装する最初のステップとして、分散アーキテクチャで動作するように Web アプリケーションを再設計しようとしないでください。アプリケーションによっては、アーキテクチャの変更には、セッション状態の同期やサーバーの場所間でのデータベース トランザクションのレプリケーションなどの困難なタスクが含まれる場合があります。ユーザーとコンテンツとの距離を縮めようとする試みは、このアプリケーション アーキテクチャのステップによって遅れたり、通過できなかったりする可能性があります。

エンドユーザーの応答時間の 80 ～ 90% が、ページ内のすべてのコンポーネントのダウンロードに費やされることに注意してください: 画像、スタイルシート、スクリプト、Flash など。これがパフォーマンスの黄金律です。アプリケーション アーキテクチャを再設計するという難しい作業から始めるのではなく、まず静的コンテンツを分散することをお勧めします。これにより、応答時間の大幅な短縮が達成されるだけでなく、コンテンツ配信ネットワークのおかげでより簡単になります。

コンテンツ配信ネットワーク (CDN) は、コンテンツをより効率的にユーザーに配信するために、複数の場所に分散された Web サーバーの集合です。特定のユーザーにコンテンツを配信するために選択されるサーバーは、通常、ネットワークの近接性の尺度に基づいています。たとえば、ネットワーク ホップが最も少ないサーバーや応答時間が最も速いサーバーが選択されます。

一部の大手インターネット企業は独自の CDN を所有していますが、Akamai Technologies、EdgeCast などの CDN サービス プロバイダーを使用する方がコスト効率が高くなります。 、またはレベル3。新興企業やプライベート Web サイトの場合、CDN サービスのコストは法外に高額になる場合がありますが、ターゲット ユーザーが拡大し、よりグローバルになるにつれて、高速な応答時間を実現するには CDN が必要になります。 Yahoo! では、静的コンテンツをアプリケーション ウェブ サーバーから CDN（前述のサードパーティと Yahoo 独自の CDN の両方）に移動した施設により、エンドユーザーの応答時間が 20% 以上改善されました。 CDN への切り替えは比較的簡単なコード変更であり、Web サイトの速度が大幅に向上します。

top | このルールについて議論します

Expires または Cache-Control ヘッダーを追加します

タグ: サーバー

このルールには 2 つの側面があります:

静的コンポーネントの場合: 将来の Expires ヘッダーを設定して「期限切れにしない」ポリシーを実装する 動的コンポーネントの場合:条件付きリクエストでブラウザを支援するための適切な Cache-Control ヘッダー

Web ページのデザインはますます充実しており、ページ内のスクリプト、スタイルシート、画像、Flash が増えています。ページへの初めての訪問者は、いくつかの HTTP リクエストを行う必要があるかもしれませんが、Expires ヘッダーを使用することで、これらのコンポーネントをキャッシュ可能にします。これにより、後続のページビューでの不要な HTTP リクエストが回避されます。 Expires ヘッダーは画像で最もよく使用されますが、スクリプト、スタイルシート、Flash コンポーネントを含むすべてのコンポーネントで使用する必要があります。

ブラウザ (およびプロキシ) はキャッシュを使用して HTTP リクエストの数とサイズを削減し、ウェブページを読み込みますもっと早く。 Web サーバーは、HTTP 応答の Expires ヘッダーを使用して、コンポーネントをキャッシュできる期間をクライアントに伝えます。これは遠い将来の Expires ヘッダーで、この応答は 2010 年 4 月 15 日まで古くならないことをブラウザーに伝えます。

      Expires: Thu, 15 Apr 2010 20:00:00 GMT

サーバーが Apache の場合は、ExpiresDefault ディレクティブを使用して、現在の日付を基準にして有効期限を設定します。この ExpiresDefault ディレクティブの例では、Expires の日付をリクエストの時点から 10 年後に設定します。

      ExpiresDefault "access plus 10 years"

遠い将来の Expires ヘッダーを使用する場合は、コンポーネントが変更されるたびにコンポーネントのファイル名を変更する必要があることに注意してください。ヤフーで！多くの場合、このステップはビルド プロセスの一部になります。バージョン番号はコンポーネントのファイル名に埋め込まれます (例: yahoo_2.0.6.js.

)

遠い未来の Expires ヘッダーの使用は、ユーザーがサイトにすでにアクセスした後にのみページ ビューに影響します。 。ユーザーが初めてサイトにアクセスし、ブラウザーのキャッシュが空の場合、HTTP リクエストの数には影響しません。したがって、このパフォーマンス向上の影響は、ユーザーがプライミング キャッシュを使用してページにアクセスする頻度によって異なります。 （「プライミング キャッシュ」には、ページ内のすべてのコンポーネントがすでに含まれています。）これは Yahoo! で測定されました。 プライミング キャッシュを使用したページ ビューの数は 75 ～ 85% であることがわかりました。遠い将来の Expires ヘッダーを使用すると、ユーザーのインターネット接続を介して 1 バイトも送信せずに、ブラウザーによってキャッシュされ、後続のページ ビューで再利用されるコンポーネントの数が増加します。 このルールについて議論してください

Gzip コンポーネント

tag: サーバー

HTTP リクエストとレスポンスをネットワーク経由で転送するのにかかる時間は、フロントエンド エンジニアの決定によって大幅に短縮できます。確かに、エンドユーザーの帯域幅速度、インターネット サービス プロバイダー、ピアリング交換ポイントへの近さなどは、開発チームの制御の範囲を超えています。ただし、応答時間に影響を与える変数は他にもあります。圧縮により、HTTP 応答のサイズが小さくなり、応答時間が短縮されます。

HTTP/1.1 以降、Web クライアントは、HTTP リクエストの Accept-Encoding ヘッダーを使用して圧縮のサポートを示します。

      Accept-Encoding: gzip, deflate

Web サーバーがこのヘッダーを認識した場合、リクエストを送信すると、クライアントがリストしたメソッドの 1 つを使用してレスポンスを圧縮する場合があります。 Web サーバーは、応答の Content-Encoding ヘッダーを介して Web クライアントにこれを通知します。

      Content-Encoding: gzip

Gzip は、現時点で最も一般的で効果的な圧縮方法です。これは GNU プロジェクトによって開発され、RFC 1952 によって標準化されました。他の唯一の圧縮形式は deflate ですが、効果が低く、あまり普及していません。

Gzip 圧縮は通常、応答サイズを約 70% 削減します。今日のインターネット トラフィックの約 90% は、gzip をサポートすると主張するブラウザを経由して送信されます。 Apache を使用している場合、gzip を構成するモジュールはバージョンによって異なります。Apache 1.3 は mod_gzip を使用しますが、Apache 2.x は mod_deflate を使用します。

ブラウザとプロキシには、ブラウザが期待する内容と受信する内容の不一致を引き起こす可能性がある既知の問題があります。圧縮されたコンテンツに関して。幸いなことに、古いブラウザの使用が減少するにつれて、このようなエッジケースは減少しつつあります。 Apache モジュールは、適切な Vary 応答ヘッダーを自動的に追加することで役立ちます。

サーバーはファイルの種類に基づいて何を gzip するかを選択しますが、通常、圧縮する内容は非常に限られています。ほとんどの Web サイトは HTML ドキュメントを gzip 圧縮します。スクリプトとスタイルシートを gzip 圧縮することも価値がありますが、多くの Web サイトはこの機会を逃しています。実際、XML や JSON を含むあらゆるテキスト応答を圧縮することは価値があります。画像ファイルと PDF ファイルはすでに圧縮されているため、gzip 圧縮しないでください。これらを gzip 圧縮しようとすると、CPU を浪費するだけでなく、ファイル サイズが増加する可能性があります。

できるだけ多くのファイル タイプを Gzip 圧縮することは、ページの重量を軽減し、ユーザー エクスペリエンスを高速化する簡単な方法です。

top | このルールについて話し合ってください

スタイルシートを先頭に置く

tag: css

Yahoo! でパフォーマンスを調査しているときに、スタイルシートをドキュメントの HEAD に移動すると、ページの読み込みが速くなったように見えることがわかりました。これは、スタイルシートを HEAD に配置すると、ページが段階的にレンダリングできるためです。

パフォーマンスを重視するフロントエンド エンジニアは、ページが段階的に読み込まれることを望んでいます。つまり、ブラウザーが持つコンテンツをできるだけ早く表示したいのです。これは、大量のコンテンツを含むページや、低速のインターネット接続を使用しているユーザーにとって特に重要です。進行状況インジケーターなどの視覚的なフィードバックをユーザーに提供することの重要性については、十分に調査され、文書化されています。私たちの場合、HTML ページが進行状況インジケーターです。ブラウザーがページを徐々に読み込むと、ヘッダー、ナビゲーション バー、上部のロゴなどはすべて、ページを待っているユーザーに対する視覚的なフィードバックとして機能します。これにより、全体的なユーザー エクスペリエンスが向上します。

The problem with putting stylesheets near the bottom of the document is that it prohibits progressive rendering in many browsers, including Internet Explorer. These browsers block rendering to avoid having to redraw elements of the page if their styles change. The user is stuck viewing a blank white page.

The HTML specification clearly states that stylesheets are to be included in the HEAD of the page: "Unlike A, [LINK] may only appear in the HEAD section of a document, although it may appear any number of times." Neither of the alternatives, the blank white screen or flash of unstyled content, are worth the risk. The optimal solution is to follow the HTML specification and load your stylesheets in the document HEAD.

top | discuss this rule

Put Scripts at the Bottom

tag: javascript

The problem caused by scripts is that they block parallel downloads. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start any other downloads, even on different hostnames.

In some situations it's not easy to move scripts to the bottom. If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page. There might also be scoping issues. In many cases, there are ways to workaround these situations.

An alternative suggestion that often comes up is to use deferred scripts. The DEFER attribute indicates that the script does not contain document.write, and is a clue to browsers that they can continue rendering. Unfortunately, Firefox doesn't support the DEFER attribute. In Internet Explorer, the script may be deferred, but not as much as desired. If a script can be deferred, it can also be moved to the bottom of the page. That will make your web pages load faster.

top | discuss this rule

Avoid CSS Expressions

tag: css

CSS expressions are a powerful (and dangerous) way to set CSS properties dynamically. They were supported in Internet Explorer starting with version 5, but were deprecated starting with IE8. As an example, the background color could be set to alternate every hour using CSS expressions:

      background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

As shown here, the expression method accepts a JavaScript expression. The CSS property is set to the result of evaluating the JavaScript expression. Theexpression method is ignored by other browsers, so it is useful for setting properties in Internet Explorer needed to create a consistent experience across browsers.

The problem with expressions is that they are evaluated more frequently than most people expect. Not only are they evaluated when the page is rendered and resized, but also when the page is scrolled and even when the user moves the mouse over the page. Adding a counter to the CSS expression allows us to keep track of when and how often a CSS expression is evaluated. Moving the mouse around the page can easily generate more than 10,000 evaluations.

One way to reduce the number of times your CSS expression is evaluated is to use one-time expressions, where the first time the expression is evaluated it sets the style property to an explicit value, which replaces the CSS expression. If the style property must be set dynamically throughout the life of the page, using event handlers instead of CSS expressions is an alternative approach. If you must use CSS expressions, remember that they may be evaluated thousands of times and could affect the performance of your page.

top | discuss this rule

Make JavaScript and CSS External

tag: javascript, css

Many of these performance rules deal with how external components are managed. However, before these considerations arise you should ask a more basic question: Should JavaScript and CSS be contained in external files, or inlined in the page itself?

Using external files in the real world generally produces faster pages because the JavaScript and CSS files are cached by the browser. JavaScript and CSS that are inlined in HTML documents get downloaded every time the HTML document is requested. This reduces the number of HTTP requests that are needed, but increases the size of the HTML document. On the other hand, if the JavaScript and CSS are in external files cached by the browser, the size of the HTML document is reduced without increasing the number of HTTP requests.

したがって、重要な要素は、リクエストされた HTML ドキュメントの数と比較して、外部 JavaScript および CSS コンポーネントがキャッシュされる頻度です。この要因は定量化するのが困難ですが、さまざまな指標を使用して測定できます。サイトのユーザーがセッションごとに複数のページ ビューを持ち、多くのページで同じスクリプトとスタイルシートが再利用されている場合、キャッシュされた外部ファイルからより大きなメリットが得られる可能性があります。

多くの Web サイトは、これらの指標の真ん中に当てはまります。これらのサイトの場合、一般に最善の解決策は、JavaScript と CSS を外部ファイルとして展開することです。インライン化が望ましい唯一の例外は、Yahoo! のフロント ページや My Yahoo! などのホームページです。セッションあたりのページ ビューが少ない (おそらく 1 つだけ) ホームページでは、JavaScript と CSS をインライン化するとエンドユーザーの応答時間が短縮される可能性があります。

通常、多くのページ ビューの最初に表示されるフロント ページの場合、インライン化によってもたらされる HTTP リクエストの削減と、外部ファイルの使用によって得られるキャッシュの利点です。そのような手法の 1 つは、フロント ページに JavaScript と CSS をインライン化しますが、ページの読み込みが完了した後に外部ファイルを動的にダウンロードすることです。後続のページは、ブラウザーのキャッシュに既に存在しているはずの外部ファイルを参照します。

top | このルールについて話し合う

DNS ルックアップを減らす

tag: content

電話帳が人の名前を電話番号にマッピングするのと同じように、ドメイン ネーム システム (DNS) はホスト名を IP アドレスにマッピングします。ブラウザに www.yahoo.com と入力すると、ブラウザが接続した DNS リゾルバーがそのサーバーの IP アドレスを返します。 DNSにはコストがかかります。通常、DNS が特定のホスト名の IP アドレスを検索するのに 20 ～ 120 ミリ秒かかります。 DNS ルックアップが完了するまで、ブラウザはこのホスト名から何もダウンロードできません。

DNS ルックアップはパフォーマンスを向上させるためにキャッシュされます。このキャッシュは、ユーザーの ISP またはローカル エリア ネットワークによって維持される特別なキャッシュ サーバー上で実行できますが、個々のユーザーのコンピュータ上で実行されるキャッシュもあります。 DNS 情報は、オペレーティング システムの DNS キャッシュ (Microsoft Windows の「DNS クライアント サービス」) に残ります。ほとんどのブラウザには、オペレーティング システムのキャッシュとは別に独自のキャッシュがあります。ブラウザが独自のキャッシュに DNS レコードを保持している限り、オペレーティング システムがレコードのリクエストを行う必要はありません。

Internet Explorer は、DnsCacheTimeout レジストリ設定で指定されているように、デフォルトで DNS ルックアップを 30 分間キャッシュします。 Firefox は、network.dnsCacheExpiration 構成設定によって制御され、DNS ルックアップを 1 分間キャッシュします。 (Fasterfox はこれを 1 時間に変更します。)

クライアントの DNS キャッシュが (ブラウザーとオペレーティング システムの両方で) 空の場合、DNS ルックアップの数は Web ページ内の一意のホスト名の数と等しくなります。これには、ページの URL、画像、スクリプト ファイル、スタイルシート、Flash オブジェクトなどで使用されるホスト名が含まれます。一意のホスト名の数を減らすと、DNS ルックアップの数が減ります。

一意のホスト名の数を減らすと、量が削減される可能性があります。ページ内で行われる並行ダウンロード。 DNS ルックアップを回避すると応答時間が短縮されますが、並列ダウンロードを減らすと応答時間が長くなる可能性があります。私のガイドラインは、これらのコンポーネントを少なくとも 2 つ、最大 4 つのホスト名に分割することです。これにより、DNS ルックアップの削減と高度な並列ダウンロードの許可との間で適切な妥協点が得られます。

top | このルールについて議論してください

JavaScript と CSS を縮小する

tag: javascript, css

縮小とは、コードから不要な文字を削除してサイズを削減し、それによって読み込み時間を短縮する手法です。コードが縮小されると、すべてのコメントと不要な空白文字 (スペース、改行、タブ) が削除されます。 JavaScript の場合、ダウンロードされるファイルのサイズが小さくなるため、応答時間のパフォーマンスが向上します。 JavaScript コードを縮小するための 2 つの一般的なツールは、JSMin と YUI Compressor です。 YUI コンプレッサーは CSS を縮小することもできます。

難読化は、ソース コードに適用できる代替最適化です。これは縮小よりも複雑であるため、難読化ステップ自体の結果としてバグが発生する可能性が高くなります。米国の上位 10 の Web サイトの調査では、難読化の場合は 25% であったのに対し、縮小化では 21% のサイズ削減が達成されました。難読化によりサイズは大幅に削減されますが、JavaScript を縮小する方がリスクは低くなります。

外部スクリプトとスタイルの縮小に加えて、インライン化された 3f1c4e4b6b16bbbd69b2ee476dc4f83a cdb437ef872df3303b11b84513957a19 ブロックは縮小できますし、縮小する必要があります。スクリプトとスタイルを gzip 圧縮した場合でも、それらを縮小するとサイズは 5% 以上削減されます。 JavaScript と CSS の使用量とサイズが増加するにつれて、コードを縮小することで得られる節約も増加します。

top | このルールについて話し合います

Avoid Redirects

tag: content

Redirects are accomplished using the 301 and 302 status codes. Here's an example of the HTTP headers in a 301 response:

      HTTP/1.1 301 Moved Permanently      Location: http://example.com/newuri      Content-Type: text/html

The browser automatically takes the user to the URL specified in the Location field. All the information necessary for a redirect is in the headers. The body of the response is typically empty. Despite their names, neither a 301 nor a 302 response is cached in practice unless additional headers, such as Expires or Cache-Control, indicate it should be. The meta refresh tag and JavaScript are other ways to direct users to a different URL, but if you must do a redirect, the preferred technique is to use the standard 3xx HTTP status codes, primarily to ensure the back button works correctly.

The main thing to remember is that redirects slow down the user experience. Inserting a redirect between the user and the HTML document delays everything in the page since nothing in the page can be rendered and no components can start being downloaded until the HTML document has arrived.

One of the most wasteful redirects happens frequently and web developers are generally not aware of it. It occurs when a trailing slash (/) is missing from a URL that should otherwise have one. For example, going to http://astrology.yahoo.com/astrology results in a 301 response containing a redirect tohttp://astrology.yahoo.com/astrology/ (notice the added trailing slash). This is fixed in Apache by using Alias or mod_rewrite, or the DirectorySlash directive if you're using Apache handlers.

Connecting an old web site to a new one is another common use for redirects. Others include connecting different parts of a website and directing the user based on certain conditions (type of browser, type of user account, etc.). Using a redirect to connect two web sites is simple and requires little additional coding. Although using redirects in these situations reduces the complexity for developers, it degrades the user experience. Alternatives for this use of redirects include using Alias and mod_rewrite if the two code paths are hosted on the same server. If a domain name change is the cause of using redirects, an alternative is to create a CNAME (a DNS record that creates an alias pointing from one domain name to another) in combination with Alias or mod_rewrite.

top | discuss this rule

Remove Duplicate Scripts

tag: javascript

It hurts performance to include the same JavaScript file twice in one page. This isn't as unusual as you might think. A review of the ten top U.S. web sites shows that two of them contain a duplicated script. Two main factors increase the odds of a script being duplicated in a single web page: team size and number of scripts. When it does happen, duplicate scripts hurt performance by creating unnecessary HTTP requests and wasted JavaScript execution.

Unnecessary HTTP requests happen in Internet Explorer, but not in Firefox. In Internet Explorer, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page.

In addition to generating wasteful HTTP requests, time is wasted evaluating the script multiple times. This redundant JavaScript execution happens in both Firefox and Internet Explorer, regardless of whether the script is cacheable.

One way to avoid accidentally including the same script twice is to implement a script management module in your templating system. The typical way to include a script is to use the SCRIPT tag in your HTML page.

      <script type="text/javascript" src="menu_1.0.17.js"></script>

An alternative in PHP would be to create a function called insertScript.

      <?php insertScript("menu.js") ?>

In addition to preventing the same script from being inserted multiple times, this function could handle other issues with scripts, such as dependency checking and adding version numbers to script filenames to support far future Expires headers.

top | discuss this rule

Configure ETags

tag: server

Entity tags (ETags) are a mechanism that web servers and browsers use to determine whether the component in the browser's cache matches the one on the origin server. (An "entity" is another word a "component": images, scripts, stylesheets, etc.) ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date. An ETag is a string that uniquely identifies a specific version of a component. The only format constraints are that the string be quoted. The origin server specifies the component's ETag using the ETag response header.

      HTTP/1.1 200 OK      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT      ETag: "10c24bc-4ab-457e1c1f"      Content-Length: 12195

Later, if the browser has to validate a component, it uses the If-None-Match header to pass the ETag back to the origin server. If the ETags match, a 304 status code is returned reducing the response by 12195 bytes for this example.

      GET /i/yahoo.gif HTTP/1.1      Host: us.yimg.com      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT      If-None-Match: "10c24bc-4ab-457e1c1f"      HTTP/1.1 304 Not Modified

The problem with ETags is that they typically are constructed using attributes that make them unique to a specific server hosting a site. ETags won't match when a browser gets the original component from one server and later tries to validate that component on a different server, a situation that is all too common on Web sites that use a cluster of servers to handle requests. By default, both Apache and IIS embed data in the ETag that dramatically reduces the odds of the validity test succeeding on web sites with multiple servers.

The ETag format for Apache 1.3 and 2.x is inode-size-timestamp. Although a given file may reside in the same directory across multiple servers, and have the same file size, permissions, timestamp, etc., its inode is different from one server to the next.

IIS 5.0 and 6.0 have a similar issue with ETags. The format for ETags on IIS is Filetimestamp:ChangeNumber. A ChangeNumber is a counter used to track configuration changes to IIS. It's unlikely that the ChangeNumber is the same across all IIS servers behind a web site.

The end result is ETags generated by Apache and IIS for the exact same component won't match from one server to another. If the ETags don't match, the user doesn't receive the small, fast 304 response that ETags were designed for; instead, they'll get a normal 200 response along with all the data for the component. If you host your web site on just one server, this isn't a problem. But if you have multiple servers hosting your web site, and you're using Apache or IIS with the default ETag configuration, your users are getting slower pages, your servers have a higher load, you're consuming greater bandwidth, and proxies aren't caching your content efficiently. Even if your components have a far future Expires header, a conditional GET request is still made whenever the user hits Reload or Refresh.

If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether. The Last-Modified header validates based on the component's timestamp. And removing the ETag reduces the size of the HTTP headers in both the response and subsequent requests. This Microsoft Support article describes how to remove ETags. In Apache, this is done by simply adding the following line to your Apache configuration file:

      FileETag none

top | discuss this rule

Make Ajax Cacheable

tag: content

One of the cited benefits of Ajax is that it provides instantaneous feedback to the user because it requests information asynchronously from the backend web server. However, using Ajax is no guarantee that the user won't be twiddling his thumbs waiting for those asynchronous JavaScript and XML responses to return. In many applications, whether or not the user is kept waiting depends on how Ajax is used. For example, in a web-based email client the user will be kept waiting for the results of an Ajax request to find all the email messages that match their search criteria. It's important to remember that "asynchronous" does not imply "instantaneous".

To improve performance, it's important to optimize these Ajax responses. The most important way to improve the performance of Ajax is to make the responses cacheable, as discussed in Add an Expires or a Cache-Control Header. Some of the other rules also apply to Ajax:

Gzip Components Reduce DNS Lookups Minify JavaScript Avoid Redirects Configure ETags

 

Let's look at an example. A Web 2.0 email client might use Ajax to download the user's address book for autocompletion. If the user hasn't modified her address book since the last time she used the email web app, the previous address book response could be read from cache if that Ajax response was made cacheable with a future Expires or Cache-Control header. The browser must be informed when to use a previously cached address book response versus requesting a new one. This could be done by adding a timestamp to the address book Ajax URL indicating the last time the user modified her address book, for example,&t=1190241612. If the address book hasn't been modified since the last download, the timestamp will be the same and the address book will be read from the browser's cache eliminating an extra HTTP roundtrip. If the user has modified her address book, the timestamp ensures the new URL doesn't match the cached response, and the browser will request the updated address book entries.

Even though your Ajax responses are created dynamically, and might only be applicable to a single user, they can still be cached. Doing so will make your Web 2.0 apps faster.

top | discuss this rule

Flush the Buffer Early

tag: server

When users request a page, it can take anywhere from 200 to 500ms for the backend server to stitch together the HTML page. During this time, the browser is idle as it waits for the data to arrive. In PHP you have the function flush(). It allows you to send your partially ready HTML response to the browser so that the browser can start fetching components while your backend is busy with the rest of the HTML page. The benefit is mainly seen on busy backends or light frontends.

A good place to consider flushing is right after the HEAD because the HTML for the head is usually easier to produce and it allows you to include any CSS and JavaScript files for the browser to start fetching in parallel while the backend is still processing.

Example:

      ... <!-- css, js -->    </head>    <?php flush(); ?>    <body>      ... <!-- content -->

Yahoo! search pioneered research and real user testing to prove the benefits of using this technique.

top

Use GET for AJAX Requests

tag: server

The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.

An interesting side affect is that POST without actually posting any data behaves like GET. Based on the HTTP specs, GET is meant for retrieving information, so it makes sense (semantically) to use GET when you're only requesting data, as opposed to sending data to be stored server-side.

 

top

Post-load Components

tag: content

You can take a closer look at your page and ask yourself: "What's absolutely required in order to render the page initially?". The rest of the content and components can wait.

JavaScript is an ideal candidate for splitting before and after the onload event. For example if you have JavaScript code and libraries that do drag and drop and animations, those can wait, because dragging elements on the page comes after the initial rendering. Other places to look for candidates for post-loading include hidden content (content that appears after a user action) and images below the fold.

Tools to help you out in your effort: YUI Image Loader allows you to delay images below the fold and the YUI Get utility is an easy way to include JS and CSS on the fly. For an example in the wild take a look at Yahoo! Home Page with Firebug's Net Panel turned on.

It's good when the performance goals are inline with other web development best practices. In this case, the idea of progressive enhancement tells us that JavaScript, when supported, can improve the user experience but you have to make sure the page works even without JavaScript. So after you've made sure the page works fine, you can enhance it with some post-loaded scripts that give you more bells and whistles such as drag and drop and animations.

top

Preload Components

tag: content

Preload may look like the opposite of post-load, but it actually has a different goal. By preloading components you can take advantage of the time the browser is idle and request components (like images, styles and scripts) you'll need in the future. This way when the user visits the next page, you could have most of the components already in the cache and your page will load much faster for the user.

There are actually several types of preloading:

無条件プリロード - onload が起動するとすぐに、追加のコンポーネントを取得します。ロード時にスプライト画像がどのようにリクエストされるかの例については、google.com を確認してください。このスプライト画像は google.com のホームページでは必要ありませんが、連続検索結果ページでは必要です。条件付きプリロード - ユーザーのアクションに基づいて、ユーザーが次にどこに向かっているのかを経験に基づいた推測を行い、それに応じてプリロードします。 search.yahoo.com では、入力ボックスに入力を開始した後に追加のコンポーネントがどのように要求されるかを確認できます。予想されるプリロード - 再設計を開始する前に事前にプリロードします。再デザイン後に「新しいサイトはすばらしいが、以前より遅い」という声がよく聞かれます。問題の一部は、ユーザーがキャッシュがいっぱいの状態で古いサイトにアクセスしていたのに、新しいサイトでは常にキャッシュが空であることが考えられます。再設計を開始する前にいくつかのコンポーネントをプリロードすることで、この副作用を軽減できます。古いサイトは、ブラウザーがアイドル状態の時間を利用して、新しいサイトで使用される画像とスクリプトをリクエストできます

top

DOM 要素の数を減らす

tag: content

複雑なページはダウンロードするバイト数が多くなり、また、これは、JavaScript での DOM アクセスが遅くなることを意味します。たとえば、イベント ハンドラーを追加する場合に、ページ上の 500 個または 5000 個の DOM 要素をループするかどうかで違いが生じます。

DOM 要素の数が多い場合は、次のマークアップで改善すべき点があることを示している可能性があります。必ずしもコンテンツを削除せずにページを削除します。レイアウト目的でネストされたテーブルを使用していますか?レイアウトの問題を解決するためだけに dc6dce4a544fdca2df29d5ac0ea9906b をさらに追加していますか?おそらく、マークアップを行うための、より適切で意味的に正しい方法があるかもしれません。

レイアウトに関する大きな助けとなるのは、YUI CSS ユーティリティです。grids.css は全体的なレイアウトに役立ち、fonts.css とreset.css は削除に役立ちます。ブラウザのデフォルトの書式設定。これは、新たにスタートしてマークアップについて考えるチャンスです。たとえば、dc6dce4a544fdca2df29d5ac0ea9906bs は、新しい行をレンダリングするためではなく、意味的に意味がある場合にのみ使用します。

DOM 要素の数はテストするのが簡単です。 Firebug のコンソールに次のように入力します:
document.getElementsByTagName('*').length

多すぎる DOM 要素はいくつあるでしょうか?適切なマークアップを持つ他の同様のページを確認してください。たとえば、Yahoo!ホームページはかなり忙しいページであり、要素 (HTML タグ) はまだ 700 未満です。

top

コンポーネントをドメイン間で分割する

tag: content

コンポーネントを分割すると、並列ダウンロードを最大化できます。 DNS ルックアップ ペナルティのため、使用するドメインの数が 2 ～ 4 個以下であることを確認してください。たとえば、HTML と動的コンテンツを www.example.org でホストし、静的コンポーネントを static1.example.org とstatic2.example.org に分割することができます

詳細については、Tenni Theurer の「Maximizing Parallel Downloads in the Carpool Lane」を参照してください。

top

iframe の数を最小限に抑える

tag: content

iframe を使用すると、HTML ドキュメントを親ドキュメントに挿入できます。 iframe を効果的に使用するには、iframe の仕組みを理解することが重要です。

d5ba1642137c3f32f4f4493ae923989c 長所:

バッジや広告などの遅いサードパーティコンテンツをサポート セキュリティサンドボックス スクリプトを並行してダウンロード

d5ba1642137c3f32f4f4493ae923989c 短所:

空白の場合でもコストがかかる ページのロードをブロックする 非セマンティック

top

404 は使用しない

tag: content

HTTP リクエストはコストがかかるため、HTTP リクエストを作成して役に立たない応答 (つまり 404 Not Found) を取得することはまったく不要であり、速度が遅くなります何のメリットもなく、ユーザー エクスペリエンスを低下させます。

一部のサイトには、便利な 404「X のことですか?」があり、これはユーザー エクスペリエンスには優れていますが、サーバー リソース (データベースなど) を浪費します。特に問題となるのは、外部 JavaScript へのリンクが間違っており、結果が 404 になる場合です。まず、このダウンロードは並列ダウンロードをブロックします。次に、ブラウザは 404 応答本文を JavaScript コードであるかのように解析し、その中で使用可能なものを見つけようとします。

top

Cookie サイズの削減

tag: cookie

HTTP Cookie は、次のようなさまざまな理由で使用されます。認証とパーソナライゼーション。 Cookie に関する情報は、Web サーバーとブラウザーの間で HTTP ヘッダーで交換されます。ユーザーの応答時間への影響を最小限に抑えるために、Cookie のサイズをできるだけ低く保つことが重要です。

詳細については、Tenni Theurer と Patty Chi の「When the Cookie Crumbles」を確認してください。この研究の成果:

不要な Cookie を削除します。 ユーザーの応答時間への影響を最小限に抑えるために、Cookie サイズをできるだけ小さくします。 他のサブドメインが影響を受けないように、適切なドメイン レベルで Cookie を設定するように注意してください。 有効期限日を適切に設定します。有効期限を早めるか、期限を設定しないと、Cookie がより早く削除され、ユーザーの応答時間が向上します

top

コンポーネントに Cookie のないドメインを使用する

tag: cookie

ブラウザが静的画像のリクエストを作成し、リクエストと一緒に Cookie を送信するとき、サーバーはこれらの Cookie を使用しません。したがって、正当な理由もなくネットワーク トラフィックが発生するだけです。静的コンポーネントが Cookie なしのリクエストでリクエストされていることを確認する必要があります。サブドメインを作成し、すべての静的コンポーネントをそこでホストします。

ドメインが www.example.org の場合、静的コンポーネントを static.example.org でホストできます。ただし、www.example.org ではなくトップレベル ドメイン example.org にすでに Cookie を設定している場合、static.example.org へのすべてのリクエストにはそれらの Cookie が含まれます。この場合、まったく新しいドメインを購入し、そこで静的コンポーネントをホストし、このドメインを Cookie なしで保つことができます。ヤフー！ yimg.com を使用し、YouTube は ytimg.com を使用し、Amazon は images-amazon.com などを使用します。

Cookie のないドメインで静的コンポーネントをホストするもう 1 つの利点は、一部のプロキシが、リクエストされたコンポーネントのキャッシュを拒否する可能性があることです。クッキー。これに関連して、ホームページに example.org と www.example.org のどちらを使用するべきか迷っている場合は、Cookie への影響を考慮してください。 www を省略すると、*.example.org に Cookie を書き込む以外に選択肢がないため、パフォーマンス上の理由から、www サブドメインを使用し、そのサブドメインに Cookie を書き込むことが最善です。

top

DOM アクセスを最小限に抑える

tag: javascript

Accessing JavaScript を使用した DOM 要素は遅いため、ページの応答性を高めるには、次のことを行う必要があります。

アクセスされた要素への参照をキャッシュする ノードを「オフライン」で更新してからツリーに追加する JavaScript でレイアウトを修正するのを避ける

詳細については、YUI シアターの Web サイトを確認してください。 Julien Lecomte 著「高性能 Ajax アプリケーション」

トップ

スマート イベント ハンドラーの開発

tag: javascript

DOM ツリーのさまざまな要素に関連付けられたイベント ハンドラーが多すぎて、頻繁に実行されるため、ページの応答性が低下することがあります。そのため、イベント委任を使用することが良いアプローチとなります。 div 内に 10 個のボタンがある場合は、ボタンごとに 1 つのハンドラーではなく、イベント ハンドラーを 1 つだけ div ラッパーにアタッチします。イベントがバブルアップするので、イベントをキャッチして、そのイベントがどのボタンから発生したかを把握できるようになります。

また、DOM ツリーで何かを開始するために onload イベントを待つ必要もありません。多くの場合、必要なのは、ツリー内で使用できるようにアクセスしたい要素だけです。すべての画像がダウンロードされるまで待つ必要はありません。 DOMContentLoaded は、onload の代わりに使用することを検討できるイベントですが、すべてのブラウザで利用できるようになるまでは、onAvailable メソッドを持つ YUI イベント ユーティリティを使用できます。

詳細については、YUI シアターの「高性能 Ajax アプリケーション」を確認してください。ジュリアン・ルコント。

トップ

2cdf5bf648cf2f33323966d7f58a7f3f を選択してください。 over @import

tag: css

以前のベスト プラクティスの 1 つは、プログレッシブ レンダリングを可能にするために CSS を先頭に置く必要があると述べています。

IE では、@import は 2cdf5bf648cf2f33323966d7f58a7f3f を使用するのと同じように動作します。 ページの下部にあるため、使用しないことをお勧めします。

top

フィルターを避ける

tag: css

IE 独自の AlphaImageLoader フィルターは、IE バージョン