HTML のパフォーマンスに関する一般的な考慮事項

読み込みの速いウェブサイトを構築するための最初のステップは、 ページの HTML に対するサーバーからのレスポンスです。[ リクエストが送信されると、ブラウザはサーバーに GET リクエストを送信し、 取得できます。ウェブページに対する最初のリクエストは、HTML リソースに対するもので、 HTML を最小限の遅延ですばやく受信できるようにすることが、重要なパフォーマンス なります。

最初の HTML リクエストはいくつかのステップを経て、 説明します。各ステップの時間を短縮することで、 First Byte（TTFB）。TTFB は唯一の指標ではありませんが ページの読み込み速度に関して言えば、TTFB が高くなると、リーチが難しくなります 「商品」として指定されたLargest Contentful Paint などの指標のしきい値を （LCP）と First Contentful Paint（FCP）です。

<ph type="x-smartling-placeholder">

リダイレクトの回数を減らす

リソースがリクエストされると、サーバーはリダイレクトまたは 永続的なリダイレクト（301 Moved Permanently レスポンス）または一時的な 1（302 Found レスポンス）を返します。

リダイレクトすると、ブラウザが次の処理を行う必要があるため、ページの読み込み速度が遅くなります。 新しい場所で追加の HTTP リクエストを行い、リソースを取得します。他にも リダイレクトには 2 種類があります

  1. 配信元内ですべて発生する同一オリジン リダイレクト。これらの型 リダイレクトは完全に制御下にあります。これは、リダイレクトを 完全にウェブサーバー上にあります。
  2. 別のオリジンによって開始されたクロスオリジン リダイレクト。この種の リダイレクトは通常制御できません

クロスオリジン リダイレクトは、広告や URL 短縮サービスなど、 サードパーティサービスも提供していますクロスオリジン リダイレクトは制御できませんが、 複数のリダイレクト（例: HTTP ページにリンクして HTTPS にリダイレクトされる広告 クロスオリジン リダイレクトと同等ですが、 同じオリジンのリダイレクトがトリガーされます。

<ph type="x-smartling-placeholder">

HTML レスポンスをキャッシュに保存する

HTML レスポンスをキャッシュに保存するのは困難です。レスポンスには、 その他の重要なリソース（CSS、JavaScript、画像、その他リソース） できます。これらのリソースには、それぞれのファイルに一意のフィンガープリントが含まれる場合があります。 （ファイルの内容に応じて変更されます）。つまり、キャッシュされた HTML ドキュメントは、デプロイ後に最新でなくなる可能性があります。 古いサブリソースへの参照です。

それでも、キャッシュしないのではなく、キャッシュの有効期間が短いほうがメリットがある場合があります。 たとえば、CDN でリソースをキャッシュできるようにするなど、 ブラウザで送信されたリクエストに対してリクエストを受信し、 再度ダウンロードするのではなく、再検証する必要があります。このアプローチが効果的 どのようなコンテキストでも変化しない静的なコンテンツに適しており、 リソースをキャッシュに保存するまでの時間を分単位で設定できます。 あります。静的 HTML リソースに 5 分かかるのは間違いなしであり、 定期的な更新を見逃すことがなくなります。

ページの HTML コンテンツが、なんらかの方法でパーソナライズされている場合（ ユーザーとして認証されているため、たいていの場合、そのコンテンツのためにコンテンツを セキュリティを含め、さまざまな懸念が 鮮度ですHTML レスポンスが キャッシュを無効にすることはできません。です。 そのため、このような場合には HTML のキャッシュ保存を完全に避けることをおすすめします。

HTML をキャッシュするには、ETag または Last-Modified レスポンス ヘッダー。ETag（エンティティとも呼ばれます） tag - header はリクエストされたリソースを一意に表す識別子。 多くの場合は、リソースのコンテンツのハッシュを使用します。

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

リソースが変更されるたびに、新しい ETag 値を生成する必要があります。オン 後続のリクエストでは、ブラウザは ETag 値を If-None-Match リクエスト ヘッダー。サーバーの ETag がそれと一致する場合 ブラウザから送信されたリクエストに対して、サーバーは 304 Not Modified レスポンスを返します。 ブラウザはキャッシュ内のリソースを使用します。費用は引き続き発生しますが 304 Not Modified レスポンスは、ネットワーク レイテンシ全体よりもはるかに小さくなります HTML リソース。

ただし、リソースの更新頻度の再検証に伴うネットワーク レイテンシは やはりその欠点がありますウェブ開発の多くの側面と同様に トレードオフと妥協は避けられません24 時間以内ごとに 1 回 追加の労力をかける価値はあるか 念頭に置くようにして、HTML コンテンツを一切キャッシュする必要はありません。

<ph type="x-smartling-placeholder">

サーバーの応答時間を測定する

レスポンスがキャッシュに保存されない場合、サーバーのレスポンス時間は バックエンドアプリケーションスタックですウェブページで 動的に生成されるレスポンス（データベースからのデータ取得など）が TTFB が、配信可能な静的なウェブページよりも高くなる可能性があります。 バックエンドで長時間のコンピューティング時間を 必要とせずにすぐに実行できます特典として すべてのデータを クライアントサイドでフェッチすると より予測しやすいサーバーサイド環境から、予測不可能なものへと進化するでしょう。 使用します。クライアントサイドの労力を最小限に抑えることで、 ユーザー中心の指標を使用します

フィールドでの TTFB が遅い場合は、情報を開示できます。 Server-Timing を使用してサーバー上で時間が費やされた場所 レスポンス ヘッダー:

Server-Timing: auth;dur=55.5, db;dur=220

Server-Timing ヘッダーの値には、複数の指標と それぞれに異なる時間が設定されています。このデータは現場のユーザーから収集できる Navigation Timing API を使用して分析し、ユーザーが 遅れが生じます上記のコード スニペットでは、レスポンス ヘッダーに次の 2 つのタイミングが含まれています。

  • ユーザーの認証時間（auth）。これには 55.5 ミリ秒かかりました。
  • データベース アクセス時間（db）。これには 220 ミリ秒かかりました。
で確認できます。 <ph type="x-smartling-placeholder">

また、ホスティング インフラストラクチャを見直して、 ウェブサイトのトラフィックを処理するための十分なリソースがある。共有中 ホスティング プロバイダは高い TTFB の影響を受けやすいことが多く、専用ソリューションは 費用がかかる可能性があります

<ph type="x-smartling-placeholder">

圧縮

HTML、JavaScript、CSS、SVG 画像などのテキストベースのレスポンスは、 圧縮して圧縮し、ネットワーク経由の転送サイズを より高速にダウンロードできます。広く使用されている圧縮アルゴリズムは、gzip と Brotli。Brotli は gzip と比べて約 15 ～ 20% 改善されています。

圧縮は、ほとんどのウェブ ホスティング プロバイダによって自動的に設定されますが、 Google Cloud でリソースを構成する場合は 圧縮設定をご自身で調整することもできます

  1. 可能であれば Brotli を使用します。すでに述べたように、Brotli ではかなり多くの gzip と比べて大幅に改善されており、Brotli はすべての主要な 。可能な限り Brotli を使用する。ただし、ウェブサイトが 使用する場合は、代替手段として gzip を使うか、 どのような圧縮も行わない方がよいからです。
  2. ファイルサイズは重要です。1 KiB 未満の非常に小さなリソース。圧縮しない まったく圧縮しない場合もありますあらゆるタイプの有効性 データ圧縮の程度は、大量のデータが存在することにかかっており、 より圧縮可能なビットを見つけ出すために、圧縮アルゴリズムを できます。ファイルが大きいほど圧縮がうまくいきますが、 圧縮される可能性があるという理由だけで、非常に大きなリソースを出荷する 説明します。JavaScript や CSS などの大規模なリソースには、 ブラウザで前回の処理が完了してから解析と評価にかける時間が大幅に長くなる 解凍され、たまにしか使用していない場合でも、 変更によってファイル ハッシュが変わるため、わずかに変更しただけ。
  3. 動的圧縮と静的圧縮を理解する。動的および静的 圧縮は、リソースをどのような場合に なります。動的圧縮では、リソースの作成時にリソースが リクエストし、場合によっては毎回リクエストします。一方 静的圧縮はファイルを前もって圧縮するため、圧縮が不要 実行されるようにします。静的圧縮では、 圧縮に伴うレイテンシが増加し、サーバー レスポンスに悪影響が 最大 100 倍ですたとえば、 JavaScript、CSS、SVG 画像は静的に圧縮する必要がありますが、HTML は （特に、認証済みのために動的に生成される場合） 動的に圧縮する必要があります。

ご自身で圧縮を行うのは難しいため、通常は コンテンツ配信ネットワーク（CDN）に配信し、 自動的に処理しますこれらの概念を理解しておくと、 ホスティング プロバイダが適切に圧縮を使用しているかどうかを調べます。その知識が 圧縮設定を改善して、圧縮の優先順位を 効果を最大化できます

コンテンツ配信ネットワーク（CDN）

コンテンツ配信ネットワーク（CDN）は、複数のサーバーで構成される分散ネットワークです。 キャッシュし、エッジからリソースを提供します。 ユーザーと物理的に近い場所に配置されます。デバイスとの物理的な距離 ユーザーがラウンドトリップ時間（RTT）を短縮すると同時に、HTTP/2 や DDoS などの最適化 HTTP/3、キャッシュ、圧縮により、CDN はコンテンツをより迅速に配信できる 配信元サーバーから取得する場合よりも少なくなりますCDN を利用すると 場合によって、ウェブサイトの TTFB が大幅に改善される可能性があります。

<ph type="x-smartling-placeholder">

理解度テスト

完全に制御できるリダイレクトのタイプはどれですか。

クロスオリジン リダイレクト。
もう一度お試しください。
同一オリジンのリダイレクト。
正解です。

Server-Timing ヘッダーには複数の指標を含めることができます。

正しい
正解です。
誤り。
もう一度お試しください。

物理的に最も近いサーバータイプは、次のうちどれでしょうか。 どうすればよいでしょうか。

ウェブサイトの配信元サーバー。
もう一度お試しください。
コンテンツ配信ネットワーク（CDN）のエッジサーバー。
正解です。

次のステップ: クリティカル パスを理解する

ここまで、パフォーマンスに関するいくつかの考慮事項について学習しました。 ウェブサイトの HTML と照合すれば 広告を確実に読み込むことができます しかし、これはウェブの学習の始まりにすぎません。 向上します次に、クリティカル レンダリング パスの背後にある理論について説明します。 あります。このモジュールでは、レンダリング ブロックや ページの最初の URL を取得する際に各リソースが果たす役割について、 できるだけ速くレンダリングする必要があります