販売している製品/サービスの静的なランディング ページを運営しており、AdWords などを使用して宣伝しています。当然のことながら、ページの読み込み速度は、コンバージョンを最大化するための大きな要因です。
HTTP/2 の利点:
HTTP/2 の短所:
1) ロード速度を遅くする必須の TLS。
だから私は引き裂かれました。一方で、HTTP/2 には多くの改善点があります。一方で、不必要な TLS を避け続け、引き続き base64/スプライトを使用してリクエストを減らす方が速いかもしれません。
合計ページ サイズは ~1MB です。
それは価値があるでしょうか？
最新のハードウェアに対する TLS のパフォーマンスへの影響はごくわずかです。転送時間は、おそらくネットワークに依存します。TLS セッションを確立するために追加のネットワーク ラウンドトリップが必要なのは事実ですが、1MB を転送するのに必要な時間と比較すると、おそらく無視できる程度です (また、広くサポートされている TLS セッション チケットもラウンドトリップを節約します)。
これらの 1000 kb には、いくつの HTTP リクエストが必要ですか? それほど大きなページでは、エンド ユーザー エクスペリエンスにとってそれほど重要ではないと思います。ただし、TLS は今後も使用されます...サイトの速度が低下する可能性があるため、TLS を使用しないでください。正しく実行すれば、サイトの速度が低下することはありません。
SSL が遅くならないことについて詳しくは、https ://istlsfastyet.com/ をご覧ください。
読み込み速度を下げることは間違いなく努力する価値があるという証拠があります (速度のビジネス ケースを参照してください)。
TLS セッションは苦痛であり、HTTP2 にはプレーン テキストを妨げるものは何もないため、ブラウザー ベンダーがそれを主張しているのは残念です。低負荷システムの場合、CPU コストが制限要因ではない場合、TLS は基本的に 1 つの RTT (ネットワークの往復時間) のコストがかかります。
HTTP/2、特に HTTP/2 プッシュは、多くの RTT を節約できるため、TLS のコストがかかっても大きなメリットとなります. ただし、これを判断する最善の方法は、自分のページで試してみることです。プッシュをサポートする HTTP/2 サーバー (Jetty など) を使用していることを確認してください。そうしないと、すべての利点が得られません。 これは、SPDY を使用したプッシュの優れたデモです (これは、HTTP/2 と同じメカニズムです)。
SPDY/3.1 または HTTP/2 ベースの場合、両方とも多重化要求ストリームをサポートしているため、強制 TLS によってページの読み込み速度が低下することはありません。非 https よりも遅いのは、非 SPDY または非 HTTP/2 ベースの TLS のみです。
https://community.centminmod.com/threads/nginx-spdy-3-1-vs-h2o-http-2-vs-non-https-benchmarks-tests.2543/をチェックして、SPDY/3.1 と HTTP の理由を明確に示します/2 over TLS は、ページ全体の読み込みが高速です。HTTP/2 では複数のホストで同時に多重化が可能ですが、SPDY/3.1 ではホストごとの多重化が可能です。
最善の方法は、非 https と HTTP/2 または SPDY/3.1 https の両方をテストして、どちらが最適かを確認することです。静的なランディング ページがあるため、テストがはるかに簡単になります。https://h2ohttp2.centminmod.com/flags.htmlのページと同様のことを行うことができます。ここでは、HTTP/2、SPDY、および非 https の両方を同じサーバーにセットアップし、すべての組み合わせをテストして比較することができます。