サイトの表示速度をlinkタグの「rel="preconnect"」で上げる／WebPagetestで事前接続を調べる

HTMLのリソースヒント（日本語訳）に載っているlinkタグの「rel="preconnect"」がサイトの表示速度を上げるのに役立つと知ってブログに取り入れたんだ。

速くなるのは確かながらほんの僅かで、体感上、殆ど変わらないようだけど、しかしブラウザの外部ファイルの読み込みを効率化できるので、訪問者が以前よりも安定して閲覧できるかも知れないから外すには至らない。

Luminescence of cars running on a dark road by Mateusz Dach [CC0], via Pexels

リソースヒントのpreconnectの仕組み

リンク関係型 preconnect は、［要求されるリソースを fetch するために利用することになる生成元］を指示するために利用される。［ DNS 検索, TCP ハンドシェイク, TLS 折衝（任意選択）］も含む，接続を早期に起動しておけば、 UA は，接続を確立する際の高い遅延コストを覆い隠せるようになる。

Resource Hints（日本語訳） via ウェブ関連仕様日本語訳

preconnectを使うとブラウザが外部ファイルを読み込む際に事前接続を完全に行うように指定できる。

DNSルックアップ（名前解決）
TCPハンドシェイク（応答確認）
TLSネゴシエーション（通信交渉）

※TLSネゴシエーションはオプション（任意選択）だからいつも必要とはかぎらない。

サイトのhead内にpreconnectのlinkタグを記載して事前接続の三つのプロセスを全て完了しておくとブラウザは指定された外部ファイルが必要なところから直ぐに読み込んで画面に表示するためのレンダリングも速やかに可能になるから表示速度が上がるわけなんだ。

linkタグの「rel="preconnect"」の記述法

<link href="外部ファイルのルートかサブドメイン" rel="preconnect">

事前接続を行うので、サイトの内部ファイルを指定しても最初に閲覧した時点で済んでいるから意味はない。

linkタグの「rel="preconnect"」を使うのは専ら外部ファイルを参照する必要がある場合にかぎられる。

href属性の指定先のURLは外部ファイルのルートドメインかサブドメインを対象にして記述する。外部ファイルのコンテンツを読み込むわけではないので、サイトから参照するURLが実際にディレクトリー以下を含んでいるとしても省略して構わない。

外部ファイルの状況によってlinkタグの「pre="connect"」はそのままでは動作しないから注意しなくてはならない。

セキュリティ上の理由から、ブラウザーは、スクリプトによって開始されるオリジン間 HTTP 要求を制限しています。例えば、 XMLHttpRequest や Fetch API は同一オリジンポリシー（same-origin policy）に従います。つまり、これらの API を使用するウェブアプリケーションは、そのアプリケーションが読み込まれたのと同じオリジンからのみ HTTP リソースの要求を行うことができ、それ以外のオリジンからの場合は正しい CORS ヘッダーを含んでいることが必要です。

オリジン間リソース共有（CORS） via MDN Web Docs

スクリプトから二次的に要求される外部ファイルかどうか。例えばGoogle FontsのEarly access（Webフォント）を使うような場合に一つのドメイン：fonts.googleapis.comは大丈夫だけれどももう一つのドメイン：fonts.gstatic.comがオリジン間リソース共有で止められてしまう。そのままでは無理だけれどもlinkタグの「pre="connect"」にcrossorigin属性を追加すれば動作するようになる。

<link href="外部ファイルのルートかサブドメイン" rel="preconnect" crossorigin>

crossoriginの値なしの記述はanonymous（匿名）の値を持つ。正確な記述では「crossorigin="anonymous"」と同じ状態になっている。crossoriginの値は他にもuse-credentials（証明書を使用）があるので、外部ファイルの設定によって使い分ける。

指定先の外部ファイルのドメインの入力は「//」から始めても構わない。すなわち「href="//example.com"」のように記述できる。ドメインのhttpヘッダーがhttpでもhttpsでも通用するから便利だし、ソースコードが短くなるだけサイトの容量が減るから表示速度も上がる。

サイトの表示速度を上げ易くする条件

外部ファイルが必要になるよりも先に動かなくては事前接続の利点がないので、linkタグの「rel="preconnect"」はなるべくソースコードの冒頭に置く。そして対象となる外部ファイルを引き離して後ろの方へ置く、または二つの間にCSSなどの他のソースコードが多めに挿入されるようにしておくと良いと思う。

最低限、ブラウザでlinkタグの「rel="preconnect"」の事前接続が終わってから必要な外部ファイルが読み込まれる形にソースコードを記載する順番だけは守らないとサイトの表示速度を上げるには意味がなくなってしまう。

linkタグの「rel="preconnect"」は幾つも使うとファーストビュー（最初の画面）を遅らせる可能性がある。当該の事前接続に時間を取られ過ぎると全体的にサイトの表示速度は速くなるとしても代わりにブラウザが画面を出し難くなって訪問者の体感速度が下がるかも知れない。いい換えるとロード時間の短縮に対してファーストビューの遅延が発生しないようにlinkタグの「rel="preconnect"」の数は適切に調節するべきなんだ。幾つも使わず、増やし過ぎないのが大事だと考える。

WebPagetestで事前接続を調べる方法

Waterfall View via WebPagetest

サイトにlinkタグの「rel="preconnect"」を指定する外部ファイルはサイトか外部ファイルのソースコードから分かって選べるけど、しかしWebPagetestで調べるとサイトの読み込み時間をコード毎に明瞭に把握できるから良いと思う。crossorigin属性がないと駄目だったり、総じてコード自体が正しく記載されているかどうか、実際の動作状況を通じて確認するのにも役立つ。

WebPagetestは無料のサービスでアカウントの登録も求められないから気軽に使えるし、現時点、 Googleがサイトの表示速度を計測するツールのTest My Siteに搭載していたり、ウェブの高速化の取り組み（Analyze and optimize your website with PageSpeed tools）から支援しているらしくて信頼性も高そうだ。

機能が非常に豊富だけれども基本的に調査したいサイトのURLを入力して実行すればテスト結果からサイトの表示速度や関連するソースコードの諸々の読み込み時間のデータが手に入る。

WebPagetestの通常の入力画面の日本語訳

Test a website's performance via WebPagetest

Enter a Website URL

ウェブサイトのURLを入力

Test Location

テスト地域

日本ならば「Tokyo, Japan」（日本の東京）

Browser

ブラウザ

Connection

接続

スマホならば「3G」や「4G」など

Number of Tests to Run

テストの回数／一度に九回まで

Repeat View

繰り返し閲覧

First View and Repeat View（一回目と繰り返し）
First View Only（一回目だけ）

Capture Video

動画を取り込む

Keep Test Private

自分だけがテストを知る／結果を一般公開しない

Label

ラベル（Test History：テスト履歴で複数の結果を纏める）

通常の画面で所定の項目を入力して右側の「START TEST」のボタンを押すとテストが開始されて画面が切り替わる。Waitingと TestingとDone（待機とテストとやった）の三段階で長くても数分で完了する。するとWalterfall（ウォーターフォール：数値の推移を示した棒グラフ）の画像がScreen Shot（スクリーンショット）と共に出て来る。押すとそれぞれに全体を確認できる。

Walterfallの画像から入ってWalterfall View（ウォーターフォールビュー）でも分かるけれども下のConnection View（コネクションビュー）にサイトの接続状況のデータが集められている。

Waterfall Viewで黄色の帯文字が付くのはリダイレクトのURLで、赤色の帯文字が付くのはエラーのURLで、何れもサイトの表示速度を下げる要因だからなるべく修正しておきたい（外部ファイルの問題ならば使わうのを止める以外に直接は改善できないかも知れない）。