重要でありながら遅いページはホームページではない

概要

上司がウェブサイトが遅いと言ったとき、まず画像を圧縮してホームページに謝りたくなるかもしれない。しかし、より有効なのは、実際に最初に高速化する価値のあるページを決めることだ。この記事では、あるシナリオを紹介する。中規模B2Bサイトの「速度を改善してほしい」という依頼を受けた小さなマーケティングチームの例だ。フィールドデータを使ったCore Web Vitalsの計測、ビジネスへの影響によるページの選定、そして安価な修正の後に構造化データを追加する方法について説明する。その成果は、技術に詳しくない上司にも理解できる、短くて説得力のある計画だ。

ウェブサイトで最も遅いページは、PageSpeed Insightsが指摘するページではない。上司が一度も開いたことのないページ、つまり有料キャンペーンに関連するページや、忘れられた製品セクションに埋もれているページこそが、今月の予算が何かを生み出すかどうかを実際に左右する。幹部が「サイトが遅い、直してくれ」と言ったとき、彼らが必要としているのはウェブサイト高速化プロジェクトではない。優先順位をつける作業なのだ。

多くの人が経験したことがあるシナリオを考えてみよう。あなたは中規模B2Bソフトウェア企業のマーケティングチーム全員だとしよう。サイトには、ホームページ、ブログ、ヘルプセンター、そして特定の広告キャンペーンに紐づいた5つのランディングページがある。上司がCore Web Vitalsに関する記事を読んだか、クライアントの苦情を聞いた。指示は明確だ。「速くしろ」と。

次の1時間での対応が、次の1か月を画像圧縮に費やすか、重要指標を変える仕事に費やすかを左右する。

恥ずかしいページではなく、稼ぐページから始める

原則はこうだ。高速化の取り組みにはリターンがあり、そのリターンはトラフィックとコンバージョン価値に依存する。トラフィックが少なくてもコンバージョン率が高いページは、たとえ遅くても、ビジネスにとってホームページ以上に重要になり得る。

したがって、最初の一歩は、サイトマップではなくアナリティクスからページのリストを作ることだ。広告クリックという形でお金を受け取っているページはどれか？ ローンチ以来触れられていないページはどれか？ このシナリオでは、2か月間運用されている検索広告の背後にある最も重要なランディングページが、最適化されていない大きなスクリーンショットで作られていた。一方、ホームページは1年前に代理店によってすでに最適化されていた。

最初にホームページを修正してはいけない。お金を生むページを修正するのだ。これは技術的な選択ではなく、ビジネス上の選択だ。完全な技術監査が正しい対応に思えるなら、ちょっと待ってほしい。監査はリストを生み出すだけで、どの項目から始めるべきかは教えてくれない。適切に範囲を絞った技術的SEO監査は、パニック対応ではなく、意思決定ツールだ。

多くの場合、少数のページがトラフィックとコンバージョンの大部分を生み出し、残りは情報提供用または痕跡的なものであることがわかる。だからといって、遅い情報ページを永遠に無視してよいわけではない。収益に直結するページの後に順序付ける理由にはなる。ホームページがすべての中で最も遅いかもしれないが、ビジネス目標がリード獲得なら、ホームページへの訪問は単なる出発点であり、実際にコンバージョンが発生するのはランディングページだ。

「速い」を「測定された」と「体感される」に分ける

2つ目のステップは、パフォーマンステストがページについて語ることと、実際のユーザーが体験することを分けることだ。GoogleのCore Web Vitalsドキュメントでは、検索ランキングにカウントされる3つの指標が挙げられている。Largest Contentful Paint（読み込み）、Interaction to Next Paint（応答性）、Cumulative Layout Shift（視覚的な安定性）だ。これらが重要なのは、ユーザーが実際にページを使えるかどうかに影響する瞬間を追跡するからだ。

シナリオでは、パフォーマンステスターでランディングページを開き、妥当なスコアを得る。しかし、Google Search Consoleのフィールドデータ（実際の訪問者の体験を反映）と比較すると、そのページは頻繁に遅いことが判明する。それが重要シグナルだ。ラボテストは変更後、前後を比較するのに依然として有用だ。しかし、フィールドデータは、さまざまなデバイスや接続環境から広告をクリックした人々にとっての真実だ。

この代わりに	これで始める	理由
PageSpeedスコアを単一の数値として見る	Core Web Vitalsのフィールドデータ	フィールドデータはテストサーバーではなく実ユーザーから得られる
「サイトが遅い」	ビジネス目標を支えるページ	速いだけの無駄なページはリードを生まない
CMSを再構築する	画像を圧縮しスクリプトを整理する	低リスクの修正が利益の大部分をもたらす

後でさらに詳しいリファレンスが必要なら、Core Web Vitalsガイドで各指標を詳しく説明している。しかし今は、計画を立てるのに十分な知識だけでよい。重要なのは、その特定のページで実際に問題を引き起こしている3つの指標のうちどれかを特定することだ。テキストの表示が遅いなら、画像とサーバーレスポンスを調べる。ボタンがカクつくなら、長いJavaScriptタスクを調べる。レイアウトが飛び飛びになるなら、広告や埋め込み用に確保されたスペースを調べる。そのニュアンスこそが、的を絞った修正とランダムな最適化を分ける。

高価なものより先に安価なものを修正する

3つ目の原則は、パフォーマンスプロジェクトをリニューアルまで膨らませないことだ。実際にユーザー体験を改善するもののほとんどは、地味で安価だ。

ランディングページを見て、明らかな問題を特定しよう。画像はフル解像度のスクリーンショットだ。誰も特定できないサードパーティスクリプトがページ上にある。ウェブフォントがテキストのレンダリングをブロックしている。これらはよくある問題だ。

理想的な世界では、モダンフレームワークを使って1週間かけてページを書き直すだろう。実際には、半日でできるタスクから始める。画像の圧縮、未使用スクリプトの遅延読み込み、ヒーロー画像のプリロードだ。これらの変更は午後にはテストでき、承認委員会は必要ない。

注意点：速度の問題は常にこれほど単純とは限らない。サーバー、データベース、または制御できないサードパーティ依存関係が原因で遅いページもある。しかし、安価な修正を確認していないなら、高価な修正を正当化することはできない。多くのチームがスクリーンショットを圧縮しなかったために、再構築に予算を浪費している。ここには謙虚さが必要だ。パフォーマンススコアは症状であって診断ではない。安価な修正自体が診断なのだ。画像を圧縮した後、ボトルネックがコンテンツなのかインフラなのかがわかる。

コードを触っているついでに構造化データを追加する

ここが上司を驚かせるレイヤーだ。安価な修正を行った後、あなたはすでにページの中にいる。そのタイミングで、速度とはまったく関係ないものを追加するのに最適だ。構造化データである。

構造化データは、検索エンジンがページの内容を理解するのに役立つマークアップだ。リッチな検索結果や視認性の向上につながる同じHTMLであり、検索がAI生成の回答に移行するにつれて、その重要性は高まっている。小規模チームにとって、これは活用されていないレバーだ。新しいコンテンツを書く必要がないからだ。すでに存在するものにラベルを付けるだけだ。

シナリオでは、ランディングページにサービス指向のスキーマを追加する。正確なタイプは、ページが何についてのものか（サービスページ、記事、製品）によって異なる。すべてのタイプを一度に追加する必要はない。10個を雑に追加するより、1個を注意深く追加するほうがよい。結果が保証されているわけではない。表示するものを決めるのはGoogleだ。しかしリスクは低く、潜在的なメリットは現実的だ。さらに深く掘り下げるなら、構造化データ実装ガイドが実践的な手順を説明している。

修正を「利益につながったか？」に変換する

難しいのは技術的な作業ではない。技術に詳しくない上司への説明の仕方だ。

上司が求めたのは一つだけ。サイトを速くすることだ。「ランディングページのLCPを改善しました」と言っても、ぽかんとされるかもしれない。代わりに、その作業をビジネス上の成果に翻訳しよう。

このシナリオでは、ランディングページは有料キャンペーンの目的地だ。1秒待つごとに、訪問者がコールトゥアクションが表示される前に離脱する可能性がある。だからこう説明する。「お金が動くページから明らかな摩擦を取り除きました」と。特定のランキング上昇を約束することはできない（約束する人は誰でも推測しているだけだ）が、合理的で正直な議論はできる。また、上司がすでに理解している予算と結びつけることもできる。同じ広告費で訪問は得られる。違いは、その訪問がリードになるチャンスがあるかどうかだ。

専門用語だらけのダッシュボードより、シンプルな月次レポートのほうが効果的だ。3つのことを示す。どのページを選んだか、どの指標を測定したか、何を変更したか。指標が改善すれば、それが検証になる。改善しなければ、再評価できる明確な実験がまだある。月ごとに単一のスコアを追いかけないこと。Core Web Vitalsはトラフィック構成、デバイスタイプ、さらには地域によって変動する。数字ではなく傾向を報告しよう。

次の月曜日に何をするか

このシナリオから得られる教訓は、「ウェブサイト」を修正するのではなく、データに基づいて特定のページを修正し、一度きりのプロジェクトではなく、繰り返し可能なプロセスを手に入れることだ。権力を持つ人が「速くしろ」と言ったとき、最も有用な返答は、明確化のための単一の質問だ。「どのページを、誰のために？」

その後、フィールドデータを測定し、安価な修正を行い、すでにコードを触っているなら構造化データを追加し、平易な言葉で報告する。結果は劇的ではないかもしれない。しかし、どのページが速くなったのか、なぜそのページを選んだのか、次に何をすべきかが正確にわかる。それは、スピードスコアから始まり、誰も理解できないリニューアルで終わる曖昧なプロジェクトよりも良い成果だ。