preconnectは必要な外部domainだけへ指定し広告やfontの読込先を確認する

preconnectは、pageで必要になる外部domainへ先に接続するようbrowserへ伝えるlink relationです。外部font、画像CDN、広告scriptなどを使うpageで候補になります。ただし、外部domainを見つけるたびに追加しません。実際に読込むものだけを確認して指定します。

W3CのResource Hintsは、preconnectを必要なresourceを取得するoriginへ早期接続するためのrelationとして定義しています。DNS lookup、TCP handshake、必要ならTLS negotiationを前もって始めることで、接続にかかる待ち時間を隠せる場合があります。一方で、hintの実行はuser agentの状況によって決まり、必ず実行されるわけではありません。

ここでいうoriginは、単に見た目が同じserviceかどうかでは決まりません。protocol、host、portが違えば、browserは別の接続先として扱います。site本体と画像配信先、fontのstylesheetを置く先とfont fileを置く先も、URLを実際に見なければ同じ接続先か判断できません。広告tagのscriptを一つ置いたからといって、広告表示に関係するすべてのdomainへ先回りする必要があるわけでもありません。

先に減らすべきなのは、不要な外部読込みです。pageを開いた直後に使わないwidget、利用していないfont、古い解析tagが残っているなら、hintを増やすより読込み自体を外す方が判断しやすくなります。外部serviceを使うことと、最初の表示時に接続を始めることは別です。誰がそのserviceを入れ、いつ必要になるかを確かめてから、connectionを先に作るか決めます。

preconnectとdns-prefetchは対象が違う

たとえば外部fontを最初の見出しで使うなら、その配信元は候補になります。問い合わせformを開いたあとだけ使う外部serviceなら、最初のpage表示で接続する必要があるかを考えます。

dns-prefetchは名前解決を先に行うためのhintです。接続まで準備するpreconnectより小さい判断で済みますが、どちらも使う予定のないdomainへ付けるものではありません。接続の準備まで行いたい理由が説明できないなら、まず読み込むURLと表示順を確認します。relationの名称だけで速そうな方を選ばないことが大切です。

同じdomainへ両方を置けば、二種類の指定をした分だけ効果が増すとは限りません。preconnectを検討するなら、そのoriginについて名前解決だけでなく接続準備まで行いたい理由を残します。theme fileへ記述する人と、広告やfontを管理する人が違う場合は、URL、使うpage、必要になる時点を共有します。後から不要なhintを外せるようにするためです。

設定前に外部domainを一覧にする

resource hintは、URLを一つ足せば必ず速くなる魔法ではありません。不要な接続を増やせば、利用者のnetworkやbrowserの処理を使います。theme、plugin、広告tagがどのdomainへ読込みを出すかを先に調べます。

一覧を作るときは、管理画面の設定名だけで済ませません。たとえば「解析」「広告」「font」という名前では、どのpageでどのURLを読むのかが分かりません。domainごとに、読み込むresource、読み込むpage、最初の表示で必要か、管理している人、削除できる条件を書きます。広告scriptがheaderにあっても、広告枠を置かないpageで同じ接続が必要かは別に確認します。

代表pageも一枚だけ選びません。トップpage、記事page、問い合わせpageのように、読み込むものが異なるpageを比べます。トップだけで使うsliderの画像配信先を、全page共通のhintにしてしまうと、関係のないpageでも接続準備を行います。共通headerに記述するのか、特定templateだけへ記述するのかは、一覧で利用範囲を見てから決めます。

1. 代表pageを開き、外部から読み込むfont、画像、scriptを記録する。
2. 最初の表示で必要なものと、操作後に必要なものを分ける。
3. 最初に必要なoriginだけをpreconnectの候補にする。
4. 追加後に同じpageを開き、外部resourceが正しく読めるかを確認する。
5. themeやpluginを更新したら、domain一覧も見直す。

広告やアクセス解析を外部へ頼む場合も、scriptを追加する人とpageの表示を確認する人を分けないでください。tagを入れたことで新しいdomainへの接続が増えても、誰も把握していなければ後で直せません。

追加する位置も確認します。browserがhintを読むのが遅ければ、早めに接続する目的が薄れます。headerへ書くか、特定pageのheadへ書くかは、最初に必要になるresourceとtemplateの構成で決めます。本文の末尾にscriptを置くためだけのserviceなら、headで先に接続する理由を説明できるか考えます。codeを共通fileへ足すときは、個別pageでしか使わないoriginまで全pageへ広がらないかを見ます。

変更後は、表示が壊れていないことだけで完了にしません。外部fontが読めなくなっていないか、画像CDNのURLが誤っていないか、広告や解析のscriptが二重に入っていないかを確認します。表示速度を比べるなら、同じpage、同じ状態で、hintを入れる前後を見ます。閲覧環境や読み込む広告が変われば、ひとつの数字だけで判断しにくくなります。何を減らしたいのかを決めてから比較します。

resource hintを表示速度の保証にしない

preconnectはbrowserへ判断材料を渡す仕組みです。画像が重い、scriptが多い、serverの応答が遅いといった問題まで解決するものではありません。どの待ち時間を減らしたいかを決めずに足しても、成果を比較できません。

たとえば最初の見出しが外部fontを待つために読めないのか、本文画像が大きすぎて表示が遅いのか、広告scriptがpageの操作を止めるのかでは、調べる場所が違います。fontの接続を先にしても画像fileの大きさは変わりません。広告用のoriginへ接続しても、themeのscriptが多すぎる問題は残ります。resource hintを使う判断は、待ち時間の原因を一つに分けた後で行います。

外部domainは、serviceを解約したときやpluginを外したときにも見直します。使わないhintが残っていると、次にpageを調べる人は今も必要な接続だと受け取ります。設定を外した日、外したservice、headから消したrelationを記録しておけば、不要な読み込みを戻す作業を避けられます。表示速度のための小さな設定ほど、誰が管理するかを曖昧にしない方がよいです。

最初の一手は、トップpageで最初に必要な外部domainを三つ以下へ絞って書き出すことです。そのdomainが本当に必要かを確かめてから、hintを検討します。