1秒を切るスタジオサイト：私たちのパフォーマンス予算

ある種のスタジオサイトがあります。スクロールするたびにパララックスがきらめき、フォントが切り替わり、自動再生の映像が3秒間バッファリングし、ホバーするとカーソルに牙が生える。そんなサイトは、ミドルレンジのスマートフォンでは読み込みに8秒かかり、光回線以外のあらゆる接続で壊れているように感じられます。私たちはそういうサイトはつくりません。自らに課すブリーフは、厳しく、シンプルです。Pixel 6aで、帯域を制限した4G回線で、First Contentful Paintを1秒未満に。

このブリーフを満たすのに、英雄的な最適化は必要ありません。必要なのは、積み重なって効いてくる少数のアーキテクチャ上の選択と、それよりずっと多くの「やらないこと」です。この記事では、私たちが守っている予算、その背景にある判断、そして予算が守られたことを示すフィールドでの計測結果を紹介します。スタジオサイト、エージェンシーのサイト、あるいはポートフォリオ型のサイトを公開するなら、これはほぼそのまま流用できる、現実的な目標です。

01数字で見る予算

私たちが公開するスタジオサイトはすべて、Chrome DevToolsのスロットリングでFast 3Gを設定したPixel 6aで、次の数値を目標にしています。実際の4G回線ではもっと速く、Fast 3Gは最悪のケースの下限として使っています。計測にはLighthouseを使い、本番環境ではVercel Analyticsで実ユーザーの指標を取っています。

• Largest Contentful Paint（LCP）：ラボで1.2秒未満、フィールドのp75で1.8秒未満。Googleの「良好」の基準は2.5秒。
• First Contentful Paint（FCP）：ラボで1.0秒未満。
• Cumulative Layout Shift（CLS）：0.05未満。Googleの「良好」の基準は0.1で、私たちはその半分を自らに課しています。
• Interaction to Next Paint（INP）：100ms未満。Googleの「良好」の基準は200ms。
• 初回読み込みの総転送サイズ：HTML、CSS、フォント、JS、ヒーロー画像を含めて、圧縮後150KB未満。
• 初回読み込みのJavaScriptバンドル：圧縮後80KB未満。

ページがこのどれかを満たさなければ、P1のバグとして扱います。「あとで戻ってくるもの」ではなく、サイトを公開する前に直すP1です。

02なぜ、これほど厳しいのか

理由は2つあります。1つ目に、Core Web VitalsはGoogleのランキング要因です。同点のときの決め手ではなく、ランキング要因そのものです。基準を満たすサイトはページエクスペリエンスによる後押しを受けられ、満たさないサイトはわずかな差で不利になります。狭いキーワード群で競うスタジオにとっては、そのわずかな差が重要です。

2つ目に、体感パフォーマンスはブランドのシグナルです。瞬時に表示されるサイトは、有能に見えます。トラッキングピクセルの読み込みで固まるサイトは、そう見えません。「よく考えられた、モダンな仕事をお届けします」を売りにするスタジオなら、サイトが最初の接点でその言葉を証明しなければなりません。サイトそのものが、ブリーフなのです。

03判断1：すべてを静的にレンダリングする

パフォーマンスに関する最大の判断は、レンダリング戦略です。私たちはNext.jsをApp Routerで使い、スタジオサイトのすべてのページをビルド時に静的にレンダリングしています。実行時のデータベース参照はありません。HTMLを配信するエッジ関数以外に、リクエストごとのサーバー処理もありません。サイト全体が、CDN上のファイルです。

具体的に得られるものはこうです。エッジでのTTFBはCDN次第で、地球上のどこでも通常30〜80ms。サーバーレンダリングの構成なら、ブラウザがまだTLSハンドシェイクを終えていないタイミングで、HTMLの最初の1バイトがすでに届いています。その後のすべて、つまり描画も、インタラクションも、次のページも、それだけ早く始まります。

トレードオフは、コンテンツを変更するたびにデプロイが必要になることです。月に一度更新するスタジオサイトなら、デプロイは取るに足らない作業で、Vercelなら90秒で終わります。1時間ごとに更新するメディアなら計算は変わり、ISR（Incremental Static Regeneration）が適切な手段になります。けれど、スタジオサイトが1時間ごとに更新されることはありません。

04判断2：Webフォントは1種類、ウェイトは2つ

カスタムフォントは、最初の描画において、コントロールできる最大のコストです。1ウェイト分のWebフォントのサブセットは、通常、圧縮後25〜40KB。2つのファミリーから3つのウェイトを読み込むサイトは、コンテンツの最初の1バイトが描画される前に150KBのフォントを送ることになります。私たちは1つのファミリーを2つのウェイトで、next/fontによるセルフホストかつハッシュ付きの配信で提供しています。Google Fontsへのサードパーティリクエストも、フォントCDNへのDNSルックアップもありません。

その代償も受け入れています。イタリックも、細字も、極太もありません。タイポグラフィ上の区別はすべて、サイズ、色、字間、あるいは手元の2つのウェイトのコントラストでつけなければなりません。これは十分に元が取れるクリエイティブな制約です。8つのウェイトを必要とするサイトは、弱い階層構造をタイポグラフィの多彩さで覆い隠しがちです。2つのウェイトで成り立つサイトは、構造そのもので階層を勝ち取らなければなりません。

05判断3：ヒーロー画像の予算と、その使い方

スタジオサイトでは、LCPはほぼ必ずヒーローです。つまりLCPの予算は、ヒーローの予算です。私たちはヒーローに厳格な上限を設けています。デスクトップのブレークポイントで圧縮後80KB、モバイルで40KB。それを超えるなら、予算を使いすぎる言い訳にするのではなく、画像の選び方や処理で解決すべきクリエイティブな課題として扱います。

予算内に収めるための、4つの実践です。

1. 1対応環境ではAVIFを使い、フォールバックにWebPを用意する。AVIFは同等の画質で、WebPより通常30〜40%小さくなります。
2. 2next/imageコンポーネントでレスポンシブなサイズを配信する。スマートフォンがデスクトップ用のヒーロー画像をダウンロードすることはなく、デスクトップも、画面が本当にRetinaでない限り2倍解像度の版はダウンロードしません。
3. 3すべての画像に幅と高さを明示する。これがレイアウトシフトを防ぎます。画像が届く前に、ブラウザが正しいピクセル数の領域を確保するからです。
4. 4ヒーロー画像をプリロードする。head内に<link rel="preload" as="image" href="…"/>を入れます。コストは1行だけで、LCPを200〜400ms短縮できます。ブラウザがページの残りを解析する前に、画像のリクエストを始めるからです。

06判断4：JavaScriptは最後の手段

JavaScriptは1KBごとに、ページが操作可能になる前に、メインスレッドでダウンロードされ、解析され、実行されなければなりません。私たちはJSの予算を希少なものとして扱い、2つのルールを守っています。

• デフォルトはServer Components。コンポーネントに'use client'を付けるのは、本当にインタラクティブ性が必要な場合だけ。React Server Componentsのデフォルトは、コンテンツ中心のサイトにとって正しいデフォルトです。
• 初回読み込みにサードパーティスクリプトは入れない。80KBものベンダーコードを送り込む分析ツールも、タグマネージャーも使いません。分析は、ページが操作可能になってから遅延して動かします。私たちが使っているVercel Analyticsは、約1KBです。

スタジオサイトに課している予算は、初回読み込みで圧縮後80KB未満のJS。その大半はReact自体です。インタラクティブな層（ナビゲーションメニュー、言語切り替え、お問い合わせフォーム）は、数KBにすぎません。

07判断5：レイアウトシフトのバグを生まないCSS設計

Cumulative Layout Shiftは、Core Web Vitalsの中で最もうっかり基準を外しやすく、そして意図すれば最も直しやすい指標です。CLSをほぼゼロに保つ、4つの習慣です。

1. 1遅れて届くものすべてに、場所を確保する。画像、フォント、iframe、広告。すべてに、寸法を明示したアスペクト比のコンテナを用意します。
2. 2フォントの読み込みに依存するCSSを避ける。切り替わるまでの間は、font-display: swapでシステムフォントのフォールバックを使います。Webフォントとメトリクスが近いフォールバックを選べば、切り替えは目に見えません。
3. 3読み込み後に、ファーストビューへコンテンツを差し込まない。最初の描画のあとに現れるバナー、Cookieの通知、お知らせバーは、起こるべくして起こるレイアウトシフトです。必要なら、最初のHTMLでレンダリングしておき、アニメーションで表示させます。
4. 4遅いネットワークでテストする。光回線では見えないCLSの問題も、3Gでは現れます。遅れて届くリソースが、そこでは最も遅れて届くからです。

08判断6：アニメーションの予算

動きを抑えることは、それ自体がパフォーマンスの最適化です。メインスレッドで動くアニメーションはどれも、INPを悪化させるリスクをはらみます。クリック時にカクつく250msのアニメーションがひとつあるだけで、サイト全体がINPの「良好」の枠から押し出されてしまいます。私たちのルールは次のとおりです。

• アニメーションさせるのはtransformとopacityだけ。どちらもGPUで合成され、レイアウトを発生させません。
• 表示アニメーションはJavaScriptではなくCSSで。IntersectionObserverでclassNameを付け加えるだけで、実際のアニメーションはtransitionです。
• スクロール連動のアニメーションは使わない。聞こえはエレガントでも、ミドルレンジの端末ではひどいスクロール性能になります。
• ヒーローで動画を自動再生しない。動画が必要なら、ファーストビューより下で遅延読み込みするか、ユーザーの操作をきっかけに再生します。

09判断7：アクセシビリティとパフォーマンスの重なり

アクセシビリティの改善の多くは、パフォーマンスの改善でもあります。セマンティックなHTMLは、divだらけのマークアップより小さくなります。ブラウザ標準のフォーカスリングは、JSによる独自のフォーカス管理より速く描画されます。スキップリンクを備えたヘッダーがあれば、JavaScriptを送り込むキーボードトラップの修正は不要になります。私たちはまずアクセシビリティを前提に設計・構築し、パフォーマンスは自然とついてきます。

パフォーマンスとアクセシビリティがぶつかる唯一の場所が、アニメーションです。動きを必要とするユーザーもいれば、動きで気分が悪くなるユーザーもいます。私たちはprefers-reduced-motionを尊重し、すべての表示アニメーションに、移動ではなくフェードによるフォールバックを用意しています。

10本番環境での計測

Lighthouseによるラボの指標は必要ですが、それだけでは足りません。最も信頼できるのは、リアルユーザーモニタリング（RUM）、つまり実際の端末を使う実際の訪問者の体験です。Web Vitalsの計測にはVercel Analyticsを使っています。プラットフォームに無料で付いてきて、フィールドの指標をルート、端末、地域ごとに分けて報告してくれるからです。

毎週確認しているのは、次の項目です。

• ルートごとのp75 LCP。p75が1.8秒を超えるルートがあれば、調査します。
• INPの悪化。INPは最も油断ならない指標で、JavaScriptが増えるにつれて静かに悪化することがあります。
• ルートごとのCLS。CLSの悪化は、たいてい遅れて読み込まれる要素ひとつにたどり着きます。
• ルートごとの初回読み込みJS。CIのバンドルアナライザーで追跡し、予算を超えたビルドは失敗させます。

11やらないこと

同じくらい大切なのが、業界標準であるにもかかわらず、あえて取り入れていないものです。

• 小規模なサイトでは、SPA方式のクライアントサイドルーティングを使わない。4G回線では、バンドルの差分よりドキュメント全体を取得するほうが速いからです。ナビゲーションはブラウザに任せます。
• Service Workerは使わない。10ページに満たないサイトでは、その複雑さに見合いません。
• 30KBのSDKを差し込む画像ホスティングサービスは使わない。画像はビルド時に最適化し、サイトと同じドメインから配信します。
• 「スマート」な遅延読み込みライブラリは使わない。ネイティブのloading="lazy"属性なら、0KBで同じ仕事をこなします。
• ホバーしたリンクをすべてプリフェッチすることはしない。Next.jsは本番環境でデフォルトでプリフェッチするので、それを有効にしたまま、判断はフレームワークに任せます。

サイトを計画中で、現在のサイトのパフォーマンス監査をご希望の方、あるいは最初からこの予算でサイトを構築したい方は、hello@neptay.comまでご連絡ください。