今日は「高パフォーマンス Web サイト」を簡単に閲覧しました。この本の中国語版は「高パフォーマンス Web サイト構築ガイド」です。
この本には、個別の問題を深く掘り下げる上級章「さらに高速な Web サイト」もあり、中国語訳は「Advanced Guide to Building High-Performance Websites」です。
上記の Douban リンクで作者が紹介しているので、ここではコピーしません。
この本では、Web サイトのパフォーマンスを向上させるための 14 の原則が説明されており、各原則は例を含む独立した章になっています。これらの原則のほとんどは非常に実践的で、サイト アーキテクトやフロントエンド エンジニアに適しています。これはフロントエンドエンジニアにとってより重要です。
今回はオリジナル版を見てみました。私はウェブ開発の実務経験が浅く、急いで読んだため、省略や不適切な表現があるかもしれません。ネット民の皆様は遠慮なく修正していただければ幸いです。
原則 1 HTTP リクエストの数を減らす
リクエストの作成と応答の待機には時間がかかるため、リクエストの数は少ないほど良いです。リクエストを減らすという一般的な考え方は、リソースをマージし、ページを表示するために必要なファイルの数を減らすことです。
1. イメージマップ
<img> タグの usemap 属性を設定し、<map> タグを使用すると、画像を複数の領域に分割し、異なるリンクを指すことができます。複数の画像を使用して個別にリンクを構築する場合と比較して、リクエストの数が削減されます。
2. CSS SPRite (CSS テクスチャ統合/テクスチャ ステッチング/テクスチャ配置)
これは、要素の背景位置スタイルを設定することによって行われます。通常、インターフェースのアイコンに使用されます。一般的なものは、TinyMCE エディターの上にある小さなボタンを指します。複数の小さな画像は、基本的に、異なるオフセットを使用して統合された大きな画像から切り取られます。このようにして、読み込みインターフェイス上の多くのボタンは、実際には 1 回リクエストするだけで済みます (大きな画像を 1 回リクエストする) ので、HTTP リクエストの数が削減されます。
3. インライン画像
<img>のsrcには外部画像ファイルのURLを指定せず、画像情報を直接記述します。たとえば、src="data:image/gif;base64,R0lGODlhDAAMAL..." は、いくつかの特殊な場合に役立ちます (たとえば、小さな画像が現在のページでのみ使用される)。
原則 2: 複数行 CDN を利用する
すべてのユーザーがサイトにすばやくアクセスできるように、サイトに複数の回線 (国内通信、チャイナユニコム、チャイナモバイルなど) と複数の地理的位置 (北、南、西) へのアクセスを提供します。
原則 3: HTTP キャッシュを使用する
頻繁に更新されないリソース (静的画像など) には、より長い Expires ヘッダー情報を追加します。これらのリソースは、一度キャッシュされると、今後長期間再送信されなくなります。
原則 4: Gzip 圧縮を使用する
Gzip を使用して HTTP メッセージを圧縮し、サイズと送信時間を削減します。
原則 5: スタイルシートをページの先頭に配置する
最初にスタイル シートをロードすると、ページのレンダリングがより早く開始され、ユーザーにページの読み込みが速くなったように感じられます。
原則 6: スクリプトをページの最後に配置する
理由は 5 と同じです。ページの表示が先に処理され、ページのレンダリングが早く完了し、スクリプト ロジックが後で実行されるため、ユーザーはページの読み込みが速くなったように感じます。
原則 7 CSS 式の使用を避ける
過度に複雑な JavaScript スクリプト ロジック、DOM 検索、および選択操作により、ページ処理の効率が低下します。
原則 8 JavaScript と CSS を外部リソースとして使用する
これは、原則 1 のマージのアイデアに反しているように見えますが、そうではありません。1 ページ単独のパフォーマンスから判断すると、各ページがパブリック JavaScript リソース (jQuery や ExtJS などの JavaScript ライブラリ) を導入していることを考慮すると、インライン(つまり、HTML に JavaScript を埋め込む) ページは、(<script> タグを使用して導入される) アウトバウンド ページよりも (HTTP リクエストの数が少ないため) 高速に読み込まれます。しかし、多くのページでこのパブリック JavaScript リソースが導入されている場合、インライン スキームにより繰り返し送信が発生します (このリソースは各ページに埋め込まれているため、ページが開かれるたびにリソースのこの部分を送信する必要があり、ネットワーク送信の無駄が発生します)リソース）。この問題は、このリソースを独立させて外部参照することで解決できます。
JavaScript と CSS は比較的安定しているため、対応するリソースの有効期限を長く設定できます (原則 3 を参照)。
原則 9 DNS ルックアップを減らす
著者のアドバイスは次のとおりです。
1.キープアライブを使用して接続を維持する
接続が切断された場合、対応するドメイン名と IP のマッピングがキャッシュされている場合でも、次回接続するときに DNS ルックアップを実行する必要があります。
2. ドメイン名を減らす
新しいドメイン名を要求するたびに、DNS を通じて別のドメイン名を検索する必要があり、DNS キャッシュは機能しません。したがって、統一されたドメイン名でサイトを編成し、あまりにも多くのサブドメイン名を使用しないように最善を尽くす必要があります。
原則 10 JavaScript を縮小する
JS 圧縮ツールを使用して JavaScript を圧縮すると、非常に効果的です。 jQuery の 2 つの異なるディストリビューションを見て、違いを確認してください。
http://code.jquery.com/jquery-1.6.2.js読み取りバージョン jQuery コード、230KB
http://code.jquery.com/jquery-1.6.2.min.js jQuery コードの圧縮バージョン (実際のデプロイメント用)、89.4KB
原則 11 リダイレクトを避けるように努める
リダイレクトとは、表示したいページに実際にアクセスする前に、追加の HTTP リクエストが追加されることを意味します (クライアントが HTTP リクエストを開始する → HTTP サーバーがリダイレクト応答を返す → クライアントが新しい URL のリクエストを開始する → HTTPサーバーはコンテンツを返します。下線部分は追加のリクエストです）そのため、より多くの時間がかかります（これにより、応答が遅く感じることもあります）。したがって、必要な場合以外はリダイレクトを使用しないでください。いくつかの「必要な」状況:
1. 無効な URL を避ける
古いサイトの移行後、古い URL が無効になるのを防ぐために、通常、古い URL に対するリクエストは新しいシステムの対応するアドレスにリダイレクトされます。
2. URLの美化
読み取り可能な URL と実際のリソース URL の間で変換します。たとえば、Google ツールバーの場合、ユーザーは人間にとって意味的なアドレスであるhttp://toolbar.google.com を覚えています。 .com/tools/Firefox/toolbar/FT3/intl/en/index.htmlは実際のリソース アドレスです。したがって、前者を保持し、前者に対するリクエストを後者にリダイレクトする必要があります。
原則 12 重複したスクリプトを削除する
同じスクリプトをページに繰り返し含めないでください。たとえば、スクリプト B と C は両方とも A に依存しているため、B と C を使用するページで A が繰り返し参照される可能性があります。解決策は、単純なサイトの依存関係を手動でチェックし、繰り返しの導入を排除することです。複雑なサイトの場合は、独自の依存関係管理/バージョン管理メカニズムを構築する必要があります。
原則 13 ETag は慎重に扱う
ETag は、Last-Modified 以外の HTTP キャッシュ メソッドです。リソースがハッシュによって変更されたかどうかを識別します。ただし、ETag には次のようないくつかの問題があります。
1. 不一致: 異なる Web サーバー (Apache、IIS など) が異なる ETag 形式を定義します。
2. ETag の計算は、次のように不安定です (考慮する要素が多すぎるため)。
1) 同じリソースには、異なるサーバー上で異なる ETag が計算されており、大規模な Web アプリケーションは通常、複数のサーバーによって提供されます。これにより、サーバー A 上のクライアントのキャッシュされたリソースは引き続き有効になりますが、次回サーバー B をリクエストするときは、 ETag が異なる場合は無効とみなされ、同じリソースが繰り返し送信されることになります。
2) リソースは変更されませんが、構成ファイルの変更など、他の要因の変更により ETag が変更されます。その直接的な影響として、システム更新後にクライアント キャッシュ障害が大規模に発生し、その結果、送信量が大幅に増加し、サイトのパフォーマンスが低下します。
著者の提案は、アプリケーションの特性に応じて既存の ETag 計算方法を改善するか、単に ETag を使用せずに最も単純な Last-Modified を使用するかのどちらかです。
原則 14 Ajax で HTTP キャッシュを活用する
Ajax は非同期リクエストです。非同期リクエストは現在の操作をブロックせず、リクエストが完了するとすぐに結果を確認できます。ただし、非同期とは、即座に完了できるという意味ではなく、また、完了するまでに無限の時間がかかることを許容できるという意味でもありません。したがって、Ajax リクエストのパフォーマンスにも注意を払う必要があります。比較的安定したリソースにアクセスする Ajax リクエストが多数あるため、Ajax リクエストに対して HTTP キャッシュ メカニズムを有効に活用することを忘れないでください。詳細については、原則 3 と 13 を参照してください。
著者: 楊夢東
記事の出典：楊夢東ブログ 転載の際は出典リンクを明記してください。