HTTP2の準備：Webデザイナーと開発者のためのガイド

公開: 2022-03-10

簡単な要約↬Webデザイナーと開発者に適用されるHTTP / 2の基本について詳しく説明します。新しいプロトコルの主な機能、ブラウザーとサーバーの互換性を確認し、HTTP / 2の採用が増えるにつれて、考慮する必要のある事項について詳しく説明します。

ハイパーテキスト転送プロトコル（HTTP）は、サーバーとWebサイトの訪問者のブラウザーとの間の接続を管理するプロトコルです。 1999年以来初めて、このプロトコルの新しいバージョンがあり、すべての人にはるかに高速なWebサイトを約束します。

この記事では、Webデザイナーと開発者に適用されるHTTP2の基本について説明します。 新しいプロトコルの主な機能のいくつかを説明し、ブラウザーとサーバーの互換性を確認し、HTTP2の採用が増えるにつれて考える必要があるかもしれないことを詳しく説明します。

スマッシングに関するさらなる読み物：

プリロード：それは何に適していますか？
AMPについて知っておくべきことすべて
SmashingMagazineのパフォーマンスの向上

この記事を読むことで、短期的および長期的にワークフローを変更する際に考慮すべき事項の概要を理解できます。提起された問題をさらに掘り下げたい場合は、たくさんのリソースも含めます。私の目的は、HTTP2への移行を計画する際に、適切な決定を下せるように十分な背景を提供することです。

ジャンプした後もっと！以下を読み続けてください↓

HTTPの簡単な歴史

HTTPは古いプロトコルであり、最初は1991年に定義され、最後のメジャーリビジョンであるHTTP / 1.1が1999年に公開されました。1999年のWebサイトは、現在開発しているWebサイトとは大きく異なります。 説明されているhttp2で、Daniel Sternbergは、平均的なWebサイトのホームページをロードするために現在必要なデータの量は1.9 MBであり、ページを表示するために100を超える個別のリソースが必要であると述べています。 JavaScriptまたはCSSファイルに。

最新のWebサイトを表示するために必要な多数のリソースを取得する場合、HTTP /1.1は適切に機能しません。この記事の後半で説明するように、Web開発者として知っているパフォーマンスのベストプラクティスの多くは、HTTP /1.1の制限に対処することから生まれています。

SPDY

2009年、Googleの2人のエンジニアが、SPDYという名前の研究プロジェクトについて投稿しました。このプロジェクトは、HTTP /1.1のいくつかの問題に対処しました。 SPDYは次のことに着手しました：

多重化と呼ばれる、単一のTCP接続を介した同時要求を許可します。
ページの表示に不可欠なリソースが最初にサーバーによって送信されるように、ブラウザーがアセットに優先順位を付けることを許可します。
HTTPヘッダーを圧縮および削減します。
サーバープッシュを実装します。これにより、サーバーは重要なリソースを要求される前にブラウザーにプッシュできます。

さらに、SPDYには、ブラウザーとサーバーの間に暗号化（HTTPS）接続が必要です。

SPDYはHTTPに置き換わるものではありません。むしろ、これはプロトコルのトンネルであり、既存のHTTP要求と応答の送信方法を変更します。 サーバーとそのサーバーに接続しているブラウザの両方からのサポートが必要です。 NGINXで利用可能なサポートと、Apacheでのサポートを有効にするためにGoogleから利用可能なパッケージにより、SPDYがかなりの量採用されました。ブラウザのサポートもかなり良好で、すべての主要なブラウザの最新バージョンがそれをサポートしています。

使用できるSPDYブラウザのサポート情報 — 使用できますかに関するSPDYブラウザのサポート情報。（拡大版を表示）

HTTP2

SPDYがある程度の成功を収め、サーバーとブラウザーの両方で採用されるのを見てきました。ただし、Internet Explorer 11がサポートされているにもかかわらず、MicrosoftのEdgeブラウザがそれを削除していることに気付いたかもしれません。ここで何が起こっているのですか？

MicrosoftがHTTPプロトコルの最新バージョンであるHTTP2のサポートを実装しているため、EdgeではSPDYのサポートが終了しました。他の現在のブラウザは引き続きSPDYのサポートを維持していますが、Chromeは2016年にサポートを削除し、他のブラウザもそれに続く可能性があります。執筆時点では、Edge、Firefox、Chrome、OperaはSPDYとHTTP2の両方をサポートしています。 iOSを含むSafariは、Safari 9の発売により、今年後半にそのグループに参加する予定です。

HTTP2は、新しいプロトコルの開始点として使用されたSPDYの成功に基づいて構築されています。そのため、SPDYの目的の大部分はHTTP / 2で達成されます。 HTTPS接続の要件は廃止されました。とはいえ、すべてのブラウザベンダーは、TLS（https）接続にHTTP2のみを実装することを決定しました。したがって、サーバー間通信でクリアテキストを使用してHTTP / 2を使用できる可能性がありますが、ブラウザーにHTTP2を提供するユースケースでは、HTTP2への移行を検討する前に、サイトをhttpsで実行する必要があります。

HTTP2仕様は2015年2月に完成しました。 1年後、最新のブラウザでのブラウザサポートは優れています。 SPDYと同様に、HTTP2はブラウザーレベルとサーバーレベルの両方でサポートを必要とし、すでに多くのWebサーバー実装があります。これらはHTTP / 2wikiで追跡できます。 W3Techsには、2015年7月からの採用率の詳細に関する投稿もあります。このプロトコルの採用は、比較的新しいことを考えると、急速に進んでいます。

ウェブサイトを変更する必要がありますか？

HTTP / 2はHTTP / 1.1と下位互換性があるため、完全に無視することができ、すべてが以前と同じように機能し続けます。プロトコルの変更は、ユーザーに対して完全に透過的です。この記事の多くの読者は、HTTP /1.1以外のプロトコルを何年も使用しているでしょう。 Gmailアカウントをお持ちで、Chromeを使用してアクセスしている場合は、SPDYを使用してからHTTP / 2を使用していることになります。

ただし、ベストプラクティスであると考えることの多くは、HTTP / 2でのパフォーマンスに悪影響を与える可能性があります。時間の経過とともに、HTTP / 2を使用するように更新するサーバーが増え、HTTP / 2をサポートするブラウザーを使用する人が増えるにつれて、Webサイトは、一度はベストプラクティスに従って最適化され、新しいプロトコル用に最適化されたWebサイトよりも遅く見えるようになります。

HTTP / 2を採用するには何を変更する必要がありますか？

この記事の残りの部分では、HTTP / 2が採用されたときにアンチパターンになる一般的なベストプラクティスのいくつかを見ていきます。これまで見てきたように、移行は多くのWebサイトにとって遅いものになります。 HTTP / 2に移行するには、プロトコルをサポートするようにサーバーソフトウェアを更新する必要があります。これは、ホストされている方法によっては簡単な場合とほとんど不可能な場合があります。

特にHTTP / 2用にWebサイトに変更を加える前に、訪問者がそれをサポートするブラウザーを持っている傾向があるかどうかも考慮する必要があります。非常に最新のブラウザを使用している多くの人々を引き付けるウェブサイトの所有者は、ログに古いブラウザのユーザーの大多数が表示されている所有者よりも早くその切り替えを行うことができます。これを反映するために、この移行時間での作業方法についてもいくつか提案します。

TLSに移行する

多くのWebサイトでは、HTTP / 2に移行する上で最も難しいのは、HTTP / 2ではなく、安全な接続を介してサイトを実行するための要件です。新しいサイトを開発している場合、または古いサイトを更新している場合、最初の動きは、できるだけ早くhttpsで起動するか、httpsに移動することを確認することです。これはHTTP / 2だけでなく重要であり、Googleはランキング信号として安全な接続を使用し、ブラウザはhttps以外のWebサイトに「安全ではない」というフラグを立て始めています。将来的には、ジオロケーションなどのいくつかの強力なHTML5機能は、安全な接続なしでは利用できないことがわかります。

現在httpのみのサイトがある場合は、最初にhttpsへの移行を優先してから、HTTP / 2戦略を決定することをお勧めします。

複数の画像ファイルをスプライトに変換する

HTTP 1.1では、1つの大きな画像を取得する方が、小さな画像に対して多くのリクエストを行うよりもブラウザにとってはるかに効率的です。これは、複数のリクエストが互いに遅れてキューに入れられるためです。これを回避するために、小さなアイコンをスプライトファイルに変換することをお勧めします。

結果のスプライトは1つのHTTPリクエストで返され、複数のリクエストがキューに入れられる問題を防ぎます。ただし、訪問者がこれらのアイコンの1つだけを表示するページを表示している場合でも、その1つの画像を表示するには、必要以上に大きなファイルをダウンロードする必要があります。

HTTP / 2の多重化機能により、このリソースのキューイングはもはや問題になりません。多くの場合、小さな画像を個別に提供する方が適切です。訪問者がいるページに必要なものだけを提供する必要があります。スプライトの作成は、場合によっては引き続き保証されます。 HTTPリクエストは、パフォーマンスの1つの側面にすぎません。スプライトでいくつかの画像を組み合わせると、圧縮率が向上する可能性があります。したがって、特にこれらの画像がすべて読み込まれるページで使用される場合は、ダウンロードサイズが全体的に小さくなります。ただし、スプライトが常に最良の選択であるとは限りません。

データURIを使用した画像のインライン化

HTTP / 1.1での複数のHTTPリクエストの問題に対する別の回避策は、データURIを使用してCSSで画像をインライン化することです。この方法で画像を埋め込むと、スタイルシートがはるかに大きくなります。これをアセットを連結するための別の最適化手法と組み合わせた場合、訪問者は、画像が使用されているページにアクセスしたことがない場合でも、このコードをすべてダウンロードする可能性があります。

HTTP / 2ではHTTPリクエストが非常に安価であるため、この「ベストプラクティス」はパフォーマンスを向上させるのではなく妨げます。

CSSとJavaScriptの連結

ビルドプロセスの最終ステップとして、私たちの多くは、Webサイトで使用されているすべての小さなCSSファイルとJavaScriptファイルを連結します。これらのリソースを管理しやすくするために、開発中はこれらを分離しておくことがよくありますが、1つのファイルをブラウザーに配信する方が、5つを配信するよりもパフォーマンスが効率的であることがわかっています。繰り返しになりますが、HTTPリクエストを制限しようとしています。

これを行っている場合、ホームページにアクセスした訪問者は、Webサイトのほとんどを使用したことがない場合でも、Webサイトに必要なCSSとJavaScriptをすべてダウンロードする可能性があります。開発者は、Webサイトの各領域の特定のファイルを慎重に選択してビルドプロセスに含めることでこの問題を回避できますが、これは非常に多くの作業になる可能性があります。

連結に関する追加の問題は、すべてを一度にキャッシュからパージする必要があることです。コードベースの頻繁に変更される部分に短い日付を与えながら、長い有効期限を決して変更しないファイルを与えることはできません。 1ページで使用されているCSSの1行でも変更された場合は、すべて有効期限が切れている必要があります。

これがどこに向かっているのかわかると思います！ HTTP / 2の世界では、HTTPリクエストは安価です。アセットが使用されるページに従って、開発中にアセットを整理する方がはるかに優れています。その後、訪問者が必要とするコードのみを提供できます。小さなスタイルシートをたくさんダウンロードすることは重要ではありません。また、物事が変化する頻度に基づいて整理することもできます。寿命のある資産は、その後、より長く世話をすることができます。

ホスト間でのリソースの分割：シャーディング

HTTP / 1.1では、開いている接続の数に制限されています。多数のリソースをロードすることが避けられない場合、この制限を回避する1つの方法は、複数のドメインからリソースを取得することです。これは、ドメインシャーディングとして知られています。これにより、読み込み時間を短縮できますが、Webサイト用にこれを準備するための開発オーバーヘッドは言うまでもなく、それ自体が問題を引き起こす可能性があります。

HTTP / 2は、必要な数のリソースを要求できるため、ドメインシャーディングのこの必要性を排除します。実際、この手法は追加のTCP接続を作成し、HTTP / 2がリソースを優先するのを妨げるため、パフォーマンスを低下させる可能性があります。

今すぐHTTP / 2の準備をする方法

ある程度の寿命が期待できるが、おそらくサーバーのサポートのためにHTTP / 2を起動できないプロジェクトを開始する場合は、HTTP / 2の準備方法を検討する価値があります。ビルドプロセスにいくつか追加して、後で切り替えを簡単にすることができます。

スプライトとデータURIに加えて個々のアセットを作成する

スプライトを作成している場合は、それらの個々のアセットの作成と最適化もプロセスに追加するか、これらによってパフォーマンスが最も向上すると思われる場合は、ページ固有の小さなスプライトを追加します。これにより、Webサイトの転換点に達したときに、大きなスプライトから小さな（またはまったくない）スプライトに簡単に切り替えることができます。

同じことがデータURIにも当てはまります。現在CSSでこれらを使用している場合は、この手法から切り替えるときに画像を準備してください。

ウェブサイトセクションでアセットを整理する

CSSとJavaScriptを連結すると、とにかくファイルがすべて一緒に押しつぶされるため、開発を容易にするために最適化する誘惑があります。 HTTP / 2に切り替えると、特定のページに必要なものだけがそのページに配信されるようにリソースを注意深く管理することで、最高のパフォーマンスが得られます。したがって、この方法で開発を整理し始めると、今は成果が得られます。今のところ、まだ連結している可能性があり、転換点に達したら、ビルドプロセスのその部分を停止して、リソースを個別に提供できます。

ドメインシャーディングを管理する

HTTP / 1.1の現在のベストプラクティスは、シャーディングを2つのホスト名に制限することです。 TLS証明書が両方のホストに対して有効であり、ホストが同じIPに解決される場合、HTTP / 2を取得して接続を合体させる方法があります。ブラウザの実装者はHTTP / 2をHTTPSで実行する必要があるため、TLS証明書を取得してHTTP / 2で実行する必要があります。 VelocityConferenceのIlyaGrigorikのスライドデッキのスライド26で詳細をご覧ください。

もっと来る

最終的には、HTTP / 2の多くのベストプラクティスを取得します。最高のパフォーマンスを得るには、このプロトコルによって多くの制御が返されます。つまり、プロジェクトごとに決定を下す必要があります。この記事では、サーバープッシュなどのHTTP / 2の新機能を利用する方法については説明していません。このテクノロジーを使用すると、どのリソースを優先するかを決定し、重要度の低いものの前にそれらを配布するようにサーバーに指示できます。

いつ切り替えるか？

展開先のサーバーを完全に制御できない設計者や開発者の場合、使用するサーバーが更新されるまで決定を待たなければならない場合があります。すでにHTTP / 2を提供しているホスティング会社があります-共有ホスティングの場合でも-サポートサーバーにデプロイすることは、彼らが利益を得ることがわかっている場合、クライアントに推奨できるものです。

WebサイトがHTTP / 2をサポートするサーバーでホストされると、HTTP / 1.1の最適化を続行するか、HTTP / 2の最適化を継続するかの決定は、大多数のユーザーがサポートするプロトコルに委ねられます。 HTTP / 2には下位互換性があることを忘れないでください。特に、何もする必要はありません。あなたがする必要がある決定はそれのためにいつ最適化するかです。

分析データに基づいて決定する必要があります。 HTTP / 2をサポートするブラウザを使用している訪問者がそうでない場合よりも多い場合は、それがそれらのユーザー向けに最適化するための妥当な転換点であることをお勧めします。私たちの多くはすでにその時点に到達しているでしょう。 Can I Useなどのサイトのデータを、独自の分析および見込み客の知識から収集したデータと一緒に使用する必要があります。たとえば、HTTP / 2の利点の多くは、モバイルデバイスをサポートするHTTP / 2のユーザーによって最も強く感じられます。モバイルトラフィックの割合が高い場合は、HTTP / 2に早く移行する必要がある可能性があります。ただし、Opera Miniを使用して閲覧するユーザーからのモバイルトラフィックの割合が高い場合は、HTTP / 2への移行を延期する理由になります。これは、一部のユーザーが多数いる一方で、現在HTTP / 2はサポートされていないためです。世界の一部。

今日、まったく新しいWebサイトを構築している場合は、構築全体を通してHTTP / 2の最適化を念頭に置くことをお勧めします。起動時に、ブラウザまたはサーバーのサポートのためにHTTP / 1.1の譲歩が必要だと感じた場合、その多くはビルドプロセスで実行できるため、感じたらすぐにHTTP / 2バージョンに切り替えることができます。時は正しい。

HTTP / 2アクションプラン

安全な接続で起動するか、今すぐTLSに移行してください。これが優先事項です。
ビルドプロセスでHTTP / 2の準備をします。 あなたが今構築しているウェブサイトは、その存続期間にわたってHTTP / 2用に最適化されることで恩恵を受ける可能性があります。上記のヒントを使用して、両方のプロトコルに最適化できるビルドプロセスを作成します。
統計を確認してください。 Webサイトでのブラウザーの使用状況をCanI Useのサポート表と比較することで、訪問者の何パーセントがHTTP / 2最適化の恩恵を受けるかを確認できます。
ホスティングを確認してください。 切り替えのメリットが得られるようになったら、サーバーがHTTP / 2をサポートしていることを確認する必要があります。ホスティングプロバイダーまたはサーバー管理者に相談して、移行計画を確認してください。
HTTP / 2最適化を展開します。 サーバーがHTTP / 2をサポートしたら、残りはあなた次第です。古いベストプラクティスの使用をやめ、新しいものに切り替えます。これは、HTTP / 2をサポートしていないブラウザーを使用しているユーザーのエクスペリエンスが遅くなることを意味します。そのため、変更の背後にあるドライバーが、大多数が恩恵を受けるときの転換点になるはずです。

HTTP / 2に移行するときは、速度の向上をベンチマークし、どの手法がWebサイトに最大の違いをもたらしたかを確認するのは興味深いことです。人々がウェブサイトを移行するときに、実際の事例からの情報を見るのを楽しみにしています。その情報は、まったく新しい世代のベストプラクティスを開発するのに役立ちます。

詳細はこちら

HTTP / 2に関する情報がオンラインで利用できるようになっています。参考までにいくつかのリソースをここにリストしました。その多くは、この記事の執筆中に参照しました。

「ハイパーテキスト転送プロトコルバージョン2（HTTP / 2）」（仕様）、インターネット技術特別調査委員会仕様を読むのが好きな人、または細かい点を理解する必要がある人向けです。他のすべての人にとって、HTTP / 2FAQは主な機能の優れた要約です。
http2の説明、Daniel Sternbergこの無料の電子ブックは、戦略を計画するときにプロトコルの詳細を掘り下げたい場合に読む価値があります。
High Performance Browser Networking 、Ilya Grigorik、O'Reillyこの本は、HTTP /1.1のベストプラクティスとHTTP / 2の両方をカバーしています。今日のパフォーマンスを向上させ、将来に備えることを望む人にとっては便利です。
「HTTP / 2はここにあります、最適化しましょう」（スライドデッキ）Ilya Grigorikこの優れたスライドのセットには、この記事で取り上げたいくつかのポイントに関する詳細情報が含まれています。
HTTP / 2インジケーター：FirefoxとChromeこのブラウザープラグインは、アクセスしているWebサイトがHTTP / 2経由で提供されているかどうかを示します。
詳細については、RebeccaMurpheyによってキュレーションされたリンクのこの膨大なリストを参照してください。