SleepDr ケーススタディ: WordPress から Next.js へのマイグレーション (Lighthouse 35→94)
SleepDrのケーススタディ：WordPressからNext.jsへの移行で、Lighthouseスコアが35から94に改善
先四半期、WordPressが常に最適なツールではない理由を完璧に示すプロジェクトに取り組みました。SleepDr.com — 228のブログ投稿、お問い合わせフォーム、モバイルLighthouseスコア35を備えたスリープヘルスコンテンツサイト — が速度を求めて私たちのもとに来ました。彼らのオーガニックトラフィックは数ヶ月間低下していました。サイト全体のCore Web Vitalsスコアを統合した2026年3月のGoogleコアアップデートは彼らに大きな打撃を与えました。遅いブログ投稿のすべてがドメイン全体を引き下げていたのです。
私たちは彼らをNext.js 15 + Payload CMS 3 + Supabase + Vercelに移行させました。結果：モバイルLighthouse 94、デスクトップ99。オーガニックトラフィックは6週間以内に回復しました。これはそこにたどり着いた方法の完全なストーリーです — すべての最適化、すべてのメトリック、すべての決定 — あなた自身のプロジェクトに同じ思考法を適用できるようにします。
目次
- ビフォー：WordPressがSleepDrを殺していた理由
- 移行スタック：なぜこれを選んだのか
- ビフォー・アフター：数字
- 最適化1：画像最適化（LCP -3s）
- 最適化2：フォント最適化（FCP -1.5s）
- 最適化3：JavaScript削減（TBT 1200ms → 50ms）
- 最適化4：サーバーサイドレンダリングとエッジデプロイメント（TTFB -85%）
- 最適化5：サードパーティスクリプト管理
- 最適化6：CSS最適化（800KB → 35KB）
- ステップバイステップチェックリスト
- 2026年Core Web Vitalsが意味するもの
- FAQ
ビフォー：WordPressがSleepDrを殺していた理由
SleepDrのWordPress設定は、蓄積された技術的負債の教科書的な例でした。3年間で、彼らは34個のプラグインをインストールしました。テーマはjQueryとさらに2つの追加JavaScriptライブラリを読み込みました。すべてのページリクエストはMySQLデータベースにヒットし、HTMLをその場で生成し、既に負荷に対応できていない共有ホスティングプラン経由で最適化されていない画像を提供しました。
初期のLighthouse監査がモバイルでどのように見えたかは次のとおりです：
- 総合スコア：35（赤、不合格）
- FCP：4.2秒
- LCP：6.8秒 — 「良好」のしきい値のほぼ3倍
- CLS：0.28 — 広告、寸法のない画像、Webフォント読み込みからレイアウトが至る所でジャンプしていた
- TBT：1,200ms — メインスレッドが1秒以上ロックされていた
- TTFB：2.1秒 — 何かがレンダリングされる前に、サーバー自体が遅かった
サイトは単に遅かっただけではありません。モバイルデバイスのユーザーに対して積極的に敵対的でした。GoogleのLighthouseモバイルシミュレーションはミッドティア携帯電話をスロットルされた4G接続でシミュレートするため、スコアはそれより悪い条件の実ユーザーが経験していたことを反映していました。
2026年3月のGoogleコアアップデート後、ページごとではなくドメイン全体にわたってパフォーマンスを集約するホリスティックCWVスコアリングが導入され、SleepDrの228個の遅いブログ投稿はサイト全体のランキングに悪影響を与えていました。ロールアウトからの初期データは、影響を受けたサイトで20-35%のトラフィック低下を示しました。SleepDrはおよそ30%の低下を見ました。
何かを変える必要がありました。
移行スタック：なぜこれを選んだのか
このスタックをトレンディだから選んだわけではありません。各部分がSleepDrが抱えていた特定の問題を解決するから選びました。
- Next.js 15（App Router）：ハイブリッドレンダリング。ブログ投稿の静的生成、必要に応じたサーバーサイドレンダリング。クライアント側JavaScriptを最小化するReact Server Components。これは私たちの得意分野です — 私たちはNext.js開発実績を通じて数十のプロジェクトをそれで構築してきました。
- Payload CMS 3：WordPressの膨張がない、自己ホストされるヘッドレスCMS。これはSleepDrのコンテンツチームに同じ編集体験をもたらしました。私たちはヘッドレスCMS実装を多く扱っており、Payload 3はコンテンツ量の多いサイトの私たちのゴーツーになっています。
- Supabase：PostgreSQLデータベース（リアルタイム機能付き）。お問い合わせフォーム送信、分析イベント、およびその他の動的データを処理しました。
- Vercel：エッジデプロイメント。サイトはユーザーに最も近いノードから提供されます。TTFBはほぼ無視できるようになります。
総移行には7週間かかりました。コンテンツ移行 — 228投稿すべてとそれらの画像、メタデータ、URLストラクチャ — はそのうち約2週間がかかりました。WordPress REST APIからコンテンツをプル、変換、Payload CMSへプッシュするカスタムスクリプトを書きました。
ビフォー・アフター：数字
完全な内訳はこれです。これらはLighthouseモバイルスコアで、ここで本当のストーリーがあります。
| メトリック | ビフォー（WordPress） | アフター（Next.js 15） | 改善 |
|---|---|---|---|
| First Contentful Paint（FCP） | 4.2秒 | 1.1秒 | -3.1秒（74%高速化） |
| Largest Contentful Paint（LCP） | 6.8秒 | 1.8秒 | -5.0秒（74%高速化） |
| Cumulative Layout Shift（CLS） | 0.28 | 0.01 | -0.27（96%削減） |
| Total Blocking Time（TBT） | 1,200ms | 50ms | -1,150ms（96%削減） |
| Time to First Byte（TTFB） | 2.1秒 | 0.3秒 | -1.8秒（85%高速化） |
| 総合モバイルスコア | 35 | 94 | +59ポイント |
| 総合デスクトップスコア | 61 | 99 | +38ポイント |
明確にしておきたいのは、これらは単一ページのチェリーピックされた数字ではありません。20個の代表的ページでLighthouseを実行し、結果を平均化しました。モバイルスコアはテストされたすべてのページで91〜97の範囲でした。デスクトップは97〜100でした。
それでは、これらの改善のそれぞれをどのように達成したのか詳しく説明しましょう。
最適化1：画像最適化（LCP -3s）
画像は旧サイトで最も大きなパフォーマンスキラーでした。SleepDrのブログ投稿は製品写真とインフォグラフィックスが多く含まれていました — デザイナーのマシンから直接フル解像度のPNGとしてアップロードされることが多かったです。一部の画像は3〜4MBでした。
実施内容
**すべての画像にnext/imageを使用しました。**このコンポーネントは多くの重い処理をします：
import Image from 'next/image';
export function HeroImage({ src, alt }) {
return (
<Image
src={src}
alt={alt}
width={1200}
height={630}
priority // フォールドの上の画像：先読み
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
quality={80}
/>
);
}
next/imageが自動的に処理すること：
- フォーマット変換：PNG/JPEGの代わりにWebP（またはサポートされている場合はAVIF）を提供します。これだけで画像サイズが60〜80%削減されます。
- レスポンシブsrcset：複数のサイズを生成するため、モバイルユーザーはデスクトップサイズの画像をダウンロードしません。
- デフォルトで遅延読み込み：フォールド下の画像はユーザーがそれにスクロールするまで読み込まれません。
- 明示的な寸法：
widthとheightプロップはレイアウト内のスペースを予約し、これはCLSを直接修正します。
主な知見：LCP要素の優先度読み込み
画像上のpriorityプロップが重要でした。それがないと、Next.jsは画像を遅延読み込みします。しかしヒーロー画像がLCP要素である場合 — SleepDrのほとんどのページではそうでした — 遅延読み込みするとLCPスコアに実際に害をもたらします。すぐにダウンロードを開始したいです。
私たちはすべてのページテンプレートを監査し、LCP要素を特定し、priorityでマークしました。ブログ投稿ページは特集画像を使用しました。ホームページはヒーロー画像を使用しました。シンプルですが、LCPに3秒の差をもたらしました。
画像CDN
Vercelの組み込み画像最適化はCDNとして機能します。画像は最初のリクエスト時にエッジで処理されキャッシュされます。後続のビジターはミリ秒単位でキャッシュされた最適化版を取得します。Cloudinaryのサブスクリプションは不要です。WordPressプラグインが同じことをしようとしていますがより悪いことはありません。
正味への影響：画像最適化だけでLCPが6.8秒からおよそ3.8秒に低下しました。残りのLCPゲインはTTFB改善とフォント読み込みから来ました。
最適化2：フォント最適化（FCP -1.5s）
SleepDrのWordPressテーマは外部スタイルシートリンク経由で3つのGoogle Fontsを読み込みました。それぞれがfonts.googleapis.comへの複数の描画ブロッキングリクエスト、その後に実際のフォントファイルのためのfonts.gstatic.comへの別のリクエストでした。ブラウザがテキストを描画できる前に6つのネットワークラウンドトリップです。
実施内容
next/fontを使用してフォントを自己ホストする：
import { Inter, Merriweather } from 'next/font/google';
const inter = Inter({
subsets: ['latin'],
display: 'swap',
variable: '--font-inter',
});
const merriweather = Merriweather({
weight: ['400', '700'],
subsets: ['latin'],
display: 'swap',
variable: '--font-merriweather',
});
next/fontが異なる仕組み：
- フォントファイルを自己ホストする：外部ネットワークリクエストなし。フォントはビルドとともにバンドルされ、同じCDNから提供されます。
- 自動サブセッティング：実際に必要な文字セットのみが含まれます。InterのLatin部分は完全な100KB+ファイルの代わりに約20KBです。
display: 'swap'：テキストはフォールバックフォントですぐにレンダリングされ、読み込まれるとWebフォントに交換されます。見えないテキストなし。FCP をブロックする無スタイルコンテンツのフラッシュなし。- CSSカスタムプロパティ注入：フォントはCSSカスタムプロパティ経由で適用されます。つまり、フォールバックフォントメトリックを慎重に一致させたため、フォント交換時にレイアウトシフトがゼロです。
3番目のフォントを完全に削除しました。旧サイトは見出しの装飾的なフォントを使用していて、読みやすさを向上させることなく視覚的なノイズを追加していました。2つのフォント。それが全部です。
正味への影響：FCP描画ブロッキングフォントリクエストの排除により約1.5秒改善しました。
最適化3：JavaScript削減（TBT 1200ms → 50ms）
これは最も劇的な単一の改善でした。TBT1,200msは、ブラウザのメインスレッドが1秒以上ブロックされていたことを意味します — ユーザーはその時間中にクリック、スクロール、または何かと相互作用することができませんでした。
すべてのJavaScriptはどこから来たのか？
WordPressサイトは読み込みました：
- jQuery（87KB圧縮） — テーマとほとんどのプラグインで使用
- 34プラグインスクリプト — お問い合わせフォーム、分析、ソーシャル共有、クッキー同意、2つの異なるスライダーライブラリ、ライトボックスなど
- テーマJavaScript — メニュートグルとアニメーションライブラリの別の150KB
- インラインスクリプト — さまざまなプラグインからの雑多なスニペット
<head>に注入
ページ読み込み時のJavaScript合計：およそ1.8MB。スロットルされたモバイル接続では、パースと実行に1秒以上かかります。
実施内容
jQueryはゼロ。 Next.jsはReactを使用します。jQueryは必要ありません。
プラグインはゼロ。 すべての機能は目的に特化したコンポーネントとして再構築されました：
- お問い合わせフォーム：4KBのReactコンポーネント+ Supabaseサーバーアクション
- クッキー同意：2KBコンポーネント（
next/script戦略付き） - ソーシャル共有：ネイティブWeb Share API（フォールバックリンク付き）— ライブラリは必要ありません
- 分析：軽量Plausibleスクリプト（< 1KB）
フォール下の何かに対する動的インポート：
import dynamic from 'next/dynamic';
const NewsletterSignup = dynamic(
() => import('@/components/NewsletterSignup'),
{ ssr: false } // クライアントのみに読み込み、必要な場合のみ
);
const RelatedPosts = dynamic(
() => import('@/components/RelatedPosts')
);
React Server Componentsはレンダリングのほとんどを処理しました。ブログ投稿コンテンツ、ヘッダー、フッター、ナビゲーション — すべてサーバーレンダリング、クライアント側JavaScriptはゼロ。対話的な要素のみ（モバイルメニュートグル、お問い合わせフォーム、ニュースレターサインアップ）がJavaScriptをブラウザに送信しました。
移行後のページ読み込み時のJavaScript合計：およそ85KB。それは95%削減です。
正味への影響：TBT1,200msから50msに低下。 メインスレッドは基本的に自由です。
最適化4：サーバーサイドレンダリングとエッジデプロイメント（TTFB -85%）
TTFBはサーバーが応答の最初のバイトを送り始めるまでにどのくらいかかるかを測定します。SleepDrのWordPressサイトはモバイルで2.1秒のTTFBがありました。つまり、何かが起こる前に — 画像が読み込まれる前に、フォントがダウンロードされる前に、JavaScriptが実行される前に — ユーザーはサーバーの応答を待つため空白のスクリーンを2秒以上見つめていました。
WordPressが遅かった理由
WordPressのすべてのページリクエスト：
- 共有ホスティングサーバーにヒット（既に遅い）
- PHPを読み込んだ
- WordPressコアを実行
- 34プラグインフックを通じて実行
- MySQLを複数回クエリ
- HTML動的に生成
- 応答を送信
WP Super Cacheがインストールされていても、キャッシュヒット率は一貫性がなく、サーバー自体がパワー不足でした。
実施内容
228のすべてのブログ投稿に対して静的生成を行いました。 ビルド時に、Next.jsはすべてのブログ投稿を静的HTMLに事前レンダリングします。結果はVercelのEdge Networkに配置された.htmlファイルのセット — 80以上のグローバル場所に分散されています。
ユーザーがブログ投稿をリクエストするとき、彼らは最近いノードから事前構築されたHTMLファイルを提供されます。データベースクエリなし。サーバーサイド処理なし。ただのCDNからのファイル読み取り。
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
const posts = await payload.find({
collection: 'posts',
limit: 300,
});
return posts.docs.map((post) => ({
slug: post.slug,
}));
}
export default async function BlogPost({ params }: { params: { slug: string } }) {
const post = await payload.find({
collection: 'posts',
where: { slug: { equals: params.slug } },
limit: 1,
});
return <ArticleLayout post={post.docs[0]} />;
}
お問い合わせフォームページについては、動的な動作が必要なため、サーバーサイドレンダリングを使用しました。しかし、Vercelのエッジ関数でのSSRでも、100ms未満で実行されます。計算がCDNではなく集約データセンターで行われるためです。
正味への影響：TTFB2.1秒から0.3秒に低下 — 85%改善。キャッシング時の再訪問では、50ms程度です。
最適化5：サードパーティスクリプト管理
サードパーティスクリプトはWebパフォーマンスの静かなキラーです。SleepDrのWordPressサイトはGoogle Analytics（GA4）、Google Tag Manager、Facebookピクセル、Hotjarレコーディングスクリプト、およびクッキー同意マネージャーを読み込みました — すべて<head>で描画ブロッキング。
実施内容
Next.jsは読み込み戦略を備えたnext/scriptコンポーネントを提供します。私たちはそれらを意図的に使用しました：
import Script from 'next/script';
{/* 分析：ページが対話的になった後に読み込み */}
<Script
src="https://plausible.io/js/script.js"
strategy="afterInteractive"
data-domain="sleepdr.com"
/>
{/* クッキー同意：ブラウザがアイドル状態の時に読み込み */}
<Script
src="/scripts/cookie-consent.js"
strategy="lazyOnload"
/>
afterInteractive戦略はNext.jsハイドレーション後にスクリプトを読み込みます。ユーザーはすでにページを見ることができ、対話できます。lazyOnload戦略はブラウザが完全にアイドル状態になるまで待ちます — 非重要なスクリプトに最適です。
Google AnalyticsをPlausibleに置き換えました（< 1KB、プライバシーに焦点を当てた、ほとんどの管轄区域ではクッキー同意が不要）。Hotjarを完全に削除しました — SleepDrは実際にレコーディングをレビューしていませんでした。Facebookピクセルを削除しました。6ヶ月前からFacebook広告の実行を停止していたからです。
不要なサードパーティスクリプトを削除することはWeb開発で最も簡単なパフォーマンス勝利です。これを常に言っています。ほとんどのサイトはチームが積極的に使用していないサービスのスクリプトを読み込みます。
最適化6：CSS最適化（800KB → 35KB）
SleepDrのWordPressテーマはおよそ800KBのCSSを提供しました。これには、テーマのスタイルシート、プラグインスタイルシート、完全なBootstrapグリッドシステム（未使用）、およびFont Awesome（約12のアイコンのための）が含まれていました。
実施内容
自動削除によるTailwind CSS。 Tailwindはビルド時にテンプレートファイルをスキャンし、実際に使用するユーティリティクラスのみのCSSを生成します。本番CSSバンドル：35KB（圧縮：〜8KB）。
// tailwind.config.ts
export default {
content: [
'./app/**/*.{ts,tsx}',
'./components/**/*.{ts,tsx}',
],
theme: {
extend: {
fontFamily: {
sans: ['var(--font-inter)'],
serif: ['var(--font-merriweather)'],
},
},
},
};
12のアイコンについては、インラインSVGを使用しました。アイコンライブラリなし。各SVGは約500バイト。総アイコン重量：〜6KB対Font Awesomeの70KB+。
結果はゼロ描画ブロッキングCSS要求です。TailwindのアウトプットはNext.jsによって初期HTMLペイロードでインライン化されるため、ブラウザすぐにレンダリングを開始できます。
正味への影響：CSS96%削減、FCPとTBT改善の両方に寄与。
ステップバイステップチェックリスト
同様のパフォーマンスの問題に直面している場合、これは物事にアプローチする正確な順序です。これは影響に対する努力比率によって優先順位が付けられます。
フェーズ1：クイックウィン（1週目）
- 10個の最高トラフィックページでLighthouseを実行（モバイルモード）
- 各ページテンプレート上のLCP要素を特定
- すべての画像とiframeに明示的な
widthとheightを追加 - フォール下の画像に
loading="lazy"を追加 - LCP画像に
fetchpriority="high"を追加 - サードパーティスクリプトを監査 — 未使用のものを削除
- 残りのサードパーティスクリプトを
asyncまたはdeferに移動
フェーズ2：フォントとCSS（2週目）
- Webフォントを自己ホスト（外部フォント要求を排除）
- すべての
@font-face宣言にfont-display: swapを追加 - フォントを必要な文字セットのみにサブセット
- CSSを監査 — 未使用のスタイルシートを削除
- アイコンフォントをインラインSVGに置き換え
フェーズ3：JavaScript（3週目）
- 最大のJS依存関係を特定するためのバンドル分析
- 可能であればjQueryを削除
- 非重要なコンポーネントを動的にインポート
- 非本質的なJavaScriptを延期
- ルートごとのコード分割を実装
フェーズ4：インフラストラクチャ（4週目+）
- CDN/エッジデプロイメントオプションを評価
- コンテンツページの静的生成を実装
- 適切なキャッシュヘッダーを設定
- WordPressがボトルネックである場合、最新フレームワークへの完全な移行を検討
その最後のポイント — 完全な移行 — を検討している場合、お問い合わせください。私たちは何度もこの種のプロジェクトを行ってきました。料金ページには、ヘッドレス移行に通常かかる費用の詳細があります。
2026年Core Web Vitalsが意味するもの
2026年3月のGoogleコアアップデートがゲームを変えました。CWVはもはやページごとに評価されず — トラフィックで重み付けされたドメイン全体で集約されます。これは以下を意味します：
- 200のブログ投稿で使用される単一の遅いページテンプレートはサイト全体のランキングをタンクさせます
- 高トラフィックページは集約スコアでより多くの重みを持ちます
- ホームページを最適化してそれで終わりにすることはできません
ロールアウトからの初期データはCWVが低いサイトはおよそ20-35%のオーガニックトラフィック低下を経験したことを示しています。50%以上の損失を見たサイトもあります。回復が最も速かったサイトはページレベルの調整ではなく、インフラストラクチャレベルでパフォーマンスに対処したサイトでした — 個々のページを最適化するのではなく、基盤となるアーキテクチャを修正することで。
これはまさにSleepDrの移行が非常に効果的だった理由です。228個の個別WordPressページを最適化しませんでした。すべてのページがデフォルトで高速になるようにシステム全体を再構築しました。
完全な移行の準備ができていないサイトについては、Astroなどのフレームワークは別の強力なパスを提供します — 特にデフォルトでほぼゼロのJavaScriptを望むコンテンツ量の多いサイトの場合。
| アプローチ | 典型的なコスト | タイムライン | 予想されるLighthouse改善 |
|---|---|---|---|
| WordPress プラグイン最適化（WP Rocket、ShortPixel） | $100-500/年 | 1-2週間 | +10-20ポイント |
| WordPressテーマ置き換え | $2,000-5,000 | 2-4週間 | +15-25ポイント |
| ヘッドレスCMS移行（Next.js/Astro） | $15,000-50,000 | 4-10週間 | +30-60ポイント |
| 完全なプラットフォーム再構築 | $30,000-100,000+ | 8-20週間 | +40-65ポイント |
SleepDrのプロジェクトは228投稿すべての完全な移行、CMS設定、カスタムコンポーネント、パフォーマンス最適化を含む$20,000-25,000の範囲でした。Vercel ホスティングはプロプランで月額$20を実行します。これは共有ホスティング用の年額$300対TTFB 2秒未満に保つことができなかったVercel プロの年額約$740です。
投資利益率？彼らのオーガニックトラフィックは展開から6週間以内に回復し、10週目までに事前低下レベルを超えました。オーガニック検索に依存する事業にとって、移行は最初の四半期以内に回収されました。
FAQ
Core Web Vitalsの改善はGoogleランキングに影響を与えるまでどのくらい時間がかかりますか？ SleepDrおよび同様のプロジェクトでの私たちの経験では、Search Consoleは展開から28日以内に更新されたCWVデータを示し始めます。ランキング改善は通常その後2〜3ヶ月後に続きます。Googleはページを再クロール、実際のChromeユーザーから新鮮なフィールドデータを収集（CrUXデータ）、およびランキングアルゴリズムにそれを考慮する必要があります。一夜にして結果を期待しないでください — しかし四半期以内の測定可能な改善を期待してください。
実際の本番サイトではLighthouseスコア94は実現可能ですか？ はい、ですが最初からの意図的なアーキテクチャの選択が必要です。モバイルで90以上のラボスコアはNext.jsやAstroのような最新フレームワークで達成可能です。サードパーティスクリプトを制御し、画像を適切に最適化し、エッジネットワークにデプロイするとき。重要なのはすべてのコンポーネントはパフォーマンス対応である必要があることです。悪い埋め込みまたは最適化されていないサードパーティウィジェットが1つあれば、70秒に戻すことができます。
WordPressから離れて良いCore Web Vitalsスコアを取得する必要がありますか？ 必ずしも。WordPressサイトは正しいテーマ、積極的なキャッシング（WP Rocket + Cloudflare）、最適化されたホスティング（Kinsta、WP Engine）、およびミニマルなプラグインで良いスコアを得ることができます。現実的には、我々が監査するほとんどのWordPressサイトはモバイルで30-60のスコアです。蓄積されたプラグイン膨張とテーマ オーバーヘッドのため。50以下の場合、プラグイン最適化だけはおそらく75以上に達成することができません。ヘッドレスアプローチ — WordPressがコンテンツAPIとして機能し、フロントエンドフレームワークがレンダリングを処理する — は多くの場合、探索する価値のある中間地点です。
Lighthouseスコアと実際のCore Web Vitalsデータの違いは何ですか？ Lighthouseはラボツール — スロットルされた4Gでミッドティア電話をシミュレートし、合成スコアを与えます。Search ConsoleのCore Web Vitalsはフィールドデータ — 28日ローリングウィンドウにわたってサイトを訪問する実際のChromeユーザーからの実際の測定。Googleはランキング信号にラボスコアではなくフィールドデータを使用します。Lighthouseは問題の診断と修正のテストに有用ですが、あなたの目標は75パーセンタイルのSearch Consoleで緑CWVステータスです。
LCPで最も影響的な単一の最適化は何ですか？
画像最適化。監査するサイトの約60%では、LCP要素は画像です。適切にサイズ変更、WebP/AVIF形式で提供、fetchpriority="high"を追加、および遅延読み込みしないことは、通常LCPを2〜4秒削減します。SleepDrでは、画像最適化だけがLCP改善の約3秒を占めました。
Googleの2026年ホリスティックCWVスコアリングはどのように機能しますか？ 2026年3月のコアアップデート以来、Googleはページごとではなくドメイン全体に渡ってCore Web Vitalsデータを集約します。高トラフィックページは計算でより多くの重みを持ちます。これは、数百のページで使用される遅いブログアーカイブテンプレートはホームページのランキングも引き下げることを意味します。修正はアーキテクチャです — あなたはすべてのページテンプレートがCWVしきい値をパスする必要があります、キーランディングページだけではなく。
WordPressからNext.jsへの移行は通常どのくらいの費用がかかりますか？ SleepDrに同様のコンテンツサイト（200+ページ、標準ブログレイアウト、お問い合わせフォーム、e-commerceなし）については、経験豊富な代理店から$15,000-30,000を予想してください。e-commerce移行はより高く実行されます — 複雑さに応じて$30,000-75,000+。Vercel Proの継続的なホスティングは月額$20です。投資利益率はオーガニックトラフィックがあなたのビジネスにどれだけ価値があるかに依存しますが、CWVの低下からトラフィック低下を経験したサイトの場合、移行は通常3〜6ヶ月以内に回収されます。
モバイルまたはデスクトップLighthouseスコアに焦点を当てるべきですか？ モバイル。常にモバイル優先。Googleはモバイルファーストインデックスを使用し、Lighthouseモバイルスコアリングはデスクトップより著しく厳しいです。制約されたデバイスとネットワーク上のシミュレートのため。モバイルスコアが94の場合、デスクトップスコアはほぼ確実に95以上です。SleepDrのデスクトップスコア99はモバイル最適化のために実施したもの以上のゼロ追加の作業を必要としませんでした。