結婚式場のフェア予約ページの表示速度を、Core Web Vitals（INP・LCP・CLS）で直す手順。スクリプト・フォント・外部タグ・フォームのJS

この記事の結論：結婚式場のフェア予約ページの表示速度は、写真よりも「後から動く部品」で遅くなることが多く、Core Web Vitals の3つの指標（INP・LCP・CLS）で原因を切り分けて直します。手順は、①Search Console と PSI（Google の速度診断ページ）で実際の利用者の数値を見る、②悪い指標を、カレンダーやフォームの JavaScript、和文の Web フォント、計測やチャットなどの外部タグのどれが起こしているか調べる、③日付を押してから反応するまで（INP）は処理の分割で、最初の表示（LCP）はフォントとタグの読み込み順で、画面のずれ（CLS）は場所の確保で直す、④直したら実機のスマホで予約を1件送り、計測が切れていないか確かめる、の4段です。

この記事は、式場の Web 担当者と、フェア予約ページを作る制作会社・開発者に向けた作業の手順です。写真の形式やサイズの整え方は結婚式場サイトの写真を速く見せる記事で扱ったので、ここでは画像以外の部品に絞ります。根拠にしたのは web.dev、検索セントラル、Search Console の公式ヘルプで、どれも2026年10月2日に読み直しています。どこかの式場の実例を書いたものではありません。

フェア予約ページを遅くしているのは、写真より後から動く部品

フェア予約ページで遅さの原因になりやすいのは、ページを開いたあとに読み込まれて動き出す部品です。部品ごとに、悪くしやすい指標が違います。

どれも、1つずつなら小さな負担です。問題は、フェアの集客のたびに道具が足され、誰も全体を見ていない状態になることです。まず、今のページに何が載っているかを数えるところから始めます。

INP・LCP・CLS の目安と、フェア予約ページで悪くなる場面

3つの指標の「良好」の目安は、INP が200ミリ秒以下、LCP が2.5秒以下、CLS が0.1以下で、どれも読み込み全体のうち75パーセンタイルにあたる値で判定します。INP は、2024年3月12日に FID に代わって Core Web Vitals に入った指標です。

INP の対象になる操作は、クリック、タップ、キーボードの入力の3種類で、スクロールや拡大は含まれません。フェア予約ページでは、日付を選ぶ、時間帯を選ぶ、名前を入力する、という操作がそのまま INP に入ります。

測る順番は、実際の利用者の数値から始めて、手元で再現する

測るときは、実際の利用者の数値（フィールドデータ）で悪い指標を見つけ、そのあと手元のブラウザで再現して原因を探します。試験環境の点数だけを見て直すと、利用者が困っていない所に時間を使うことがあります。

1. Search Console 内の Core Web Vitals レポート：実際の利用者のデータ（CrUX）をもとに、似たページをまとめて「良好」「改善が必要」「不良」を出す。フェアの詳細ページがまとめてどこに入っているかを見る
2. PSI（pagespeed.web.dev）：フェアの一覧や詳細の URL を1つ入れ、上段の実際の利用者のデータと、下段の試験環境の診断を分けて読む
3. Chrome の DevTools の Performance パネル：スマホに近い速さに落として、日付を押す・入力するなどの操作を記録し、どの処理が長く動いているかを見る

アクセスが少ないページは、利用者のデータが足りず、Search Console に「データがありません」と出ることがあります。その場合はサイト全体のまとまりで見るか、次のように自分のサイトで INP を集めます。

試験環境の診断（Lighthouse）は、操作をしないので INP を直接は測れません。代わりに、読み込み中にメインの処理がふさがっていた時間（TBT）が手がかりになります。実際の利用者の INP と、どの部品で遅れたかを知りたい場合は、Google が公開している web-vitals ライブラリの attribution 版を使い、計測のタグへ送ります。

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'web_vitals_inp',
    inp_value: Math.round(value),
    inp_rating: rating,
    // どの要素を押したときに遅かったか（例：カレンダーの日付のボタン）
    inp_target: attribution.interactionTarget,
    // 入力の遅れ・処理・描画のどこで時間がかかったか
    inp_input_delay: Math.round(attribution.inputDelay),
    inp_processing: Math.round(attribution.processingDuration),
    inp_presentation: Math.round(attribution.presentationDelay),
  });
});

送った値は、GA4 ならイベントのパラメータとして集計できます（カスタム定義の登録が必要です）。遅かった要素がカレンダーの日付なのか、送信のボタンなのかが分かると、直す場所がはっきりします。

INP：日付を押してから反応するまでを、処理の分割で短くする

INP を短くする基本は、操作に対する見た目の変化を先に描き、重い処理はそのあとに回すことです。web.dev は、INP を「入力の遅れ」「処理の時間」「描画の遅れ」の3つに分け、それぞれを減らす方法を示しています。

処理を区切るには、長い処理の途中でブラウザに順番を返します（web.dev では yield と呼んでいます）。対応していないブラウザ向けに、setTimeout で代わりをする形にしておきます。

// ブラウザに一度順番を返す。scheduler.yield がなければ setTimeout で代用する
function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function onDateClick(button, date) {
  // 1. 押したことが分かる見た目だけを先に変える
  markSelected(button);
  showSlotsLoading();
  await yieldToMain();

  // 2. 空き枠を取りに行き、選んだ日の時間帯だけを描く
  const slots = await fetchSlots(date);
  renderSlots(slots);
}

フォームの入力チェックも同じ考え方です。1文字ごとに全項目を検査するのではなく、入力が終わったとき（欄から離れたとき）にその欄だけを検査します。電話番号の形を整える処理も、打っている最中ではなく欄を離れたときに行えば、入力の反応が遅れません。

外部タグ：中身を棚卸しして、読み込む時機をページと役割で分ける

外部タグは、「どのページで要るか」と「ページを開いた直後に要るか」の2つで仕分けます。web.dev も、外部の JavaScript は使っていないものを外し、async や defer で HTML の解析を止めないように読み込み、表示に関係ないものは後で読み込むよう勧めています。

タグを GTM（Google のタグ管理の道具）に集めているなら、トリガーの種類（ページビュー、DOM Ready、ウィンドウの読み込み、クリックなど）で、動き出す時機を分けられます。

チャットや埋め込みのように「押されるまで本体を読まない」作り方は、Chrome の開発者向け資料でファサード（本物に似せた、動かない代わりの表示）として紹介されています。フェア予約ページでは、チャットの窓の本体が日付カレンダーの操作と同じ時間帯に動かないだけで、入力の遅れが減ることがあります。

棚卸しのときは、GTM のコンテナの中身を一覧にして、タグごとに「誰が、何のために入れたか」「今も見ている人がいるか」を書き込みます。広告の媒体を替えたあとに古いタグが残っていることは珍しくありません。

フォント：和文の Web フォントは見出しだけにし、サブセットと表示の方針を決める

和文の Web フォントは、文字の数が多いぶんファイルが大きくなり、最初の表示（LCP）を遅らせ、読み込み後の切り替えで画面のずれ（CLS）も起こします。フェア予約ページでは、Web フォントは見出しだけに使い、本文とフォームは端末のフォントにするのが手堅い分け方です。

web.dev のフォントの手引きに沿って、次の5つを決めます。

1. 使う場所を絞る：式場らしさを出す明朝体は、ページの見出しとフェアの名前だけにする。入力欄とボタンは端末のフォントにする
2. 形式とサブセット：WOFF2 にし、見出しに使う文字だけに絞ったファイル（サブセット）を作る。フェアの名前を入れ替えたら、サブセットを作り直す手順を残す
3. 接続の準備：フォントを外部の配信元から読む場合は、preconnect で先に接続を始める。preload は他の読み込みを押しのけるので、最初の画面で必ず使う1種類だけにする
4. 表示の方針：font-display: swap は文字をすぐ出して後で差し替える。optional は間に合わなければ端末のフォントのままにし、ずれを起こさない。フェア予約ページは、ずれを避けたいので optional を候補にする
5. 代わりのフォントの寸法を合わせる：size-adjust などで端末のフォントの大きさを Web フォントに寄せ、差し替わったときのずれを小さくする

@font-face {
  font-family: "VenueMincho";
  src: url("/fonts/venue-mincho-subset.woff2") format("woff2");
  font-display: optional;
}
h1, .fair-title {
  font-family: "VenueMincho", "Hiragino Mincho ProN", "Yu Mincho", serif;
}
input, select, textarea, button {
  font-family: system-ui, sans-serif;
}

CLS：空き枠の表示、エラー文、後から出る帯で画面をずらさない

CLS を小さくするには、後から中身が入る場所の大きさを、先に確保しておきます。web.dev では、サイズを指定していない画像や埋め込み、後から差し込まれる内容、Web フォントを主な原因に挙げ、min-height や aspect-ratio で場所を確保するよう勧めています。

フェア予約ページで起きやすいずれと、直し方は次のとおりです。

なお、操作をしてから500ミリ秒以内に起きたずれは、CLS の計算から除かれます。日付を押して時間帯の一覧が開くのは利用者が期待している動きなので、すぐに開けば CLS には入りません。問題になるのは、空き枠の取得が遅く、押してから時間がたってから一覧が開いて画面が動く場合です。

直したあとに確かめること：速さより先に、予約が最後まで届くか

速さの改善で外部タグやスクリプトの読み込み方を変えると、予約の送信完了のイベントが送られなくなったり、フォームの検査が動かなくなったりすることがあります。公開の前に、次の順で確かめます。

1. 実機のスマホで、フェアの一覧から予約の送信完了まで通す：日付と時間帯を選び、入力し、送信して完了の画面が出るまで
2. 予約した人と式場の両方に、確認のメールが届いたか
3. 計測が届いたか：GA4 のリアルタイムやデバッグの画面で、送信完了のイベントが1件だけ届いたか（遅らせたタグで二重や欠落がないか）
4. PSI で、直したページを測り直す：試験環境の診断で、長い処理やずれの原因が消えたか
5. Search Console で修正を検証する：Core Web Vitals レポートで「修正を検証」を始めると、28日間の観察が始まる。利用者のデータに反映されるまで時間がかかるので、結果は週ごとに見る

株式会社bundlyzeでは、ブライダルに限らず多業種で使う予約管理のシステムを、企画の立ち上げから運用の段階まで手がけてきました。予約の画面は、速さとあわせて「満席の枠を選ばせない」「確認のメールを確実に届ける」まで含めて作る必要があります。フェア予約ページを含めた式場サイトの作り直しや改善の進め方は、Webサイト制作のサービスのページをご覧ください。

出典（web.dev・検索セントラル・Search Console の公式ヘルプ／2026年10月2日に確認）

• Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」：LCP・INP・CLS の目安と、検索での扱い
• web.dev「Interaction to Next Paint（INP）」：INP の目安（200ミリ秒以下）、対象になる操作
• web.dev「3 月 12 日に「Interaction to Next Paint」がウェブに関する主な指標に」：2024年3月12日に FID に代わった点
• web.dev「次のペイントに対するインタラクションを最適化する」：入力の遅れ・処理の時間・描画の遅れの3つの内訳と、処理を区切る方法
• web.dev「サードパーティの JavaScript を読み込む」：async・defer、接続の準備、使っていないスクリプトの削除
• web.dev「フォントに関するおすすめの方法」：WOFF2、サブセット、preconnect と preload、font-display、size-adjust
• web.dev「Cumulative Layout Shift（CLS）」：目安（0.1以下）と、操作から500ミリ秒以内のずれが除かれる点
• web.dev「Cumulative Layout Shift の最適化」：場所の確保、後から差し込まれる内容、transform での動き
• Search Console の公式ヘルプ「Core Web Vitals レポート」：実際の利用者のデータ（CrUX）、データ不足の表示、修正の検証の28日間
• Chrome for Developers「ファサードを使用したサードパーティ リソースの遅延読み込み」：チャットや動画の埋め込みを、押されるまで読み込まない作り方
• web-vitals（GoogleChrome の GitHub）：attribution 版で INP の内訳と対象の要素を取る