HTTP/2は有効にする前にpageごとの重いresourceと接続の確認を分ける

HTTP/2を有効にしても、重い画像、不要なscript、遅い外部service、設定を誤ったcacheはそのまま残ります。HTTP/2は同じ接続で複数のrequestとresponseを扱える仕組みです。導入の目的は「HTTP/2対応」と表示することではなく、利用者が必要な本文、画像、formを待たずに使える状態に近づけることです。まずpageごとに、何が遅く、どこから読み込んでいるかを確認します。

RFC 7540は、HTTP/2がheader fieldの圧縮と、一つのconnection上で複数のexchangeを並行して扱うことで、network resourceをより効率よく使い、待ち時間の感じ方を減らすことを目指す仕様だと説明しています。requestとresponseはstreamという単位で扱われ、あるresourceのresponseが遅れても、別streamの進行を止めない仕組みです。これは、pageを構成するfileが多いsiteで有利に働く場合があります。

ただし、同じconnectionで並行に読めることと、送るdataが小さくなることは別です。大きい画像を一枚送る時間、不要なscriptを評価する時間、外部domainへの新しい接続を待つ時間は、HTTP/2という名前だけではなくなりません。protocolを変える前に、pageを読めるようにするdataと、後でもよいdataを分けます。

HTTP/2が変える部分と変えない部分を分ける

HTTP/1.1では、多くのresourceを同時に取得するために複数のconnectionを使うことがあります。HTTP/2では、一つのconnectionに複数のstreamを開き、frameを交互に送れます。header fieldも圧縮されます。複数のCSS、JavaScript、画像を読み込むpageでは、connectionを増やすためだけにfileをまとめていた設計を見直す材料になります。

しかし、HTTP/2は本文を短く書き直したり、画像の大きさを適切にしたり、不要な外部scriptを外したりする機能ではありません。利用者が最初に読むcompany案内やservice pageに、大きな画像、使われていないlibrary、複数の計測tagがあれば、それぞれのrequestはHTTP/2でも必要です。fileを並行に送れることを理由に、必要性を確かめずresourceを増やしてはいけません。

ここでいう同じoriginとは、scheme、host、portを含めて同じweb originです。自社domainのpageから、別domainのfont、動画、広告、access analysisを読み込めば、通信の相手は増えます。HTMLをHTTP/2で配信できても、外部resourceの待ち時間まで一つのconnectionへまとめられるとは限りません。pageの速さを調べるときは、resourceの数だけでなく、どのdomainへrequestしているかを並べます。

最初に表示する内容を先に決める

pageを開いた直後に利用者が必要とするものは、業種やpageの役割によって変わります。会社案内なら、何をしている会社か、連絡先、所在地の案内が先です。service pageなら、提供内容、条件、問い合わせへ進む入口が読めることが先になります。portfolioや採用pageでも、写真の演出を待たなければ本文が読めない設計は、目的に照らして見直す余地があります。

説明用の仮例として、service pageの最初に大きな写真、複数のWeb font、slider用のscript、access analysis用script、問い合わせformを置く場合を考えます。HTTP/2で同じoriginのresourceが並行に読み込まれても、写真のdataが大きく、fontが失敗したとき本文が読みにくく、scriptがform操作を止めるなら、利用者は問い合わせへ進みにくいままです。最初に本文と連絡先が読めるかを見てから、装飾や計測の読み込み順を決めます。

この確認は、デザインを単純にするためだけのものではありません。画像を小さくすればよい場合もあれば、表示領域に合う画像を用意する方がよい場合もあります。外部scriptを後へ回せる場合もあれば、formの入力検査に必要なscriptは先に使う必要があります。pageごとに、利用者が最初に行う行動と、それに必要なresourceを対応させます。

server pushは先回りして送ることと必要なものを送ることを分ける

HTTP/2には、serverが利用者の次のrequestを予想してresponseを送るserver pushという仕組みがあります。RFC 7540は、利用者が必要としそうなresponseをserverが先回りして送ることで、待ち時間を減らす可能性がある一方、network usageとの交換になることを説明しています。先に送れば常に速くなる、という意味ではありません。

たとえば、すでにbrowser cacheにあるCSSを毎回pushすれば、利用者が必要としないdataを受け取る可能性があります。pageによって使わないscriptをpushすれば、表示に必要なresourceと通信を奪い合います。server pushを使うなら、最初の画面で必ず必要になり、cacheにない場合が多いresourceかを確認します。確かめずにすべてのCSSやJavaScriptを送る設定にはしません。

小規模siteでは、server pushを先に設定するより、使っていないpluginのCSS、重複したlibrary、必要以上に大きい画像を見つける方が、原因と対処の関係を追いやすいことがあります。機能を増やしたことを改善と呼ばず、変更前後の同じpageで、本文、画像、menu、formが使えるまでの状態を比べます。

導入前後はprotocolと画面を別に確認する

HTTP/2の導入をserver会社や制作者へ頼むときは、「対応できます」という回答だけでは足りません。どのdomainでHTTP/2を使うか、HTTPS接続で正常に表示できるか、CDNやproxyを通した後もHTTP/2になっているか、既存のredirectとcacheが動くかを確認します。protocolの確認と、pageの確認を同じ作業にしない方が原因を切り分けやすくなります。

1. 重要なpageを三つ程度選び、HTML、CSS、JavaScript、画像、外部resourceのrequest先を記録する。
2. browserのnetwork表示またはserverの確認方法で、各pageがHTTP/2で取得されているかを見る。
3. mobile回線とPC回線で、最初に本文、画像、menu、問い合わせformが使えるかを確認する。
4. cacheを使うpageでは、更新前のfileが残らず新しい内容へ変わるかを確認する。
5. protocol変更日、担当者、serverまたはCDNの設定場所、戻す方法を記録する。

HTTP/2に切り替えたあと、表示が速くなったように見えても、一回だけの読み込みで判断しません。初めて開く場合とcacheがある場合では、待つresourceが違います。変更前後を比べるなら、同じpage、同じconnection条件、同じ確認項目をそろえます。表示時間だけを一つの数字で比べるより、本文が読める時点、画像が崩れない時点、formが送れる時点を分けて見る方が、次に直す場所を決めやすくなります。

外部へ作業を頼む場合は、certificate、server、CDN、cache pluginのaccountを誰が持つかも確認します。HTTP/2を有効にする作業と、あとで設定を見直せることは別です。引継ぎ後に証明書更新やcache設定を確認できなければ、表示に問題が起きたとき自分で判断できません。最初の一手は、最も重要なpageを一つ選び、最初の画面で読めるべき内容と、そのために読み込むresourceを書き出すことです。