こんにちは。KUSANAGIの開発チームで取締役をしている相原です。
「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のWebサイトを「KUSANAGI」で運用しています。
この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。
第8回「あなたのWordPressサイトの速度は平均以下？ サーバの応答速度を計測してサイトの健康診断をしよう」ではTTFB（Time To First Byte）がどのようなものでなぜ重要なのか、という話をしました。
今回はTTFBを改善する施策についてお話します。
TTFBのステップを分類
はじめにブラウザからのリクエストに対して最初の1バイトがかえってくるまでのステップをネットワークとサーバ処理の2つに分類します。
ネットワークとサーバ処理では対策の方法が異なるので、分けて考えるとスムーズです。
ネットワークの高速化
次の図はネットワークのリクエストを分解したもので、TTFBはstartTimeからresponseStartまでの時間です。
A diagram of network request phases and their associated timings. web.dev Time to First Byte (TTFB)より
これらのステップを短くすることが高速化の施策です。
複数ページのリダイレクトを避ける
リダイレクトがあると、ブラウザはリダイレクト先のリソースを取得するために再度HTTPリクエストを行います。不要なリダイレクトや複数ページに渡るようなリダイレクトは避けましょう。
トレイリングスラッシュ（URLの最後のスラッシュ）の有無もリダイレクトが発生する場合があるので注意が必要です。
例としてトレイリングスラッシュなしの「https://www.wexal.jp/document」にアクセスしてみましょう。トレイリングスラッシュありの「https://www.wexal.jp/document/」に301リダイレクトしているのがわかります。
トレイリングスラッシュがないため301リダイレクトが行なわれている
このケースでは最初のアクセスの355msが無駄になってしまいました。特にWordPressではPHPが動作してからのリダイレクトになるので表示速度への影響が大きくなります。
外部に紹介するURLにトレイリングスラッシュをつけ忘れると、毎回このリダイレクトが発生してしまうので、表示速度にも影響があるばかりではなく、サーバに不要な負荷をかけることにもなります。
無駄なリダイレクトが発生しないよう、ぜひ運用を見直してみてください。
HTTP/2またはHTTP/3を使用する
HTTP/2はHTTPリクエストを多重化するなど処理性能が向上した通信プロトコルです。2015年にリリースされましたが、HTTPS通信が必須・ブラウザの対応が必要という理由から、なかなか普及が進みませんでした。2021年には50％まで普及が進んでいます。（※1）
また最近では更に高速なHTTP/3も登場しています。2020年時点での普及率が6％程度（※2）と少ないですが、広く利用できるようになることを期待しています。
※1 https://w3techs.com/blog/category/ce-http2
※2 https://w3techs.com/blog/category/ce-http3（※2）
リソースのオリジンへの事前接続
WebページではJSやWebフォントなど様々な外部のリソースを読み込みます。あらかじめそのドメインに接続する可能性があることを伝えることで「DNSの解決」や「TCPのハンドシェイク開始」などのネットワークの接続に必要な時間を短縮することができます。
具体的にはlink要素のrel属性にpreconnectを指定します。
<link rel="preconnect" href="https://example.com">
DNSの解決のみであればdns-prefetchを指定します。
<link rel="dns-prefetch" href="example.com">
リソースそのものを先読みする場合はpreloadを指定します。preloadについてはLCPの高速化で取り上げましたので興味ある方はご覧ください。
<link rel="preload" href="example.png" as="image">
比較的簡単にできる高速化手法ですのでぜひ試してみてください。
ユーザー（閲覧者）との距離
ユーザーとサーバの距離が遠くなると通信にかかる時間が増えます。日本国内であればそれほど気にならないですが、例えば日本のデータセンターにあるWebサイトをアメリカから閲覧しようとすれば距離による遅延は無視できないものになります。
特に
・海外のサーバを利用している
・多言語サイトを展開している
方は対策をすることをおすすめします。
CDNはキャシュしたコンテンツをユーザーから近い距離にあるCDNから配信することで距離的な遅延を防いでくれます
日本国内だけをターゲットにするのであれば国内サーバに切り替えるという方法もありますが、やはりCDNの利用を検討するのがよいでしょう。
代表的なCDNにはAkamai、Fastly、CloudFront、Cloudflareなどがあります。それぞれの機能や予算に合わせて選択してください。
また、CDNで何をキャッシュさせるのかは十分な検討を行なってください。
今回はサーバの応答速度を改善する施策の中からネットワークに関するものを紹介しました。次回はサーバに関する施策を紹介します。
