HTTP/2とページスピードの紹介

公開: 2020-01-03

序章

1991年に、要求/応答HTTP（HTTP 0.9）プロトコルの最初の文書化されたバージョンが導入されました。それ以来、Webは大幅に拡張され、24年後、2015年に最新バージョンのハイパーテキスト転送プロトコル（HTTP / 2）がリリースされ、正しく実装された場合にサイトのパフォーマンスに多くのメリットがもたらされました。

この記事は、ページ速度最適化イニシアチブの一部としてHTTP/2を実装したいSEOを対象としています。

HTTP / 2は非常に豊富なトピックであり、詳細に説明することができます。 HTTP / 2について説明しているオンライン情報は豊富にあり、エンドユーザーや開発者にとっては幅広いメリットがありますが、HTTP / 2に関する豊富な情報に没頭する前に、必要な情報を入手していることを確認してください。これは、適切な質問をすることから始まります。

これは検索エンジン最適化やページ速度に直接どのように影響しますか？
洞察から推奨を行うことはできますか？
推薦は現実的に実行できますか？

これらの質問は、 「私が行っていることは効果的で価値があるか」という質問に役立ちます。そして最終的には、HTTP/2がWebサイトの改善にどのように役立つかを評価するためのより良い立場にあなたを置きます。

トピックの性質が広いため、SEOの重要性を理解しようとするときに必要とされないHTTP/2に関する知識がたくさんあります。 SEOのためのHTTP/2の主な利点は、ページ速度です。

豊富なオンライン情報をナビゲートするのに役立つように、ここではHTTP / 2の概要を説明し、HTTP 1.1からGoogleのHTTP互換Spdy、そして最終的にはHTTP/2への進化について説明します。

Webがどのように進化したかを理解することは、HTTP/2プロトコルの追加の結果としてWebに加えられた改善を強調するのに役立ちます。

Googleはページ速度をどのように評価しますか？

Googleがページ速度をどのように評価しているかを確認するには、 Chromeのユーザーエクスペリエンスレポートをご覧ください。これらのレポートは、ユーザーがWeb全体で人気のある目的地をどのように体験しているかについてのユーザーエクスペリエンスメトリックを提供します。これは、主要なユーザーエンゲージメント指標（First Paint、First Contentful Paint、First Meaningful Paint、Time to Interactive）を使用して強化され、Page Speed Insights、Public Google Big Query Project、Lighthouse、WebPageTestなどの一般的なツールを介してさらにサポートされます。これらの指標とツールを利用すると、ページ速度を改善できる可能性があります。

HTTP/2の紹介

HTTP 1.1

2015年までに、HTTP1.1は時代遅れになりました。 Webページ/サイトが基本的なHTML、CSS、JavaScript、および多数のリソースとさまざまなフレームワークに基づいて構築/依存されていた時代は終わりました。 2015年以前の時代は、TCP接続ごとに1つのリクエストに制限されているという考えに基づいていました。これにより、Webクライアントがダウンロードのために複数のリソースをキューに入れ、ネットワークの輻輳とページの読み込み時間が遅くなる状況が発生しました。

HTTP / 2は、上記の問題を軽減するために、3つの主要な改善領域を対象とするように設計されています。

シンプルさ
ハイパフォーマンス
堅牢性

HTTP/2のSEOの利点

ページ速度は、おそらくSEOが自分のWebサイトまたはクライアントのWebサイトにHTTP/2を実装することを検討する主な理由です。ページ速度/パフォーマンスは、デスクトップクエリの2010年以降のランキング要素である一連のメトリックです。モバイルデバイスの使用が増加したため、2018年7月、GoogleはPageSpeedがモバイルのランキング要素になることを正式に発表しました。

HTTP / 2は、ページ速度のためにサイトを最適化するときに利用できる3つの主要な機能を提供します。

多重化
サーバープッシュ
ストリームの優先順位付け

多重化

多重化により、Webクライアントは単一のTCP接続内に複数の要求を含めることができるため、サーバーの負荷が軽減され、ネットワークの輻輳が軽減されます。

古いHTTP1/ 1.1プロトコルを利用する最新のWebクライアント（Chrome、Firefox、Safari、Opera）には、ホスト名ごとの同時TCP接続数にデフォルトの制限があります。したがって、HTTP 1 / 1.1を利用するWebクライアントは、TCPの輻輳に簡単に悩まされる可能性があります。最新のWebクライアントでは、この問題は多重化を使用して解決されます。これにより、ページ速度が最も大幅に向上する可能性があります。

以下に示すのは、HTTP/1.1とHTTP/2の比較を使用した多重化の利点であり、 HTTP/2多重化が有効になっている場合と有効になっていない場合の一般的な動作を示しています。

（ WebpageTest、HTTP / 1.1、多重化のデモンストレーションなし）

（ WebpageTest、HTTP / 2、多重化のデモンストレーション）

上の画像では、パフォーマンスベースのウォーターフォールを使用して、Webページのユーザー（リソースを要求する）とサーバー（どのリソースに応答するか）の間のリソースのロードを示しています。 通常、ページリソースには、HTML、JavaScript、CSS、および画像が含まれます。パフォーマンスベースのウォーターフォールは、特定のリソースがいつ呼び出され、ダウンロードされ、クライアント内でレンダリングされるかについての正確なポイントを示します。これは、サイトのページ速度の問題を発見、評価、分析する上で重要です。「HTTP/2」の上の画像で示されているように、すべてのリソースが同時にダウンロードを開始し、リソースが別のポイントでロードを開始することはありません。 HTTP / 2は多重化を利用し、単一のTCP接続を介して1つの要求のみを送信することに依存しなくなったため、上記のように複数のリソースを同時にダウンロードできます。対照的に、画像「HTTP / 1.1」で示されているように、リソースは多重化機能を利用できないため、同時にダウンロードされません。 HTTP / 1.1での平均的な最新のブラウザーは、同時に6つの接続を持つことができますが、HTTP / 2を実装する利点は、HTTP / 1.1で同時に実行できる接続の数に関係なく、すべての要求にTCPハンドシェイクが必要ないことです。接続プロセスは毎回完了する必要があります。したがって、それらはさまざまな時点でダウンロードを開始しているため、ユーザーのページの読み込みが長くなります。

（ Upwork HTTP/1.1とHTTP/2の図）

GoogleやBingなどの検索クローラーは、HTTP/2実装の恩恵を直接受けません。上記のように、これらの最適化の主な利点は、ページ速度にある可能性があります。したがって、HTTP / 2の実装は検索クローラーに直接影響を与えない可能性がありますが、2010年以降のデスクトップクエリと2018年7月以降のモバイルクエリのGoogleの直接的なランキング要素であるページ速度に影響を与える可能性があります。その結果、ウェブサイトが配信されないことが重要です。 Googleがランキングに影響を与えることでパフォーマンスを抑制したり、最近ではサイトが遅い可能性があることをユーザーに報告したりするため、ユーザーのエクスペリエンスが遅くなります。

サーバープッシュ

サーバープッシュを使用すると、特定のサーバーまたはエッジネットワークが、クライアントから要求されていないときにリソースをWebクライアントに送信できます。サーバープッシュがどのように機能するかを理解するには、最初にWebサイトが従う要求/応答パターンを理解することが重要です。ユーザーがWebサイトからページを要求すると、サーバーは要求されたコンテンツ/リソースで応答します。

仮に、styles.cssと呼ばれる外部スタイルシートですべてのスタイルが定義されているサイトについて考えてみてください。ユーザーがページのHTMLスケルトン（この場合はindex.htmlなど）を要求すると、サーバープッシュはindex.htmlへの応答の送信を開始した直後にCSSをユーザーに「プッシュ」できます。

（スマッシングマガジン、サーバープッシュ）

サーバープッシュがページ速度の向上にどのように役立つかを理解する前に、ブラウザー内に表示される画像、CSS、JavaScriptなどのさまざまなリソースでブラウザーがどのように機能するかを理解することが重要です。ご覧のとおり、ブラウザは画像、CSS、JavaScriptリソースをダウンロードする方法の説明を送信します。初めてWebサイトにアクセスするときは、通常、.htmlファイルであるGETリクエストを行います。この.htmlファイルを受信すると、ブラウザはそれをスキャンして理解し、HTMLファイルに含まれている内容に応じて追加のGETリクエストを行う場合があります。

サーバープッシュはページ速度の向上にどのように役立ちますか？

サーバープッシュを使用することで、ブラウザーから必要なGETリクエストの数（ラウンドトリップ）が削減され、ページの読み込み時間が長くなる原因となるレンダリングの遅延が回避されます。これにより、Webクライアントのレンダリング時間が大幅に改善され、ユーザーがWebページをより速く表示できるようになり、ユーザーのエクスペリエンスが大幅に向上します。

サーバープッシュは、Googlebotがサイトや他のクローラーをクロールする方法に直接影響を与えませんが、SEOのメリットは、FirstPaintやFirstMeaningfulContentなどのユーザー中心の要素を改善することで得られます。

Webページテスト、Lighthouse、Page Speed Insights、およびChromeユーザーエクスペリエンスレポートを利用して、同じ業界内の競合他社と比較したサイト/ページのパフォーマンスを判断できます。以下は、サーバープッシュなし（画像1）とサーバープッシュあり（画像2）の実装を示す2つの画像です。

（WebpageTest、サーバープッシュなし）

（WebpageTest、HTTP / 1.1、サーバープッシュあり）

サーバープッシュを使用すると、サーバーは、追加のページコンポーネント（CSSファイル、JavaScript、画像など）を含む.htmlファイルを送信するように求められた場合に、それらを常に送信するように構成できます。

上記のウォーターフォールでは、push.phpが4つのCSSファイルを使用していることがわかります。

サーバープッシュがない場合、ブラウザーはpush.phpファイルを受信し、HTMLを解析してから、追加のCSSファイルごとに特定の要求を行う必要があります。すべてのCSSファイルを受信すると、レンダリングプロセスでそれらのファイルの使用を開始できます。

サーバープッシュが有効になっている場合、push.phpのリクエストにより、サーバーは4つのCSSファイルを送信するように自動的にトリガーされます。ブラウザはそれらを受け取り、レンダリングプロセスではるかに早くそれらの使用を開始できます。これは、ブラウザがページコンテンツのレンダリングをはるかに早く開始できることを意味し、その結果、ページ速度メトリックが向上します。

HTTP/2の優先順位付け

HTTP / 2優先順位付けは、リソースがロードされる順序の制御をサイト所有者に戻します。適切に行われると、優先順位付けは、ページリソースを最適化された順序で配信することにより、ユーザーエクスペリエンスとページ/サイトの速度を向上させ、「高速な」ユーザーエクスペリエンスを実現します。

HTTP/2の前身であるHTTP/1.1を見ると、Webクライアントがリソースがロードされる順序を制御していました。上で説明したように、これは、各TCP接続が一度に1つのリソースしかサポートできなかったという事実によるものでした。選択するリソースと並行して開く接続の数を決定することにより、リクエストをスケジュールするのはブラウザ次第です。

それがどのように行われるかを説明する前に、リソースに優先順位を使用する理由を理解することが重要です。

ページの上部に画像があり、ページの下部に画像がある場合、論理的には、上部の画像が下部の画像の前に読み込まれることを確認する必要があります。この概念は、HTTP/2優先順位付けがもたらす可能性のある重要性と影響を示すのに役立ちます。 HTTP / 2の優先順位付けにより、最初に配信して他のリソースよりも先に読み込むリソース（JavaScript、CSS、画像）を指定できるため、ページの読み込み時間を最速にすることができます。

ブラウザは、多重化を使用して単一のTCP接続を介して複数のリソースを同時に要求できるようになりましたが、リソースをいつ/どのように配信するかを決定するのに役立つ優先度情報を各要求で指定できるようになりました。サーバーとブラウザの両方がHTTP/2の優先順位付けをサポートしている場合、ブラウザは、リソースが互いに競合することなく、全帯域幅を利用して優先順位付けのルールを定義する必要があります。優先順位付けプロセスがどのように機能するかをよりよく理解するには、HTTP/2優先順位付けに重要な3つのパラメーターについて説明することが重要です。

ストリーム：これは、確立された接続内のバイトの双方向フローであり、1つまたは複数のメッセージを伝送する場合があります。

親ストリーム：これは、リソースが依存しているストリームです。

子ストリーム：これは、親ストリームの依存ストリームです。 それらは同じ親を共有するため、子ストリームとして知られています

重み：これは1〜256の範囲で割り当てられる数値であり、複数のストリームが接続を共有している場合にストリームに割り当てる帯域幅を識別します。帯域幅は、他のすべてのアクティブなストリームの重みに関連して割り当てられます。

排他ビット：これは、他のストリームと帯域幅を共有せずにストリームをダウンロードする必要があることを示すフラグです。

ヘッダーフレーム：これは、ストリームが属するフレームのIDです。

バイナリフレーミングレイヤー：これは、HTTPメッセージがカプセル化され、クライアントとサーバー間で転送される方法です。

以下の例は、上記の例を示しています。

（ Google Developers HTTP / 2ストリームの優先順位付け）

HTTP / 2優先順位付けを実行するには、新しいHTTP/2バイナリフレーミングレイヤー内にあるヘッダーフレーム内に優先順位付け情報を追加する必要があります。親ストリームと他の子ストリームへの依存関係/非依存関係によって、優先度/均等化が決まり、リソースのWebクライアントへの配信が決まります。

HTTP / 2の優先順位付けは現在、多数のプラットフォームでサポートされていますが、多くのCDNとホスティングプロバイダーはHTTP/2の優先順位付けをサポートしていません。したがって、この最適化手法を使用する場合は、HTTP/2の優先順位付けをサポートするCDN/ホスティングプロバイダーを利用していることを確認することが重要です。以下は、どのCDN/ホスティング/サーバーがHTTP/2優先順位付けをサポートできるかできないかを説明する表です。

HTTP/2の優先順位付け-共通のサーバー/ホスティング/CDNの互換性

この比較は2020年2月1日に正しかったが、どちらを選択するかを決定する前に、潜在的なサービスプロバイダーが互換性を改善したかどうかを確認する価値があります。

残念ながら、すべてのブラウザがHTTP / 2の優先順位付けをサポートしているわけではなく、Webクライアントが異なるため、優先順位が異なるため、特定のブラウザを批判的に検討することも重要です。以下は、どのWebクライアントがHTTP/2優先順位付けをサポートできるかを説明する表です。

HTTP/2優先順位付けWebクライアントの互換性

HTTP / 2の優先順位付けは、ページ/サイトの速度に対するユーザーの認識を大幅に向上させ、Chromeユーザーエクスペリエンスレポート内に蓄積されたデータにプラスの影響を与えます。この最適化はGooglebotなどの検索クローラーには影響しませんが、 LighthouseやPage Speed Insightsなどのツールは、ユーザーの観点からページ速度のパフォーマンスに対するHTTP/2優先順位付けの影響を評価するのに役立ちます。

HTTP /2でサポートされているCDN/ホストを利用してサーバーとクライアントの両方でストリームの重みを正しく構成することで、クライアントのページ速度メトリックを大幅に向上させることができます。

HTTP/2の前提条件は何ですか

HTTP / 2の速度の利点を利用できるようになる前に、それを利用できることを確認してください。考慮する必要があるいくつかの前提条件があります。

HTTPSが有効になっていることを確認することが重要です。
認証された機関からのTLS証明書を利用し、証明書をアクティブ化してインストールします。
Nginx、Apache、IISなどのWebサーバーソフトウェアがHTTP/2をサポートしていることを確認してください。サポート用の完全な認証済みリストはhttp://ayi.ma/browsershttp2にあり、HTTP/2のブラウザーサポートが表示されます。 CDN/ホスティングのHTTP/2サポートをお探しの場合は、http：//ayi.ma/serverhostingを参照してください。

よくある落とし穴/HTTP/2の導入で変更しなければならないこと

以前のHTTP1.0およびHTTP1.1プロトコルの制限により、開発者とSEOは、これらの制限がページ速度のパフォーマンスとセキュリティにもたらす多数の問題を回避する方法を見つけるよう努めてきました。

最終的に、彼らはこれらの制限のいくつかを回避するための「ハック」を見つけることができましたが、これらの方法の多くは開発者にさらに多くの作業を引き起こしました。あなたが尋ねるかもしれないこれらのハックのいくつかは何ですか？ HTTP / 2を正しく実装することで解決できる、サイトで見られる最も一般的なハッキングのいくつかを次に示します。

ドメインシャーディングを回避する

驚いたことに、HTTP / 2が正しく実装されていても、多くのサイトがこのハックを使用しています。 HTTP / 2が有効になっている場合、ドメインシャーディングを利用しないようにすることが重要になります。ドメインシャーディングは、リソースを異なるホスト名に分割する手法であり、より多くのリソースを同時に提供できるようにします。

更新されたHTTP/2プロトコルのおかげで、ドメインシャーディングは不要になり、実際、解決するよりも多くの問題が発生します。 HTTP / 2がサイトで正しく構成および有効化されており、ドメインシャーディングも使用している場合、ブラウザは複数のホスト名にまたがる多重化とダウンロードのメリットを享受できないため、実際にはHTTP/2のメリットの一部を打ち消しています。

さらに、ドメインシャーディングを使用すると、実際にストリームの優先順位付けが破られ、ページ速度を最大限に活用するためにリソースをロードできなくなります。

サーバープッシュを適切に利用する

サーバープッシュには、注意が必要ないくつかの欠点があります。サーバープッシュは実際には使いすぎである可能性があり、いつ使用するかを選択する必要があります。 WebクライアントがHTMLだけでなく、「プッシュ」されたすべてのものをダウンロードする可能性があるため、必ずしも多くのリソースをプッシュする必要はありません。これは、ページの読み込みとレンダリングに実際に時間がかかる可能性があることを意味します（Time to InteractiveなどのGoogleが焦点を当てているユーザー中心の指標が増えます）。

サーバープッシュの2つ目の一般的な落とし穴は、Webクライアントがすでに持っているリソースをプッシュしない方法を見つけることです。これは、さまざまな方法で制御できます。 1つの方法は、リソースをリピーターにプッシュしないことを選択し、リピーターがキャッシュされたアセットを利用できるようにすることです。これは、はるかに簡単な実装です。これは、リソースのキャッシュヘッダーをチェックして、ヘッダーがサーバープッシュの実装と重複していないことを確認することで簡単に実行できます。

HTTP/2での実際のテスト

理論的な知識は、HTTP/2とその利点を理解するための基礎を築くために常に重要です。概念を理解して理解したら、HTTP / 2がページ速度に与える影響を測定するために、これらの理論をテストすることが重要です。

このページスピードシリーズのパート2-実生活で-ウェブサイトのテストと分析を使用して、ページスピードとSEOの価値に関するHTTP / 2の真のメリットについて説明しますので、お見逃しなく！

HTTP / 3はどうですか？

HTTP / 3は、HTTP / 2の後継プロトコルとして明確な可能性を示していますが、Web全体のSEOのHTTP/2の終了を通知するものではありません。ワールドワイドウェブへのすべての新しい主要な開発と同様に、それは通常の展開段階を経て、サイトが新しいプロトコルを採用するのに、そしてそれがSEO業界内の事実上の標準になる前におそらく時間がかかるでしょう。 HTTP / 2の実装は、正しく実装された場合にサイトのパフォーマンスを向上させるのに役立つ、有益で単純な利点を表しています。