速さを、記事を公開する流れに組み込む
画像やフォントを記事ごとに手で調整するだけでは、更新のたびに確認が必要になります。このサイトでは配信するファイルの最適化と品質の計測を公開手順へ組み込み、記事が増えても同じ確認を続けられるようにしています。
Delivery & measurement
最初の読み込みと再利用を分ける
ビルド時の最適化、配信時のキャッシュ、変更ごとの計測を組み合わせます。
公開前に整える：必要なファイルを、小さく用意する
ページはAstroで事前にHTMLへ変換し、CSSとJavaScriptを圧縮します。共通CSSはHTMLに含め、見た目を整えるための追加の通信を減らします。閲覧時に記事用のデータベースへ問い合わせる処理はありません。
画像はビルドでサイズ別のWebPを生成し、ブラウザが表示幅や画素密度に合うものを選びます。幅と高さも指定しておき、画像を読み込む前から表示領域を確保します。
コーポレートページ用の日本語フォントは、公開原稿やUIで使う文字を集めて小さくし、自サイトから配信しています。記事一覧と本文には端末標準のフォントを使い、記事を読む際の追加取得を減らしています。
再利用する：更新が届くことと、読み直さないことを両立する
HTMLや固定URLのCSS・JavaScriptは、更新の有無を確認してから取得または再利用します。古い本文や見た目が残り続けるのを避けるためです。
フォントや生成画像には、内容が変わると名前も変わるファイル名を使います。同じURLの内容を差し替えない設計なので、1年間のキャッシュとimmutableを設定できます。変更したファイルだけを新しいURLで取得し、変わらないファイルは長く再利用します。
変更のたびに測る：確認を、作業者の記憶に頼らせない
Pull RequestのCIでは、配信するものと同じ成果物をローカルWorkerで動かし、日英ページをモバイル・PCの条件でそれぞれ3回計測します。Lighthouseの結果は中央値とHTMLレポートを残し、公開前に変更の影響を確認できるようにしています。
これは再現しやすい条件で比較するためのラボ計測です。PageSpeed Insightsでの本番URLの計測や、実際の利用者のデータとは条件が異なります。本番のCDN、端末、回線による差は、別に確認する必要があります。
数字を、読者の体験に置き換えて考える
速さはスコアだけでは判断できません。主要な指標は読んだり操作したりするときの次の体験を確かめる手掛かりです。
- LCPLargest Contentful Paint
- ページの主な画像や文章が表示されるまでの時間。読み始められるまでの待ち時間を確認します。
- INPInteraction to Next Paint
- クリックやタップの後、次の表示が描かれるまでの応答時間。操作に待たされないかを確認します。
- CLSCumulative Layout Shift
- 読み込み中に表示位置がどれだけ動くか。読んでいる文章や押そうとしたボタンがずれないかを確認します。
通常のページ読み込みを測るLighthouseだけで、利用中のINPを確認できるわけではありません。操作の確認や実ユーザーデータと合わせて判断します。
構成図の動きも画面内だけに限定し、停止操作と「動きを減らす」設定に対応しています。解析は本番で同意を得た後に読み込み、問い合わせ・完了ページにはGTMを置きません。速さを整える際も、読む・操作するという目的を損なわないようにしています。
