ページスピードの最適化の概要

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

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

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

1. HTTPリクエストの数を可能な限り減らす[コンテンツ]
2. CDN（コンテンツ配信ネットワーク）を使用する[サーバー]
3. Expires ヘッダー（または Cache-control ）を追加する [server]
4. Gzipコンポーネント[サーバー]
5. CSSスタイルをページ上部に配置する[css]
6. スクリプトを一番下へ移動する（インラインスクリプトも含む）[javascript]
7. CSS で式の使用を避ける [css]
8. JavaScriptとCSSを外部ファイルに分離する [javascript] [css]
9. DNSクエリを減らす[コンテンツ]
10. JavaScript と CSS（インラインも含む）を圧縮する [javascript] [css]
11. リダイレクトを避ける [サーバー]
12. 重複したスクリプトを削除する [javascript]
13. エンティティタグ（ETags）を構成する [css]
14. AJAXキャッシュを有効にする

Firefox には yslow というプラグインがあり、Firebug に統合されています。これを使用すると、Web サイトのパフォーマンスをこれらの側面から簡単に確認できます。

これは、yslow を使用して私のウェブサイト Xifengfang を評価した結果です。残念ながら、スコアは 51 ポイントしかありませんでした。へへ。中国の大手ウェブサイトのスコアは高くありません。先ほどテストしたところ、Sina と NetEase はどちらも 31 ポイントでした。するとYahoo（米国）のスコアは実に97点です！これは、Yahoo がこの件に関して行ってきた努力を示しています。彼らがまとめた 14 のルールと追加された 20 の新しいポイントから判断すると、私たちが決して考えもしなかったような細かい点が多くあり、一部の慣行は少し「異常」ですらあります。

まず、HTTPリクエストをできるだけ少なくする

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

CSS スプライトとは、ページ上の背景画像を 1 つに結合し、CSS の background-position プロパティで定義された値を使用して背景を取得することを意味します。現在、Taobao と Alibaba の中国サイトではこれが行われています。ご興味がございましたら、Taobao と Alibaba の背景画像をご覧ください。

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

第2条: コンテンツ配信ネットワークの使用

正直、CDN についてはあまり詳しくありません。簡単に言うと、既存のインターネットに新しいネットワーク アーキテクチャを追加することで、Web サイトのコンテンツがユーザーに最も近いキャッシュ サーバーに公開されます。DNS ロード バランシング技術により、ユーザーのソースが判別され、最も近いキャッシュ サーバーにアクセスして必要なコンテンツが取得されます。杭州のユーザーは杭州付近のサーバーのコンテンツにアクセスし、北京のユーザーは北京付近のサーバーのコンテンツにアクセスします。これにより、ネットワーク経由でデータが送信される時間が効果的に短縮され、速度が向上します。詳しい情報については、Baidu百科事典のCDNの説明を参照してください。 Yahoo! は静的コンテンツを CDN に配信し、ユーザーへの影響時間を 20% 以上短縮します。

CDN テクノロジー図:

CDN ネットワーク図:

第3条 Expiresヘッダーを追加する

現在、Web ページには、ますます多くの画像、スクリプト、CSS、Flash が埋め込まれています。これらにアクセスすると、必然的に多くの http リクエストが行われます。実際、Expires ヘッダーを設定することでこれらのファイルをキャッシュできます。 Expire は、実際にはヘッダー メッセージを通じてブラウザー内の特定の種類のファイルのキャッシュ時間を指定します。ほとんどの画像やフラッシュは、公開後に頻繁に変更する必要はありません。キャッシュすると、ブラウザはこれらのファイルをサーバーからダウンロードする必要がなくなり、キャッシュから直接読み取ることができるため、ページに再度アクセスする速度が大幅に向上します。一般的な HTTP 1.1 プロトコルは次のヘッダー情報を返します。
HTTP/1.1 200 OK
日付: 1998 年 10 月 30 日金曜日 13:19:41 GMT
サーバー: Apache/1.3.3 (Unix)
キャッシュ制御: max-age=3600、再検証が必要
有効期限: 1998 年 10 月 30 日金曜日 14:19:41 GMT
最終更新日: 1998年6月29日月曜日 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
コンテンツの長さ: 1040
コンテンツタイプ: text/html

これは、サーバー側スクリプトを通じて Cache-Control と Expires を設定することによって実行できます。

たとえば、PHP で 30 日後に有効期限が切れるように設定します。

<!--pHeader("Cache-Control: must-revalidate");$offset = 60 * 60 * 24 * 30;$ExpStr = "Expires: " . gmdate("D, d MYH:i:s", time() + $offset) . " GMT";Header($ExpStr);-->サーバー自体を構成することによっても実行できます。私はこれらのことについてあまりよく分かりません、ハハ。さらに詳しく知りたい場合は、http://www.web-caching.com/ を参照してください。

私の知る限り、Alibaba の中国サイトの現在の有効期限は 30 日です。ただし、この期間中にいくつかの問題がありました。特に、スクリプトの有効期限の設定は慎重に検討する必要があり、そうしないと、対応するスクリプト機能が更新された後、クライアントがそのような変更を「認識」するのに長い時間がかかる可能性があります。以前、[プロジェクトを提案] していたときにこの問題に遭遇しました。したがって、何をキャッシュし、何をキャッシュしないかを慎重に検討する必要があります。

4. Gzip圧縮を有効にする: Gzipコンポーネント

Gzip の考え方は、ファイルを送信する前にサーバー側でファイルを圧縮することです。これにより、ファイル転送のサイズが大幅に削減されます。送信が完了すると、ブラウザは圧縮されたコンテンツを再度解凍して実行します。現在のブラウザのほとんどは gzip を「適切に」サポートしています。ブラウザだけでなく、主要な「クローラー」も認識できるので、SEO 担当者も安心です。さらに、gzip の圧縮率は非常に高く、通常は約 85% です。つまり、サーバー側の 100K ページは、クライアントに送信する前に約 25K に圧縮できます。具体的な Gzip 圧縮の原理については、csdn の記事「Gzip 圧縮アルゴリズム」を参照してください。 Yahoo は、すべてのテキスト コンテンツ (html (php)、js、css、xml、txt など) を gzip で圧縮する必要があることを特に強調しています。当社の Web サイトはこの点で優れた成果を上げており、A を獲得しています。以前、当社のホームページは A ではありませんでした。ホームページには広告コードによって配置された js が多数あったためです。これらの広告コードの所有者の Web サイトの js は gzip で圧縮されておらず、これも当社の Web サイトのパフォーマンスを低下させる原因となっていました。

上記 3 点は主にサーバー側の内容であり、私はそれらについて表面的な理解しか持っていません。私が犯した間違いがあれば指摘していただければ幸いです。

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

なぜ CSS をページの上部に配置するのでしょうか? IE や Firefox などのブラウザは、すべての CSS が完全に送信されるまで何もレンダリングしないためです。理由は、Xiao Ma が言った通り、単純です。 css の正式名称は Cascading Style Sheets です。カスケードとは、後の CSS が前の CSS をカバーし、上位レベルの CSS が下位レベルの CSS をカバーできることを意味します。 [css! ] でこの階層関係については、この記事の下部で簡単に説明しました。ここでは、CSS が上書きできることだけを知っておく必要があります。前のスタイルシートは上書きされる可能性があるため、ブラウザが完全に読み込まれた後にレンダリングするのは間違いなく合理的です。IE などの多くのブラウザでは、スタイルシートをページの下部に配置すると、Web ページ コンテンツの連続表示が禁止されるという問題があります。ブラウザはページ要素の再描画を避けるために表示をブロックするため、ユーザーには空白のページしか表示されません。 Firefox では表示がブロックされませんが、スタイルシートのダウンロード中に一部のページ要素を再描画する必要がある場合があり、ちらつきの問題が発生する可能性があります。だからできるだけ早くCSSを読み込む必要があります

この意味に従って、さらに注意深く見てみると、実際に最適化できる領域が存在します。たとえば、このサイトに含まれる 2 つの CSS ファイルは、<link rel="stylesheet" rev="stylesheet" href="http://www.space007.com/themes/google/style/google.css" type="text/css" media="screen" /> と <link rel="stylesheet" rev="stylesheet" href="http://www.space007.com/css/print.css" type="text/css" media="print" /> です。メディアから、最初の CSS はブラウザ用であり、2 番目の CSS ファイルは印刷スタイル用であることがわかります。ユーザーの行動習慣からすると、ページを印刷するアクションはページが表示された後に実行する必要があります。したがって、より良いアプローチとしては、ページが読み込まれた後にこのページに印刷デバイス用の CSS を動的に追加し、速度を少し向上させることです。 （ハハハ）

第6条 スクリプトを一番下に置く

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

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

第7条 CSSで式の使用を避ける

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

8. JavaScriptとCSSを外部化する

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

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

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

10. JavaScriptを縮小する

js と css を圧縮するとページのバイト数が削減されるという利点は明らかです。容量が小さいほど、ページの読み込みが速くなります。圧縮は、音量の削減に加えて、ある程度の保護も提供します。この点に関しては我々は良い仕事をしてきました。よく使われる圧縮ツールには、JsMin、YUI コンプレッサーなどがあります。さらに、http://dean.edwards.name/packer/ は非常に便利なオンライン圧縮ツールも提供しています。圧縮された js ファイルと圧縮されていない js ファイルのサイズの違いは、jQuery の Web ページで確認できます。

もちろん、圧縮の欠点の 1 つは、コードの可読性が失われることです。フロントエンドで作業している多くの友人がこの問題に遭遇したことがあると思います。Google で見るとエフェクトがとてもクールですが、ソースコードを見ると文字が密集していて、関数名さえ置き換えられています。とても怖いです!こうなると、自分のコードをメンテナンスするのは非常に不便ではないでしょうか?現在、すべての Alibaba の中国サイトで採用されている方法は、公開時にサーバー側で js と css を圧縮することです。これにより、独自のコードを保守することが非常に便利になります。

第11条 リダイレクトを避ける

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

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

パフォーマンスの観点だけでなく、コード標準の観点からも、これは言わなくてもご存知だと思います。しかし、一時的なニーズを満たすためだけに、重複する可能性のあるコードを追加してしまうことが多々あることを認めなければなりません。おそらく、CSS フレームワークと JS フレームワークを統合すれば、問題をよりうまく解決できるでしょう。 Xiaozhu さんの見解は非常に正しいです。重複を避けるだけでなく、再利用可能にすることも重要です。

第13条 ETagsの設定

これも分かりません、ハハハ。 inforQ で「ETags を使用して Web アプリケーションの帯域幅と負荷を削減する」という比較的詳細な説明を見つけました。興味のある学生はご覧ください。

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

Ajax をキャッシュする必要がありますか? Ajax リクエストを行うときは、キャッシュを回避するためにタイムスタンプを追加することが必要になることがよくあります。 「非同期」は「即時」を意味するわけではないことに留意することが重要です。 AJAX が動的に生成され、1 人のユーザーに対してのみ機能する場合でも、キャッシュされる可能性があることに留意してください。