2022年、あるホスティング比較サイトがクライアントとして現れました。大規模なカタログ——約4,000ページ、深くネストされたカテゴリ構造、いたるところに散らばったアフィリエイトリンク、大陸並みのサイズのヒーロー画像。Google Search Consoleは目も当てられない状態でした。モバイルでのLCPは4.2秒。INP（当時はFIDと呼ばれていました）はギリギリの状態。クライアントはすでに前の代理店に£6,000を費やしており、その代理店はCDNを導入して終わりにしていました。
このプロジェクトが、Seahawkで高ページ数サイトに対するパフォーマンスの考え方を形作ることになりました——ディレクトリサイト、リスティングプラットフォーム、HostListスタイルのホスティングレビュープロパティなど。以下は実際の戦略です。Seahawk for high-page-count sites — directory sites, listing platforms, hosting review properties like HostList-style builds. What follows is the actual playbook.
---
大規模サイトがLCPを異なる方法で低下させる理由
小規模なサイトは単純な問題を抱えています。1つのヒーロー画像、1つのテーマ、やりすぎている1つのプラグイン。この3つを修正すれば2秒以下になります。
大規模サイト？それは全く別の話だ。LCP要素はどのページにいるかによって変わる。カテゴリアーカイブのLCP候補は、商品詳細ページのそれとは異なり、ホームページのそれとも異なる。ほとんどのパフォーマンスツールは単一のスコアを報告する。その数値は嘘だ。野放図に異なるページセットの平均値であり、ホームページを修正しながら下部の3,800個のリスティングページを無視することは、エージェンシーが悪評を得る正確なやり方だ。which page you're on. A category archive has a different LCP candidate than a product detail page, which has a different candidate than the homepage. Most performance tools report a single score. That number is a lie — it's an average of a wildly varied set of pages, and fixing the homepage while ignoring the 3,800 listing pages underneath it is exactly how agencies earn bad reputations.
GoogleのCore Web Vitalsドキュメントは明確だ。フィールドデータ——実際のユーザーが経験する内容で、Chrome User Experience Reportで測定される——がGoogleが実際にランキングシグナルとして使用するものだ。PageSpeed Insightsからのラボデータは方向性を示すものであり、決定的ではない。PSIで95点を得ながら、CrSXデータでPoor LCPを持つサイトを見たことがある。この2つを混同してはいけない。Core Web Vitals documentation from Google is clear that field data — what real users experience, measured in Chrome User Experience Report — is what Google actually uses for ranking signals. Lab data from PageSpeed Insights is directional, not definitive. I've seen sites score 95 on PSI and still have Poor LCP in CrSX data. Don't confuse the two.
リスティングサイト上の3つの本当の原因
私が監査してきた（この時点で数百件を通過してきた）すべての大規模サイトで、LCP障害はほぼ毎回、3つの根本原因にさかのぼる。
- 最適化されていないヒーローまたはカード画像——フル解像度で提供されることが多く、形式が間違っている、fetchpriorityヒントがない — often served at full resolution, wrong format, no
fetchpriorityhint - レンダリングをブロックするサードパーティスクリプト——アフィリエイトトラッカー、広告ネットワーク、比較ウィジェットがブラウザが何もペイントできる前にロードされる — affiliate trackers, ad networks, comparison widgets loading before the browser can paint anything
- TTFB がLCP予算を増加させる——ページがロードを開始する前に600～900msを消費する遅いサーバー応答 — slow server response eating 600–900ms before the page even starts loading
その3つ目が人々が過小評価する部分だ。TTFB が700msの場合、ブラウザが1ピクセルもレンダリングする前に、すでに「良好」なLCP予算のほぼ半分を消費している。ホスティングの選択とサーバー側のキャッシング機構はDevOpsの懸念ではない——SEOの懸念だ。
---
TTFBから始める：これは第一にホスティングとキャッシング機構の問題だ
上記で言及したHostListタイプのプロジェクト？最初にやったのは、5つの異なる地理的場所からWebPageTestを実行することだった。TTFBは一貫して680～820msだった。そのサイトはバージニア州の共有ホストで運営されていた。有機トラフィックの大部分は英国とドイツから来ていた。WebPageTest from five different geographic locations. TTFB was consistently 680–820ms. The site was on a shared host in Virginia. Most of their organic traffic came from the UK and Germany.
マネージドWordPressホストに移行し、ロンドンとフランクフルトにエッジノードを配置した。リスティングページ（データはそこまで頻繁に変わらないので）のキャッシュライフタイムを12時間に設定して、フルページキャッシングを構成した。TTFBはリピートリクエストで120～180msに、初回キャッシュミスで280～350msまで低下した。この1つの変更だけで、画像に一切手を付ける前にLCPから約500ms削減できた。
ホスティング側で常にチェックすることがいくつかある：
- フルページキャッシングは実際に機能しているか？X-Cacheレスポンスヘッダーを確認する。すべてのリクエストでMISSと表示されている場合、キャッシング層は機能していない。 Check the
X-Cacheresponse header. If it saysMISSon every single request, your caching layer isn't functioning. - オリジンサーバーは主要な対象ユーザーに地理的に近いか？これは明らかに聞こえるが、実際には間違っていることが意外と多い。 This sounds obvious. You'd be surprised how often it's wrong.
- キープアライブは有効になっているか？安いホストの中には、まだ永続接続を無効にしているところがある。2024年にこんなことがあるとは信じられないが、起きている。 Some cheaper hosts still disable persistent connections. Wild in 2024, but it happens.
- HTTP/2またはHTTP/3は有効か？curl -I --http2 https://yourdomain.comを実行して、レスポンスのプロトコルを確認する。 Run
curl -I --http2 https://yourdomain.comand check the protocol in the response.
TTFBを解決するまで画像最適化に手を付けるな。遅いサーバー上で画像を最適化するのは、燃えている家を塗装するようなものだ。
---
LCP画像問題（そして`fetchpriority`がすべてを変える理由）
つまり、画像ですね。カード・グリッド・レイアウトを持つリスティングサイトでは、LCP要素はほぼ必ず、ファーストビューの最初のカード画像か、またはヒーローバナーです。ブラウザはそれを発見し、取得し、デコードし、レンダリングする必要があります。これらの各ステップが遅延する可能性があります。
HostListプロジェクトで実際に行ったことを順番に説明します。
- すべてのカード画像をWebPに変換しました—Imagifyのバルク変換を使用して。ファイルサイズの平均は58%削減され、使用していたカードのサムネイルサイズ（280×180px表示、retina用に2倍提供）での視覚的な品質低下はありませんでした。 — using Imagify's bulk conversion. Average file size dropped 58% without visible quality loss at the card thumbnail sizes we were using (280×180px display, served at 2x for retina).
- 最初のカード画像に`fetchpriority="high"`を追加しました—この1つの変更だけで、WebPageTestで計測されたLCPから約200msを削減できました。ブラウザがそれを通常の遅延画像のように扱うのを止め、プリロードスキャナーのキューに直ちに登録します。 — This one change alone knocked ~200ms off measured LCP in WebPageTest. The browser stops treating it like a regular lazy image and queues it immediately in the preload scanner.
- カード画像の最初の2行から`loading="lazy"`を削除しました—遅延ロードはビューの下の画像に優れています。最初の表示行では、実際に逆効果です。ブラウザに画像がビューポートの近くになるまで取得しないよう指示しています—すでにそこにあるのに。 — Lazy loading is brilliant for below-fold images. On the first visible row, it actively hurts you. It tells the browser to not fetch the image until it's near the viewport — which it already is.
- ホームページテンプレートに限定して、`<head>`内のヒーロー画像用に`<link rel="preload">`タグを追加しました。 in the
<head>on the homepage template specifically.
このシーケンスにより、ホームページのLCPがラボ環境で3.1sから1.4sに短縮されました。フィールドデータは約28日以内に続きました（CrUXデータが大規模な変更を反映するのにはおおむねそのくらいかかります）。
レスポンシブ画像に関する注記
同じ1400px幅の画像をモバイルデバイスに提供している場合、帯域幅を無駄にしてデコード時間を追加しています。srcsetを適切に使用してください。2016年の会話のように聞こえるかもしれませんが、Seahawkを通過するサイトの約40%でまだこれを見かけます。WordPressのwp_get_attachment_image()関数はsrcsetを自動的に生成します—ただし、画像が十分な解像度でアップロードされており、テーマがadd_filter('max_srcset_width', ...)で抑制していない場合のみです。srcset properly. I know this sounds like a 2016 conversation but I still see it on probably 40% of the sites that come through Seahawk. The WordPress wp_get_attachment_image() function generates srcset automatically — but only if the image was uploaded at sufficient resolution and the theme hasn't suppressed it with add_filter('max_srcset_width', ...).
---
レンダリングをブロックするスクリプト：アフィリエイトサイトの税金
ホスティング比較サイトやリスティングプラットフォームはアフィリエイト収益で成り立っている。つまり、サードパーティのトラッキングスクリプトが必要だ。Commission Junction、Impact、Awin、カスタムピクセルトラッカー — それらが積み重なる。単一のリスティングサイトで14個の独立したサードパーティスクリプトオリジンを数えたことがある。それぞれがDNSルックアップ、TCP接続、TLSハンドシェイクを個別に実行してから、そのスクリプトの1バイトすら受け取られる。
修正はスクリプトを削除することではない。削除はできない — 収益がそれに依存している。修正はシーケンシングだ。
サードパーティスクリプトがLCP要素の初期レンダリングをブロックすることは絶対にあってはならない。完全に。
実践的には、これは以下を意味する：
- すべてのアフィリエイト/アナリティクススクリプトを、<head>ではなくDOMContentLoadedイベント後にロードするよう移動させる。after the
DOMContentLoadedevent, not in<head>. - 制御下にあるすべてのスクリプトにasyncまたはdefer属性を使用する。
asyncordeferattributes on every script you control. - 制御下にないスクリプト（タグマネージャーによって注入されたもの）については、Google Tag Manager自体をdeferでロードする — はい、これはほとんどのアフィリエイトトラッキングユースケースでは安全であり、GTM自体のドキュメントがこのアプローチを認めている。
defer— yes, this is safe for most affiliate tracking use cases, and GTM's own documentation acknowledges this approach. - Asset CleanUp Proやwp Rocketのスクリプト遅延機能などのスクリプトマネージャーを使用して、ユーザーインタラクション（最初のスクロールまたは最初のクリック）まで非必須のサードパーティをdeferする。
HostListの再構築では、サードパーティスクリプトをdeferすることでTotal Blocking Timeを1,840msから290msに削減した。TBTは直接的なCore Web Vitalではないが、そのCore Web VitalであるINPとの相関が強い。is.
フォント読み込み：誰も言及しない静かなLCP殺し
フォント読み込み：誰も言及しない静かなLCP殺し
カスタムフォントは特定の不具合モードを引き起こします。ブラウザはレイアウトをレンダリングし、LCP テキスト要素に到達し（LCP が画像ではなく見出しの場合もあります）、その後フォントファイルがペイントされるまで待機します。これはFlash of Invisible Textと呼ばれ、フォントファイルのサイズとサーバーの近接性に応じて、LCP を200ミリ秒から1秒以上遅延させます。
この問題を解決するには2つの方法があります：
@font-face宣言でfont-display: swapを使用してください。ブラウザはフォールバックフォントで即座にレンダリングし、カスタムフォントが読み込まれた時点で切り替わります。LCP候補が時間通りにペイントされます。in your@font-facedeclaration — the browser renders in a fallback font immediately and swaps when the custom font loads. LCP candidate gets painted on time.- フォントを自分でホストしてください。Google Fonts は クロスオリジンリクエストを追加します。google-webfonts-helperツールを使用した自己ホスティングにより、独自ドメインからフォントを配信でき、その余分な接続を削減できます。google-webfonts-helper tool lets you serve fonts from your own domain, cutting that extra connection.
大規模なディレクトリサイトをそのツールを使用してGoogle Fonts から移行するのに約45分かかりました。LCP が180ミリ秒改善されました。単体では革新的ではありませんが、他のすべての施策と組み合わせると、これらのマージンが複合的に効いてきます。
---
フィールドで実際に重要なものを測定する
CrUX データが最高の真実です。しかし月1回の更新に限定され、十分なトラフィックのある URL のみです。数千ページのある大規模サイトの場合、より細粒度な何かが必要です。
PageSpeed Insights APIをスクリプト化して、代表的なURL群を対象に実行しています。通常はトラフィック上位100ページ、カテゴリーレベルページ50件、「薄い」深いカタログページ20件という構成です。これを月次で実行することで、単一時点のスコアではなく、適切なパフォーマンス分布を把握できます。PageSpeed Insights API scripted across a representative sample of URLs — typically the top 100 pages by traffic, 50 category-level pages, and 20 "thin" deep-catalogue pages. Running this monthly gives a proper performance distribution, not a single-point score.
Lighthouse CI（クライアントの開発サイクルがある場合、CI/CDパイプラインで実行）では、以下の値に対してアサーションを行っています：
- LCP ≤ 2.5s（ラボ環境、保守的なターゲット。フィールドはラボ比10～15%遅れる傾向があるため）
- TBT ≤ 300ms
- CLS ≤ 0.1
ただ、HostList型のビルドでLCP 1.5秒未満を目指す場合は、ラボ環境のターゲットをさらに厳しくする必要があります。そうしたプロジェクトではLighthouse CIで LCP ≤ 1.8s に設定し、CrUXが追いつくと通常フィールドデータで1.3～1.5sが実現できます。
---
まとめ：HostListの結果
ホスティング移行、フルページキャッシング、画像フォーマット変換、LCP候補への fetchpriority 付与、折り目より上の行からのレイジーロード削除、スクリプトディファー、フォント自己ホスティングのすべてを実行した後の数値は以下の通りです：fetchpriority on LCP candidates, lazy-load removal from above-fold rows, script deferral, and font self-hosting — here's what the numbers looked like:
- TTFB: 780ms → 160ms（中央値、英国訪問者）: 780ms → 160ms (median, UK visitors)
- LCP（ラボ、モバイル）：4.2秒 → 1.4秒: 4.2s → 1.4s
- LCP（フィールド、CrUX、75パーセンタイル）：3.8秒 → 1.6秒（移行後60日時点で測定）: 3.8s → 1.6s (measured 60 days post-migration)
- TBT：1,840ms → 290ms: 1,840ms → 290ms
- CLS：既に0.03で良好なため、変わらず: was already fine at 0.03, unchanged
すべてのサイトが2.8秒の改善を得られるわけではありません。しかし、私が携わった大規模なリスティングサイトのほぼすべてが、これらの問題を同時に抱えていました。つまり、改善効果が積み重なるということです。1つ修正すれば300msの改善が得られます。すべて修正すれば2.5秒の改善が得られます。
---
よくある質問
ホスティングは本当にLCPに大きく影響するのですか？
はい。特に最初の段階では、他のどの要因よりも重要です。TTFBが500msを超えている場合、画像最適化をいくらしてもLCPを「良好」まで改善することはできません。TTFBはその他すべての基礎です。まずTTFBを200ms以下に抑えてから、残りのことを心配してください。
ホスト移行ではなくCDNを使うべきですか？
CDNはスタティックアセットの配信に役立ち、適切に設定すればキャッシュされたフルページHTMLのTTFBを削減できます。しかし多くのCDNセットアップはアセットのみをキャッシュし、フルHTMLレスポンスはキャッシュしません。CDNが実際にキャッシュされたHTMLを配信しているのか、単に画像をオフロードしているだけなのかを確認してください。後者の場合、より優れたオリジンホストのほうがLCPに大きく貢献します。
`fetchpriority="high"`は今、広くサポートされていますか？
2024年の時点では、はい — Chrome、Edge、Safari（Safari 17.2以降）でサポートされています。Firefox対応はFirefox 132で実装されました。それに対応していないブラウザでは安全に無視されます。LCP画像要素に追加することによるデメリットはありません。
CrUXデータが改善を反映するのにどのくらいの時間がかかりますか？
ユーザーが実際により高速化したサイトを利用開始してからおよそ28日です。CrUXは28日間のローリングウィンドウを使用します。今日変更をデプロイすれば、フィールドデータスコアは約1ヶ月間、完全にはそれを反映しません。最適化スプリントの翌日にPageSpeed Insightsがまだ「改善が必要」と表示されていても慌てないでください。
リスティングサイトにとって最も高いインパクトをもたらす単一の変更は何ですか？
ほぼすべてのプロジェクトで、それはTTFBでした。ただし2番目に高いインパクトは一貫して、ファーストビューカードカメージの`loading="lazy"`を削除して`fetchpriority="high"`を追加することでした。この2つは通常、LCP改善全体の40～60%を占めます。他のすべてはその基礎の上への複合的な改善です。loading="lazy" from above-fold card images and adding fetchpriority="high". Together those two things usually account for 40–60% of the total LCP improvement. Everything else is compounding gains on top of that foundation.
---
大規模サイトでのパフォーマンス作業はほとんど配管工事です。地味で、着実で、4秒のLCPを1.4秒に引き下げて、2ヶ月後にオーガニックトラフィックが上がるのを見るとき、深くやりがいを感じます。単一の魔法のような設定はなく、正しい順序で行われた特定の意思決定の連続があるだけです。
サーバーを速くしましょう。次にLCP要素を早期に発見されて、フェッチされるようにしましょう。そして他のすべてをその邪魔にならないようにしましょう。