Server-Timingはホームページの遅さをブラウザーとserverのどちらで待たせたか分けて調べる

ホームページが遅いとき、画像やJavaScriptだけを疑うと、serverの処理で待たせている時間を見落とす。Server-Timingは、serverがrequestを処理する間に何へ時間を使ったかをHTTP response headerでbrowserへ伝える仕組みである。使うなら、数字を増やす前に、読者が待つpageを一つ選び、調べたい処理と、数字を見て決めることを先に定める。

Chromium Blogは2月8日、Chrome 65 BetaでServer Timing APIを案内した。Navigation TimingやResource Timingでは、documentやresourceを取得する時間を見られるが、serverがresponseを返すまでの内訳は分からない。Server-Timingは、web serverがHTTP headerへperformance情報を入れ、Chrome Developer Toolsで確認できるようにする。headerを付けただけでpageが速くなるわけではない。遅い場所を、画面の処理とserverの処理に分けて調べるための材料になる。

読者の待ち時間とserverの内訳は別の数字である

browserでpageが表示されるまでには、通信の接続、serverの処理、HTMLの受信、CSSやimageやscriptの取得、画面への描画など、いくつもの時間が重なる。画面が遅いという結果だけでは、どの作業が原因かを決められない。imageを小さくしても、databaseから記事を取り出す処理が長ければ、最初のHTMLを返すまでの待ち時間は残る。

Server-Timingが扱うのは、server側から渡す時間の情報である。たとえば、pageを作る処理、databaseへの問い合わせ、cacheから読み出す処理などへ、短い名前と時間を付けられる。browserが測る総時間と同じ数字をもう一度出すためのものではない。総時間が長い理由を、server側のどこまで見られるかに使う。

仮に、問い合わせpageを開くまでに時間がかかるとする。Developer Toolsでnetworkを見て、最初のdocumentを受け取るまでに長く待っているなら、server側の処理を疑う理由がある。そこで、templateを組み立てる処理とdatabaseを読む処理に別の指標を付ければ、どちらに時間が寄っているかを見られる。反対に、documentは早く返るのに、画像や外部scriptで待つなら、Server-Timingの数字だけを直しても、読者の画面は速くならない。

数字を一つにまとめると、原因の違う遅さを同じ対策で直そうとしてしまう。最初に、読者が待つ画面の時間、serverが返答を作る時間、browserが追加で読むresourceの時間を別に置く。これだけで、制作側へ伝える質問も変わる。

指標名は担当者だけが分かる暗号にしない

Server-Timing headerには、server側で決めた指標名と時間を入れられる。自由に名前を付けられるため、最初に名前を増やしすぎると、後から数字を見ても何を表すか分からなくなる。略語だけの指標を並べるより、少数でも処理の役割が分かる名前にする。

たとえば、記事pageの調査なら、全体のpage生成、記事dataの取得、関連する一覧の取得の三つから始められる。最初からtheme、plugin、table、外部serviceごとに細かく分ける必要はない。全体の時間が長いことを確認してから、次の測定で内訳を増やす。一度に細かくすると、比較する数字の数だけが増え、読者に影響する問題を見失う。

同じ名前を使い続けることも重要である。今月は db を記事dataの取得、翌月は画像の一覧取得という意味で使えば、過去の記録と比べられない。指標名、測る範囲、単位を短く文書に残す。制作を外へ頼む場合は、headerを付ける人だけでなく、その数字を確認する人にも意味が分かる状態で引き渡してもらう。

headerへ入れる説明にも注意がいる。Server-Timingはbrowserへ送るresponseの一部である。顧客名、入力内容、管理画面のURL、server内部の細かい構成を、原因調査のためにそのまま出さない。必要なのは、処理を見分ける短い名前と時間である。公開してよい情報と、運用者だけが見る記録を分ける。

まず一つのpageで変更前と後を比べる

測定を始めるpageは、site全体から選ばない。検索や広告から最初に開くservice page、問い合わせpage、商品一覧のように、読者が待つと用件を進めにくいURLを一つ選ぶ。対象URL、測定日時、操作した条件を記録してから、同じpageを複数回開く。

最初に確認するのは、Server-Timingの各数字を足して、画面の表示時間と一致するかではない。networkにかかる時間には、通信やbrowserのresource取得も含まれるため、単純に足しても同じにならない。ここでは、同じ条件で開いたときに、server側のどの処理が相対的に長いかを見る。

たとえば、記事dataの取得が長いという記録が続くなら、databaseのquery、cacheの使い方、表示のために読み出しているdataの量を調べる候補になる。page生成が長く、data取得は短いなら、template処理やpluginの処理を確認する候補になる。どちらの場合も、すぐにcacheを足したりpluginを止めたりしない。何を替えると、どの数字が変わるはずかを一つ決めてから作業する。

変更後は同じURLを開き、server側の数字だけでなく、本文、image、menu、問い合わせformも確認する。処理時間が短くなっても、関連情報が消えたり、formを送れなくなったりすれば、読者にとっては改善にならない。速さのために残すべき案内を削らないよう、画面の確認を測定と同じ作業にする。

headerを使えない環境では測定の目的を残す

Chrome 65 Betaで案内された機能であるため、すべてのbrowserやhosting環境で同じように確認できるとは限らない。serverの設定へ手を入れられない場合もある。そのときに、Server-Timingを使えないから調査をやめる必要はない。遅いURL、読者が待つ場面、serverへrequestが届いてからresponseを返すまでに確認したい処理を、先に記録する。

その記録があれば、hosting会社や制作者へ相談するときも、単に「siteが遅い」と伝えるより話が進む。どのURLを、いつ、どの画面で見て遅いと感じたか。HTMLを返す前の処理を見られるか。変更した後にどの画面と数字を確かめるか。これらを渡せば、Server-Timingを使うか、serverのlogや別の監視方法を使うかを、目的に合わせて選べる。

Server-Timingは、速さを示す新しいscoreではない。browserの画面に見える遅さと、serverがresponseを作る時間を分けて、次に直す場所を決めるためのheaderである。まず読者が待つURLを一つ選び、少数の指標で原因を分け、変更後は画面と用件の入口まで確認する。この順で使えば、数値を集めるだけの測定にならない。