WordPress Lighthouse スコアが50で停滞？キャッシュプラグインでは解決できない
WordPressのLighthouseスコアが50で止まっている？キャッシングプラグインではこれは修正できません
WP Rocketをインストールしました。Lighthouseスコアは35から52に上がりました。Autoptimizeを追加しました。52から58に。Perfmattersをインストールしました。これで3つのパフォーマンスプラグインを実行しています。それぞれが独自のJavaScriptを追加していて、他のプラグインが追加したJavaScriptによって引き起こされたパフォーマンス問題を修正しているのです。皮肉だと思いませんか？
私は何度もこのまったく同じ状況に陥っています。丸一日をWP Rocketの設定の微調整、クリティカルCSSの生成、スクリプトの遅延実行、画像の遅延読み込み、プリロードの有効化、CDNのセットアップに費やします。Lighthouseを再度実行します。54です。良い日なら58かもしれません。競争相手をチェックします。彼らは90以上です。何が間違っているのか疑問に思います。
ここが重要なポイントです。あなたは何も間違っていません。WordPressのパフォーマンス上限に達しているのです。それは実在し、十分に文書化されており、どのキャッシングプラグインの組み合わせもそれを打ち破ることはできません。問題はあなたの設定ではありません。アーキテクチャなのです。
この記事では、キャッシングがWordPressのパフォーマンスを修正できない理由、メトリクスごとに実際に低いスコアの原因となっているもの、そして実在するクライアント――SleepDr――をLighthouseスコア35から94に移行させた方法を、アーキテクチャを完全に変更することで説明します。
目次
- パフォーマンスプラグインのパラドックス
- レンダーブロッキングCSS：キャッシングはそれをより小さく提供するのではなく、より速く提供する
- JavaScriptのブロートウェア：jQueryとページビルダーの税金
- データベースクエリのオーバーヘッド：最初のリクエストの問題
- サーバーサイドレンダリング：PHPの構造的ボトルネック
- Lighthouseスコアの内訳を理解する
- ケーススタディ：SleepDr移行――WordPressからNext.jsへ
- パフォーマンスを実際に修正するアーキテクチャ
- 移行が有益な場合（そうでない場合）
- FAQ
パフォーマンスプラグインのパラドックス
毎月見る光景をあなたに描写させてください。サイト所有者は、WordPressサイトがLighthouseで35～55のどこかでスコアリングされているという理由で連絡します。彼らはすでにこれらのプラグインのいくつかの組み合わせをインストールしています：
- WP Rocket ($59/年) ――ページキャッシング、CSS/JS縮小化、遅延読み込み
- Autoptimize (無料) ――CSS/JS集約、クリティカルCSS
- Perfmatters ($24.95/年) ――スクリプトマネージャー、データベースクリーンアップ
- Asset CleanUp (無料) ――条件付きアセット読み込み
- Flying Scripts (無料) ――JavaScript実行の遅延
これは5つのプラグインで、その唯一の目的はWordPressがあらかじめ十分に実行することです。それぞれが独自のPHP実行オーバーヘッドを追加します。それぞれが.htaccessに独自のルールを書きます。あるものは微妙な方法で互いに衝突し、実世界の負荷の下でのみ現れます。
最良のシナリオはどうでしょうか？35から65まで到達します。これらのプラグインとそのさまざまな相互作用の調整に40時間以上を費やしたチームを見かけました。つまり、20～30のLighthouseポイントを獲得し、それでも「良い」Core Web Vitalsの閾値に達しないという、開発者時間の1週間――容易に4,000～8,000ドルの労働――です。
そして誰も話さないことはここにあります：これらのキャッシュされたページは返却された訪問者のみを支援します。最初のヒット？まだ遅いです。Googlebotクロール？キャッシュされていないページにおそらくヒットしています。最も重要なトラフィック――検索からの新規訪問者――は最悪の体験を得ます。
レンダーブロッキングCSS：キャッシングはそれをより小さく提供するのではなく、より速く提供する
これはあなたが最初にぶつかる壁で、ほとんどの人が誤解している壁です。
典型的なWordPressテーマはすべての単一ページで200KBから800KBのCSSを読み込みます。私は誇張していません。ここに貢献するものがあります：
- テーマスタイルシート：150-400KB（Divi、Avada、およびElementorテーマは最悪の犯人です）
- プラグインスタイルシート：50-200KB（お問い合わせフォーム、スライダー、ソーシャル共有、SEOプラグイン）
- Googleフォント：30-100KB（使用しない3～5フォントウェイトが読み込まれていることが多い）
- アイコンライブラリ：50-80KB（6つのアイコンのためにFont Awesome全体を読み込む）
ここが重大な統計です：このCSSのおよそ70%は任意のページで未使用です。 ホームページはWooCommerceカートスタイルを必要としません。ブログ投稿はお問い合わせフォームのCSSを必要としません。しかし、WordPressはすべてを、どこでも、すべて一度に読み込みます。
WP Rocketはこれについて何をしていますか？CSSを縮小化（10～15%の節約）し、ファイルを組み合わせてHTTPリクエストを削減し、上記の折り目のコンテンツのクリティカルCSSを生成します。それは本当に役に立ちます。しかし、ブラウザはすべて400KB+をダウンロードします。それはすべてを解析します。未使用のCSSはまだFCPの遅延に寄与します。
WP RocketはあなたのCSSをツリーシェイクすることはできません。ページごとに必要なスタイルを特定して残りを削除することはできません。それはビルド時にHTMLとCSSの関係を理解することが必要です――これはまさに最新のフレームワークが行うことです。
Next.js + Tailwindが実際にこれを解決する方法
Next.jsとTailwind CSSを使用すると、未使用のスタイルはビルド時に削除されます。遅延されません。縮小化されません。完全に削除されます。 ビルドプロセスはテンプレートをスキャンし、実際に使用されているユーティリティクラスを識別し、それらのスタイルのみを含むCSSファイルを生成します。
結果は？総CSSペイロード：サイトあたり15-40KB。ページあたりではなく――サイト全体のために。それは限界的な改善ではありません。それは桁違いの違いです。
/* WordPress: すべてを読み込む */
/* theme.min.css: 387KB */
/* elementor-frontend.min.css: 142KB */
/* woocommerce.min.css: 98KB */
/* contact-form-7.min.css: 12KB */
/* 合計: 639KB CSS、任意のページで~70%未使用 */
/* Next.js + Tailwind: 使用されているもののみをビルド */
/* globals.css: 22KB (サイト全体) */
/* ページあたりのCSS: 0KB追加 (すべてパージされたバンドルにあります) */
JavaScriptのブロートウェア：jQueryとページビルダーの税金
ここはTBT――総ブロッキング時間――が台無しにされるところです。そしてTBTはLighthouseのパフォーマンススコアの30%です。悪いTBTを使って70を超えることは文字通り不可能です。
WordPressはすべてのページでjQueryを提供します。それは縮小化とgzip圧縮で87KBです。メインスレッドで同期的に実行されます。ページにjQuery機能が不要な場合でも、すべてのページロードはこの税金を支払います。
しかし、jQueryは単なる前菜に過ぎません。ここにはWordPressページビルダーサイトのJavaScript予算があります：
| ソース | サイズ（縮小化 + gzip圧縮） | メインスレッド時間 |
|---|---|---|
| jQuery + jQuery Migrate | 87KB + 10KB | 150-300ms |
| Elementorフロントエンド | 180-350KB | 200-500ms |
| WP Rocket (そう、本当に) | 15-25KB | 30-60ms |
| スライダープラグイン | 80-150KB | 100-250ms |
| 分析 + トラッキング | 50-120KB | 80-200ms |
| その他のプラグイン | 50-200KB | 100-300ms |
| 合計 | 462KB - 855KB | 660ms - 1,610ms |
これは、実際のコンテンツがレンダリングされる前に、JavaScriptの実行だけで660ms～1.6秒のメインスレッドブロッキングです。Lighthouseは良いスコアのためにTBT 200ms未満を望んでいます。「改善が必要」のために600ms未満。あなたはすでに吹き出ています。
キャッシングプラグインは何をすることができますか？縮小化（5～10%を節約）、実行の遅延（FCPを支援しますがTBTは同じままです、なぜなら仕事はまだ起こるからです）、およびユーザーインタラクションまでスクリプトの遅延（これは機能を壊し、ユーザーが何かをクリックして500msのために何も起こらない不快な体験を作成します）。
Next.js：jQuery なし、スマートコード分割
Next.jsはjQueryを読み込みません。期間。同等のものはありません。Reactはdom操作を処理し、相互作用のためにすでにバンドルにあります。しかし、本当の勝利は自動コード分割です。
すべてのページはそれが必要なJavaScriptのみを読み込みます。静的な「About」ページは合計30KBのJSを出荷するかもしれません。あなたの対話的な予約フォームページはそのページでのみフォームライブラリを読み込みます。動的インポートは重いコンポーネントをオンデマンドで読み込むことを意味します。
// このコンポーネントがレンダリングされるときのみ予約カレンダーを読み込む
import dynamic from 'next/dynamic'
const BookingCalendar = dynamic(() => import('../components/BookingCalendar'), {
loading: () => <div className="h-96 animate-pulse bg-gray-100 rounded" />,
ssr: false // サーバーバンドルにも含めないでください
})
export default function BookingPage() {
return (
<main>
<h1>相談をスケジュール</h1>
<BookingCalendar />
</main>
)
}
そのssr: falseフラグは、カレンダーのJavaScriptが初期ページ読み込みに存在しないことを意味します。ユーザーはプレースホルダーをすぐに見る、そして対話的なコンポーネントがハイドレーションされます。TBTは最小のままです。
データベースクエリのオーバーヘッド：最初のリクエストの問題
すべてのWordPressページロードはデータベースクエリをトリガーします。少数ではありません。たくさん。
私は昨年のクライアントのサイトにQuery Monitorをインストールしました――かなり標準的なWordPress + WooCommerce + Yoastセットアップ。単一のホームページロードが生成したのはここにあります：
- WordPressコア：8-12クエリ（オプション、ユーザーセッション、書き換えルール）
- Yoast SEO：15以上のクエリ（メタデータ、スキーマ設定、パンくず）
- WooCommerce：20以上のクエリ（製品データ、カート、セッション）
- テーマオプション：10-15クエリ（カスタマイザー設定、ウィジェットデータ）
- メニューレンダリング：5-8クエリ（ネストされたメニュー項目、メタ）
- サイドバーウィジェット：ウィジェットあたり5-10クエリ
合計：単一のページロードで63-80のデータベースクエリ。 200の他のサイトを提供しているMySQLデータベースを備えた共有ホスティング上で？ここでそれがどこに行くかを見ることができます。
WP Rocketのページキャッシングはこれを排除します――キャッシュされたページの場合。しかし、キャッシュは期限切れになります。新しいページは最初のアクセスまでキャッシュされません。WooCommerceカートページはキャッシュできません（ユーザーごとに動的です）。管理ユーザーはキャッシュをバイパスします。そしてGooglebotはしばしばキャッシュから落ちたページにヒットします。
キャッシュされていないすべてのリクエストはデータベースの完全なペナルティを支払います。
Next.js ISR：事前レンダリングされたHTML、リクエスト時のゼロデータベースクエリ
増分静的再生成（ISR）を使用するNext.jsでは、ページはビルド時に静的HTMLに事前レンダリングされます。ユーザーがページをリクエストするとき、サーバーは事前構築されたHTMLファイルを返します。PHPの実行なし。データベースクエリなし。計算なし。
// これはリクエスト時ではなく、ビルド時に実行されます
export async function getStaticProps() {
const posts = await fetchFromWordPressAPI('/wp-json/wp/v2/posts')
return {
props: { posts },
revalidate: 3600 // このページを1時間ごとに再構築
}
}
revalidate: 3600は、ページがバックグラウンドで1時間ごとに再構築されることを意味します。ユーザーは常にインスタント静的HTMLを取得します。コンテンツは新鮮なままです。データベースクエリはビルド中または再検証中に1回だけ実行され、訪問者のすべてのリクエストで実行されません。
ヘッドレスCMS開発を行う場合、WordPressはコンテンツバックエンド――編集者は引き続き使い慣れた管理インターフェースを使用――しかし、フロントエンドは完全に分離されています。データベースはビルドまたは再検証中にのみヒットし、ユーザーリクエスト中にはヒットしません。
サーバーサイドレンダリング：PHPの構造的ボトルネック
TTFB――最初のバイトまでの時間――について話しましょう。これはリクエスト後、応答の送信を開始するまでにサーバーがどのくらい長く取るかです。
WordPressはPHPを実行することによってすべてのページを生成します。簡単なブログ投稿でも必要です：
- Apache/Nginxがリクエストを受け取ります
- PHPプロセスが生成されます（またはプールから再利用されます）
- WordPressブートストラップが読み込まれます（~50ファイル）
- アクティブなプラグインが読み込まれます（各1つ：ファイル読み込み、データベースクエリ、フック登録）
- テーマ関数が読み込まれます
- テンプレート階層が解決されます
- データベースクエリが実行されます
- テンプレートがHTMLにレンダリングされます
- 応答が送信されます
共有ホスティング上で（WordPressサイトの大多数が住んでいる――SiteGround、Bluehost、GoDaddy）、このプロセスは単独でリクエスト後2～4秒のTTFBを取ります。CSSやJavaScript、画像が読み込まれる前に。あなたのユーザーは2秒以上ブランク画面を見詰めています。
管理されたWordPressホスティング（Kinsta、WP Engine、Flywheel）はこれを0.8～1.5sのTTFBに削減します。優れています。それでも悪いです。
Vercelのエッジネットワーク上のNext.js？50-200ms TTFB。 それはVercelが魔法のサーバーを持っているからではありません。計算するものは何もないからです。HTMLはすでに存在します。エッジノードはユーザーに最も近い。直接それを提供します。PHPなし。データベースなし。テンプレートレンダリングなし。
2秒以上のTTFBと100msのTTFBの間のパフォーマンスギャップは、キャッシングプラグインで埋める何かではありません。
Lighthouseスコアの内訳を理解する
ケーススタディを見る前に、Lighthouseが実際に何を測定しているかと、WordPressがなぜそれぞれのメトリクスで苦労しているのかを理解しましょう：
| メトリック | 重み | 何を測定 | WordPress問題 | Next.js解決 |
|---|---|---|---|---|
| TBT | 30% | JSによるメインスレッドブロッキング | jQuery + プラグインJS = 600ms以上 | コード分割 = <50ms |
| LCP | 25% | 最大の見える要素がペイントされた | 遅いTTFB + レンダーブロッキングCSS | 事前レンダリングされたHTML + パージされたCSS |
| CLS | 25% | 視覚的なレイアウトシフト | 寸法のない遅延読み込み画像、動的広告 | next/image with 明示的なサイジング |
| Speed Index | 10% | 時間の経過による視覚的完全性 | 重いCSSがレンダリングをブロック | 最小限のCSS、インスタントHTML |
| FCP | 10% | 最初のコンテンツペイント | レンダーブロッキングリソース | クリティカルCSS インライン、何もブロック |
TBT単独で30%の重みはあなたが1,200ms以上のブロッキング時間に当たっている場合（WordPressで一般的）、あなたはすでにあなたのスコアの近くに三分の一を失っていることを意味します。画像最適化またはキャッシングは補償することはできません。
ケーススタディ：SleepDr移行――WordPressからNext.jsへ
SleepDrは、私が何十回も見た問題を持ってきました。彼らは睡眠健康診療であり、プレミアムテーマ上に構築されたWordPressサイト、予約スケジューリング用のWooCommerce、SEO用のYoast、ページビルド用のElementor、そして――推測したように――WP Rocket、Autoptimize、およびパフォーマンス用のPerfmattersを実行しています。
3つのパフォーマンスプラグイン。Lighthouseスコア：35。
これはビフォーアフターの数字です：
| メトリック | WordPress (以前) | Next.js (後) | 変更 |
|---|---|---|---|
| FCP | 4.2s | 1.1s | -74% |
| LCP | 6.8s | 1.8s | -74% |
| CLS | 0.28 | 0.01 | -96% |
| TBT | 1,200ms | 50ms | -96% |
| TTFB | 2.1s | 0.3s | -86% |
| Lighthouseスコア | 35 | 94 | +169% |
キャッシングプラグインの組み合わせはこれらの結果を達成することはできませんでした。アーキテクチャは変わらなければなりませんでした。各メトリクスを見てみましょう。
FCP：4.2s → 1.1s (-74%)
WordPressスコアの原因： WordPressサイトは2.1sのTTFBを持っていました（共有ホスティング）、その後Elementor、テーマ、WooCommerce、6つのプラグインスタイルシートから580KBのレンダーブロッキングCSS。ブラウザはそのCSSをすべてダウンロードして解析するまで何もペイントできませんでした。FCPはリテラル単にクリック後4秒以上開始できませんでした。
Next.jsの修正： Vercelのエッジから事前レンダリングされたHTML（0.3sのTTFB）。クリティカルCSS <head>にインライン――おおよそ4KB。ブラウザはHTMLを受け取った直後にほぼすぐにコンテンツをペイントします。サイト全体のCSS：28KB、最初のペイント後に非同期で読み込まれます。
LCP：6.8s → 1.8s (-74%)
WordPressスコアの原因： 最大のコンテンツが豊富な要素はヒーロー画像でした。WordPressではElementorの遅延読み込みを通じて読み込まれました（WP Rocketの遅延読み込みと競合しました――はい、彼らはお互いに戦っていました）。画像は遅いTTFB接続で提供される2.4MB PNGでした。LCPはこの巨大な画像がダウンロードを完了するまで完了できませんでした。
Next.jsの修正： next/image自動WebP/AVIF変換、応答型srcset、および上記の折り目の画像の優先読み込みを使用。ヒーロー画像は2.4MB PNGから85KB AVIFに行きました。読み込み順序でこれは優先順位が付けられました――上記の折り目コンテンツの遅延読み込みなし。高速TTFBと組み合わせて、LCPは1.8秒で完了しました。
CLS：0.28 → 0.01 (-96%)
WordPressスコアの原因： 3つの犯人。最初に、明示的な幅/高さ属性なしの画像（Elementorはそれらを動的にCSSでサイズ変更し、リフローを引き起こしました）。2番目に、ページロード後にDOMに自身を注入したクッキー同意バナーは、コンテンツを押し下げました。3番目に、font-display: swapでロードされるWebフォントは、目に見えるテキストリフロー引き起こしました。0.28のCLSは悪いです――Googleは0.1を超える何かを「貧弱」と見なします。
Next.jsの修正： next/imageは幅と高さを強制し、画像が読み込まれる前にスペースを予約します。クッキーバナーはインラインコンテンツではなく、固定オーバーレイとして配置されました。フォントは自己ホストされ、font-display: optionalでプリロードされました。結果：0.01のCLS。事実上ゼロのレイアウトシフト。
TBT：1,200ms → 50ms (-96%)
WordPressスコアの原因： jQuery（87KB + 150ms実行）。ElementorフロントエンドJS（280KB + 400ms）。WooCommerceカートフラグメント（35KB + 80ms）。3つのパフォーマンスプラグインのJavaScript（合計45KB + 90ms）。分析とトラッキング（60KB + 120ms）。さまざまなプラグインスクリプト（100KB + 200ms）。合計：メインスレッドの1秒以上のブロッキング。
Next.jsの修正： jQuery なし。ページビルダーJSなし。予約ウィジェットの動的インポート。next/scriptでstrategy="lazyOnload"を使用して読み込まれた分析。ホームページの総JavaScript：62KB。TBT：50ms。これは96%削減です。
TTFB：2.1s → 0.3s (-86%)
WordPressスコアの原因： SleepDrはSiteGround共有ホスティングにありました。キャッシュされていないすべてのリクエストはWordPressブートストラップ、プラグイン読み込み、60以上のデータベースクエリ、およびPHPテンプレートレンダリングをトリガーしました。WooCommerceカートダイナミクスのため、キャッシュの無効化は頻繁に起こりました。実際のユーザーのための平均TTFB：2.1秒。
Next.jsの修正： VercelのグローバルエッジネットワークにデプロイされたStaticページ。ISRは、コンテンツ更新を処理します――ページは30分ごとにバックグラウンドで再生成されます。ユーザーリクエストは常にユーザーに最も近いエッジノードで事前構築されたHTMLにヒットします。TTFBは0.3s平均に低下し、いくつかの地域は100msサブを見ました。
パフォーマンスを実際に修正するアーキテクチャ
SleepDr移行は、ヘッドレスWordPressパターンと呼ぶものを使用しました。WordPressはCMS――SleepDrチームはまだwp-adminにログインし、Gutenbergでコンテンツを書き、WooCommerceで予約タイプを管理します。コンテンツ管理側では何も変わりませんでした。
しかし、フロントエンドは完全にNext.jsです。ビルドプロセスはREST APIを介してWordPressからコンテンツをプルし、静的ページを生成し、Vercelにデプロイします。コンテンツエディターがWordPressで公開し、Webhookが再検証をトリガーし、更新されたページは30秒以内にライブです。
同様のアプローチを検討しているチームの場合、Astroは評価する価値のある別のオプションです――特にコンテンツが豊富で相互作用が最小限なサイト。AstroはデフォルトでゼロのJavaScriptを出荷します。これはLighthouseスコアをさらに高くプッシュできます。
重要な洞察：私たちはWordPressを最適化しませんでした。遅い部分を交換しました（PHPレンダリングとフロントエンド配信）うまく機能する部分を保ちながら（コンテンツ管理）。
移行が有益な場合（そうでない場合）
すべてのWordPressサイトがNext.jsに移行すべきだと言うつもりはありません。それは不誠実です。ここに私の正直な評価があります：
移行が有益な場合：
- あなたのLighthouseスコアは最適化努力にもかかわらず60未満で止まっています
- パフォーマンスは直接収益に影響します（eコマース、リード生成、SaaSマーケティングサイト）
- あなたは$200以上/月のために許容できるスピードを取得しようとして管理されたWordPressホスティングを支払っています
- あなたの開発チームはReact/JavaScriptで快適です
- SEOランキングはCore Web Vitals失敗から苦しんでいます
移行が有益ではない場合：
- あなたは個人ブログまたは小さいブロシュアサイトです（投資は利益を出しません）
- あなたのコンテンツチームはAPI同等のないWordPress固有のプラグインに大きく依存しています
- あなたは60-70 Lighthouseで幸せであり、あなたのCore Web Vitalsは合格します
- あなたの予算は移行のための$15,000以下です
移行が有益な場合、典型的な投資は複雑さ、テンプレート数、およびカスタム機能によっては$15,000-$50,000以上です。私たちは価格ページでアプローチと典型的なプロジェクト構造の詳細を説明しました。
ROI計算は簡単です：貧弱なパフォーマンスがあなたに月当たりXに変換をコストし、移行がYをコストする場合、あなたはあなたのペイバック期間を知っています。SleepDrの場合、改善されたページスピードは最初の四半期内に予約の34%増加に貢献しました。
FAQ
WP Rocketは本当にWordPressのLighthouseスコアを修正できないのですか？
WP Rocketは本当に利用可能な最高のWordPressキャッシングプラグインの1つです。キャッシング層ができることをすべてしています――ページキャッシング、縮小化、遅延読み込み、CDN統合、クリティカルCSS生成。しかし、それはWordPressのアーキテクチャの制約の中で動作します。あなたのスコアが50未満の場合、WP Rocketは典型的にあなたを55-65に到達させることができます。80以上一貫して取得することは、レンダーブロッキングCSS、jQuery依存性、およびWP Rocketが単純に排除できないPHPレンダリングオーバーヘッドを削除する必要があります。それは配信を最適化します。それはアーキテクチャを再構成することはできません。
キャッシングプラグインでWordPressは現実的に何のLighthouseスコアを達成できますか？
よく最適化されたセットアップでは――軽量テーマ、最小限のプラグイン、WP Rocketが完全に設定、Kinstaまたはwp Engineのような管理ホスティング――あなたは現実的にモバイルLighthouseで65-75に当たることができます。デスクトップスコアはより高くなります（80-90）テストデバイスはより多くの処理能力を持っているからです。モバイルで一貫して80以上を取得することは、非常に最小限のWordPressセットアップ（ほぼプラグインなし、カスタムテーマ）またはアーキテクチャ変更が必要です。ElementorまたはDiviのようなページビルダーを持つサイトは典型的に50-65で最大化されます。
WordPressからNext.jsへの移行にはいくらかかりますか？
コストはサイトの複雑さに基づいて大きく異なります。簡単なブロシュアサイト（5-15ページ、ブログ、お問い合わせフォーム）は$15,000-$25,000を実行します。中程度の複雑さのサイト（カスタム投稿タイプ、複数のテンプレート、統合）は$25,000-$40,000を実行します。ユーザーアカウント、動的データ、サードパーティ統合を持つeコマースまたは複雑なWebアプリケーションは$40,000で始まります。これらは証明されたヘッドレス経験を持つ代理店のための2025年の市場率です。あなたのサイトに基づいて具体的な見積もりのために私たちに連絡してください。
ヘッドレスWordPressは、あなたのコンテンツチームが新しいツールを学ぶ必要があることを意味しますか？
いいえ。それはポイント全体です。あなたのコンテンツチームはwp-admin、Gutenberg、ACF、または彼らが慣れていることを使用し続けます。唯一の見える変更は、彼らが瞬間にコンテンツ更新を見ることができるのではなく、ISR再検証のため30-60秒待つ必要があるかもしれません。いくつかのチームはこれはほとんど気付かないそれを見つけます。編集体験はほぼ同じです。
TBTとFCPの違いは何であり、両方が重要なのはなぜですか？
FCP（最初のコンテンツペイント）はユーザーが何かを見たときを測定します――どんなコンテンツでも。TBT（総ブロッキング時間）はFCPとTime to Interactive間のJavaScript実行によるメインスレッドがブロックされている期間を測定します。あなたはまともなFCPを持つことができますが、恐ろしいTBT、コンテンツが見えることが意味するユーザーがすぐにそれと相互作用できない。これはWordPressサイトで一般的です、そこで、HTMLキャッシュから素早くレンダリングしますが、800KB以上のJavaScriptが次に実行されます。両方のメトリクスは重要です、なぜなら彼らはどちらがあなたのLighthouseスコアの40%を表すが（TBT 30%、FCP 10%）一緒にそれらは素早くコンテンツの見え方と相互作用両方を表すからです。
Next.jsへの移行はSEOランキングを一時的に傷つけるでしょうか？
正しく行われれば、いいえ。重要なのはURL構造を維持し、変更されるすべてのURLに適切な301リダイレクトを実装し、すべてのメタデータを保存し、XMLサイトマップが正しいことを確認することです。私たちは典型的に1-2週間安定化期間を見ます。ランキングはわずかに変動し、その後改善がGoogle認識の改善がされた後のこのとして立派になるかは良いCore Web Vitals。SleepDrは移行中ランキングドロップを見ませんでした、6週間内のポジションを得ました。リスクはずさんな移行――壊れたリダイレクト、欠落ページ、リダイレクトなしの変更されたURL構造――から来ます。
代わりにAstroを移行のために使用できますか？
絶対に。Astroは、限定された相互作用とコンテンツが豊富なサイトのための優れた選択肢です。AstroはデフォルトでゼロのJavaScriptを出荷し、対話的なコンポーネント――彼らのコール「島嶼建築」のみハイドレーション。ブログ、ドキュメンテーションサイト、またはマーケティングサイトのような、ほとんどのページが静的コンテンツであるサイトの場合、Astroは次.jsよりさらに優れたLighthouseスコアを達成できます。私たちは、重要な相互作用が必要な場合（ダッシュボード、予約システム、eコマース）の次.jsを推奨し、コンテンツが主要な場合はAstro を推奨します。
Lighthouseスコアの改善は投資の価値がありますか？
それはあなたのサイトが何であるかに完全に依存します。個人ブログの場合、おそらく。あなたのビジネスで、オーガニック検索トラフィックが収益を運ぶ場合、数学は強力です。Googleは確認されているCore Web Vitalsをランキング要因として。2024-2025の研究は、LCPの100msごとの改善が1.1%変換率増加とeコマースサイトに相関していることを示しています。あなたのサイトが月当たり$50,000の収益を生成し、10-15%の変換改善が月当たり$5,000-$7,500を追加する場合、$30,000移行は4-6か月でそれ自体を支払うことになります。あなたは自分の数字を実行してください――答えはあなたのビジネスに常に特定されます。