予約フローでレイアウトシフトが発生していたSPA
Prijsvrijは、旅行の検索・比較・予約ができるオランダの旅行サイトです。サイト全体がSPAで構築されており、同じチームがPrijsvrij.beとD-reizenも運営しています。
現地で1日4時間、計2日間の作業を行いました。初日はサイトの診断を実施しました。2日目はチームと診断結果を確認し、最も優先度の高い問題から順にどう修正すべきか、ステップごとに説明しました。
ファーストビュー、予約フロー、クリック操作
レイアウトシフトの大半は、ソフトナビゲーションで発生していました。ページを再読み込みせずにアプリがコンテンツを切り替える処理です。トップページでLighthouseを実行しても、これらは一切検出されません。しかし、予約を進める実際のユーザーは遭遇します。そしてCrUXは、最初に開いたURLのシフトとしてカウントします。
2026年3月末に診断レポートを提出し、4月15日にデン・ボスで、その1週間後にはオンラインで開発チームとレビューを行いました。特に難関だったのがCLSです。この構成としては原因が通常より多くありました。開発チームが3サイトすべてで改修を完了させた結果、5月には全サイトでデスクトップのCLSがグリーン（良好）になりました。
6月のある朝、先方のフロントエンドリードからメールが届きました。CoreDashのClaude Code連携を使い、ここ数週間prijsvrij.nlのチューニングを進めていたところ、グラフが好転してきたとのことでした。「D-reizenも追加できないか」という相談です。1時間も経たないうちに、D-reizenとPrijsvrij.beの両方がCoreDashに追加されました。
次はINPです。6月末に現状を確認したとき、過去に何度も目にしてきたパターンだと気づきました。確立された手順に沿って一つひとつ正確に対処すれば、確実に改善できます。これで大部分は解決します。その奥にある課題が見えてくるのはそれからですが、それらは常に小さな問題です。そこで、よりハンズオンな進め方を提案しました。机上の理論より実践を重視し、ピンポイントで小さな改修を加えていくやり方です。7月には先方のオフィスで昼食を交えて作業を行い、現在も四半期ごとの訪問を続けています。
休暇シーズンには、旅行中のユーザーからのアクセスが増加するため、モバイルのLCPが一時的に上昇します。それでも2.5秒を大幅に下回る水準を維持しており、すでに再び低下し始めています。
ローディングアニメーションはレイアウトシフトを先送りしているだけ
アニメーションで待ち時間をカバーできているように見えていました。しかし、フライト詳細の表示に切り替わった瞬間にレイアウトシフトが発生します。
クリック処理内のトラッキングは、すべてのクリックを遅らせる
クリックハンドラー内のタグは、画面が更新される前に実行されます。更新の後に移動させれば、ユーザーには先に結果が表示され、タグも正常に実行されます。
SPAは変化し続ける
リリースを重ねるたびに、前回のチェック時には存在しなかったコンポーネントやタグが追加されます。だからこそ、私は四半期ごとに訪問を続けています。
Lighthouseでは検出できないSPAのレイアウトシフトはありませんか？
予約フローや決済フローのURLをお送りください。ソフトナビゲーションを含め、実際のユーザーと同じように画面を操作して確認します。
またはコンサルティングの詳細を見る。その他の実績はクライアント実績ページをご覧ください。
