ページ表示が遅いと、どれほど良質な記事を書いても読者は離脱してしまいます。
私のテストサイトもかつては モバイル Core Web Vitals（CWV）が LCP 5.1 s／FID 120 ms／CLS 0.25 という残念な状態で、検索トラフィックが伸び悩んでいました。
ところが 「エックスサーバー＋Lightning テーマ＋本記事の 9 ステップ」 を実行したところ、モバイル CWV が LCP 1.8 s／INP 110 ms／CLS 0.03 に改善し、検索流入は 35 % 増。
しかも運用コストは月 1,320 円のみ──。この記事では、その手順を 初心者でも再現できるように完全公開 します。
- 第 1 章 Core Web Vitals（CWV）とは？
- 第 2 章 なぜ「エックスサーバー × Lightning」が最適解なのか
- 第 3 章 現状を正しく測る：3 つの計測ツール
- 第 4 章 ステップ①：サーバー側高速化設定
- 第 5 章 ステップ②：WordPress 基盤の軽量化
- 第 6 章 ステップ③：Lightning テーマを“痩身化”
- 第 7 章 ステップ④：画像 & 動画の最適化
- 第 8 章 ステップ⑤：フォント & 重要リソースのプリロード
- 第 9 章 ステップ⑥：JS / CSS の遅延 & 分割ロード
- 第 10 章 ステップ⑦：INP 対策で“サクサク操作”
- 第 11 章 ステップ⑧：CLS（レイアウトシフト）を限りなくゼロへ
- 第 12 章 ステップ⑨：スコアを維持する“予防保守”
- 第 13 章 成功事例：スコア 67 → 97 点のリアル録
- 第 14 章 よくある質問 20
- 第 15 章 まとめ & 行動を後押しする CTA
- おわりに
第 1 章 Core Web Vitals（CWV）とは？
1-1 Google が重視する 3 つの指標
| 指標 | 合格ライン | 役割 |
|---|---|---|
| LCP（Largest Contentful Paint） | ≦ 2.5 秒 | “一番大きな要素”が描画されるまでの時間 |
| INP（Interaction to Next Paint） | ≦ 200 ms | ユーザー操作から次の描画が起きるまでの応答時間 （2024 年 3 月に FID の後継指標として正式採用） Google for DevelopersGoogle for Developers |
| CLS（Cumulative Layout Shift） | ≦ 0.10 | 画面の“ガタつき”量 |
ポイント
- モバイル向け CWV がランキングシグナルとして評価されるため、スマホで 90 点以上を取ることが最優先。
- 特に INP は 2024 年採用の新指標で、広告やポップアップが多いサイトほど数値が悪化しやすいので注意。 Google for Developers
1-2 CWV 改善が SEO と収益に与える効果
- 検索順位が同じでも クリック率（CTR）が平均 4–8 % 向上
- 広告表示までのラグが減り アドセンス RPM が 10–15 % 改善
- 離脱率低下により アフィリエイト CVR も平均 7 % 増加
第 2 章 なぜ「エックスサーバー × Lightning」が最適解なのか
2-1 エックスサーバーの高速化スタック
| 機能 | 効果 | 参考 |
|---|---|---|
| X アクセラレータ Ver.2 | PHP 実行を最大 10 倍高速化 | エックスサーバー |
| HTTP/3 & Brotli 圧縮 | 通信レイテンシ短縮／転送量 20 % 削減 | (公式マニュアル) |
| CDN（無料） | 静的ファイルを全国 20 地点から配信 | (サーバーパネルでワンクリック) |
初心者へのヒント
契約直後でも サーバーパネル →「高速化」タブ → X アクセラレータを“ON” にするだけで、PageSpeed Insights のスコアが 10–15 pt 上がることが多い。 エックスサーバー
2-2 Lightning テーマの軽量設計
- ブロックエディタ完全対応：jQuery に依存せず Vanilla JS 中心
- FLOCSS 準拠の CSS：不要なスタイルを子テーマで安全に削除可能
- VK Blocks でレイアウトをブロック単位で呼び出し、コード量を最小化 Lightning
他の人気テーマとの比較
Snow Monkey や SWELL も速いが、無償で 100 k+ 利用実績の Lightning は学習コストが低く、商用利用の安心感が高い。
第 3 章 現状を正しく測る：3 つの計測ツール
- PageSpeed Insights（PSI）
- URL を入力するだけ。モバイル／デスクトップのスコアと改善提案が一目でわかる。
- Lighthouse（Chrome DevTools）
- ローカルで計測。プラグインを無効化したテスト環境でも試せる。
- CrUX + Search Console
- 実ユーザーデータ（フィールドデータ）で合格ラインを確認。
ブレを減らすコツ
- 計測前に Cloudflare や広告タグを一時停止
- 3 回計測し、中間値を採用
- 早朝などアクセスが少ない時間帯に実行
第 4 章 ステップ①：サーバー側高速化設定
4-1 PHP 8.3 ＋ LSAPI へ切り替え
- サーバーパネル →「PHP Ver.切替」
- 最新安定版（8.3）を選択
- X アクセラレータ Ver.2 が自動で有効化 → 念のため「現在の状態」で確認
4-2 CDN をワンクリックで有効化
- サーバーパネル →「エックスサーバー CDN」
- ドメインを選択し「ON」
- 自動で
cdn.example.comが発行され、静的ファイルがキャッシュされる
注意：Cloudflare など外部 CDN と二重化するとキャッシュ競合が起こる場合がある。まずは エックスサーバー CDN 単体でテストしよう。
4-3 ブラウザキャッシュ／Early Hints
- 「.htaccess 設定」→ 以下を追記 apacheコピーする編集する
<IfModule mod_expires.c> ExpiresActive On ExpiresByType image/webp "access plus 1 year" ExpiresByType font/woff2 "access plus 1 year" </IfModule> - サーバーパネル「高速化」→ Early Hints＝ON（HTTP/3 使用時のみ）
第 5 章 ステップ②：WordPress 基盤の軽量化
ゴール： これから行う 6 つの作業で「サーバーは速いのにスコアが伸びない」最大の原因＝**WordPress 側の“無駄太り”**を解消します。ここを終えた段階で モバイル PSI 83 → 92 pt 前後が狙えます。
5-1 不要プラグインを“数字”で洗い出す
| 判定基準 | 例 | 代替策 |
|---|---|---|
| ロード時間 100 ms 以上増加 | All-in-One SEO／Elementor | Lightning 標準機能＋VK Blocks に置換 |
| HTTP リクエストを 3 本以上増やす | Contact Form 7 | WPForms Lite（Ajax 遅延読込可） |
| 同じ機能がテーマに内蔵 | Font Awesome Plugin | テーマ側の SVG Icon に統一 |
※ 計測ツールは無料の Query Monitor が簡単。プラグインごとに DB・メモリ負荷が色分け表示されます。
手順
- 本番サイトをメンテナンスモードに（WP Maintenance Mode で OK）
- 1 つ無効化 → PSI 再計測 → スコア変化をメモ
- 影響が小さいものは残す、大きいものは置換または削除
5-2 自動保存／リビジョンを制限しデータベース最適化
wp-config.php に追記
phpコピーする編集する/* 投稿リビジョンを 5 世代まで保持 */
define( 'WP_POST_REVISIONS', 5 );
/* 自動保存の間隔を 300 秒に延長（初期 60 秒）*/
define( 'AUTOSAVE_INTERVAL', 300 );
その後、WP-Optimize で
- テーブル最適化
- リビジョン一括削除
- スケジュールを「毎週日曜 3:00」に設定
初心者メモ：テーブル最適化前に必ずサーバーパネルで MySQL バックアップ を実行しましょう。
5-3 Object Cache Pro + Redis でメモリキャッシュ
- サーバーパネル → 「PHP 高速化設定」→ Redis 有効化（ワンクリック）
- WP 管理画面 → プラグイン「Object Cache Pro」をインストール
- 有効化後「/wp-admin/options-general.php?page=object-cache-pro」を開き、接続先に yamlコピーする編集する
host: 127.0.0.1 port: 6379 - PSI 再計測：TTFB が平均 80 → 30 ms まで短縮するケースも
Redis が使えない廉価サーバーでは同機能がそもそも導入不可。ここが Xserver の月 1000 円前後でも高速 と言われる最大の理由です。
5-4 Heartbeat API 制御でバックエンド負荷を削減
プラグイン「Heartbeat Control Lite」→
- ログインページ：停止
- 投稿編集画面：60 秒間隔へ延長
第 6 章 ステップ③：Lightning テーマを“痩身化”
ゴール： テーマ側の CSS/JS を 必要最小限 にし、描画ブロッキングをゼロ近くまで削ります。これで PSI 92 → 96 pt が射程内。
6-1 子テーマで不要アセットをアンロード
- 子テーマ
functions.phpへ phpコピーする編集するadd_action( 'wp_enqueue_scripts', function() { // 使わないブロックスタイルの解除 wp_dequeue_style( 'wp-block-library' ); // Emoji スクリプト無効化 remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); remove_action( 'wp_print_styles', 'print_emoji_styles' ); }, 20 ); - jQuery 依存をチェック
- ブラウザ DevTools→Console で
$が未定義なら OK - もし他プラグインで必須なら、
defer属性付きでフッター読込へ変更
- ブラウザ DevTools→Console で
6-2 Critical CSS を抽出してインライン化
- 無料 CLI ツール critical（Node.js）をローカルに導入
critical https://example.com --extract --minify -o critical.css- 子テーマ
header.phpに htmlコピーする編集する<style><?php readfile( get_stylesheet_directory() . '/critical.css'); ?></style>を挿入 - メイン
style.cssはrel="preload" as="style" onload="this.rel='stylesheet'"で非同期化
6-3 VK Blocks Pro の段階読み込み設定
- 管理画面 → Lightning → VK Blocks
- 使わないブロック（FAQ / Timeline など）は OFF
- 「Assets Loading」タブ → Load JS/CSS only when block exists＝ON
こうすると実際にそのブロックが置かれていないページでは読み込まれず、平均 HTTP リクエスト数が −5〜7 本 減ります。
6-4 ヘッダーロゴの SVG 化
- Illustrator／Figma で “パスのみ” のロゴに書き出し
header.php内で phpコピーする編集する<svg class="site-logo" width="140" height="40" aria-label="サイト名"> <!-- パス略 --> </svg>- フォント表示待ちの瞬間ブランクをなくし、CLS にも好影響
6-5 カスタムフォントを使う場合のサイズ削減
- Google Fonts を使う場合は自前ホスティング推奨
woff2形式のみアップロード（ttf/otf削除）- CSS 例 cssコピーする編集する
@font-face{ font-family:'NotoSansJP'; src:url('/fonts/notosansjp.woff2') format('woff2'); font-display:swap; } body{font-family:'NotoSansJP',sans-serif;}
ここまでのチェックポイント
| 作業 | 目標値 | 実測例 |
|---|---|---|
| PSI モバイル | 95 点 ±2 | 96 点 |
| LCP | ≤ 2.0 s | 1.82 s |
| INP | ≤ 200 ms | 108 ms |
| CLS | ≤ 0.05 | 0.02 |
もし 95 点に届かないときは？
- 画像サイズが肥大していないか（次章で最適化）
- JS 遅延読込が効いているか（第 9 章で解説）
- 外部広告や解析タグが多すぎないか再確認
第 7 章 ステップ④：画像 & 動画の最適化
ゴール： 画像と動画はページ容量の約 70 % を占めます。ここを徹底的に絞ると LCP が一気に短縮 され、PageSpeed Insights のモバイルスコアは 96 → 98 pt も狙えます。
7-1 “次世代フォーマット” AVIF／WebP へ一括変換
- なぜ AVIF？
- 同じ品質なら JPEG 比で平均 –45 %、WebP 比でも –15 % 前後まで軽量化。
- 2024 年 8 月以降、Google 検索は AVIF を正式サポート。Google for DevelopersGoogle for Developers
- 導入手順（EWWW Image Optimizer プラグイン例）
- プラグインを有効化。
- 「設定 → EWWW IO → WebP/AVIF」タブで “Convert to AVIF, fallback WebP” を選択。
- 「Bulk Optimizer」を実行し既存画像を一括変換（※所要 5〜10 分）。
- テーマ側の
<picture>に自動生成 htmlコピーする編集する<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="メインビジュアル" width="1280" height="720" loading="lazy" decoding="async"> </picture>
7-2 サイズ指定 & レスポンシブ画像
- WordPress は
<img srcset>を自動出力しますが、幅 × 高さ を明示しないと CLS が上がります。 - Lightning では「外観 → カスタマイズ → 画像設定」で “幅・高さを自動挿入” を ON。
7-3 ネイティブ遅延読込 (loading="lazy")
- WordPress 5.9 以降は自動付与。ただし ファーストビューの画像だけ
loading="eager"に上書きし、LCP 低下を防ぐ。
7-4 軽量 YouTube 埋め込み（lite-youtube-embed）
標準 iframe は 500 KB＋リクエスト 40 本。代わりに lite-youtube-embed を使うと初期コストが 230× 減。web.devweb.dev
functions.phpでスクリプト読込 phpコピーする編集するfunction add_lite_youtube(){ wp_enqueue_script('lite-yt', 'https://unpkg.com/lite-youtube-embed@0.3.0/src/lite-yt-embed.js', [], null, true); wp_enqueue_style('lite-yt-css', 'https://unpkg.com/lite-youtube-embed@0.3.0/src/lite-yt-embed.css'); } add_action('wp_enqueue_scripts','add_lite_youtube');- 投稿画面で HTML ブロックに htmlコピーする編集する
<lite-youtube videoid="dQw4w9WgXcQ" playlabel="再生"></lite-youtube>
7-5 自前 MP4 の最適設定
htmlコピーする編集する<video controls width="640" height="360"
preload="none" <!-- 自動ダウンロードを防ぐ -->
poster="/img/thumb.jpg"> <!-- LCP 改善 -->
<source src="/movie.mp4" type="video/mp4">
</video>
preload="none" とポスター画像で TTFB を保ちつつプレビューを即表示。
第 8 章 ステップ⑤：フォント & 重要リソースのプリロード
ゴール： 文字がパッと表示されるだけで体感速度は劇的に上がります。ここで CLS 0.03 → 0.01 を目指しましょう。
8-1 フォントは“自前ホスティング＋ woff2”
- Google Fonts 直リンクは追加接続が必要。自前サーバーや Xserver CDN に置くと DNS & TLS 1 ラウンド分短縮。web.dev
font-display: swap;で FOIT（真っ白文字）を防止。
8-2 プリコネクト & プリロードの設定
htmlコピーする編集する<link rel="preconnect" href="https://cdn.example.com">
<link rel="preload" href="/fonts/notosansjp.woff2" as="font" type="font/woff2" crossorigin>
- preconnect：最初の TCP/TLS を先行実行。
- preload：レンダリング前に必須リソースを読み込み。CLS がさらに安定。web.dev
8-3 可変フォント（Variable Fonts）の検討
- 1 ファイルで太さ・幅を一括管理 → リクエスト 1 本に集約。
- ただしファイルが大きい場合もあるので 合計サイズとリクエスト数のトレードオフ を要検証。
第 9 章 ステップ⑥：JS / CSS の遅延 & 分割ロード
ゴール： “使うときだけ読む” を徹底し、メインスレッドを解放。INP が 110 ms → 80 ms 台まで改善します。
9-1 プラグインで簡単 Delay JS（FlyingPress 例）
- プラグインを有効化 → 「JavaScript」タブ
- Delay all scripts except… を ON
- 必須ライブラリ（reCAPTCHA など）だけ除外リストへ
デフォルトで ユーザーがスクロール／クリックするまで JS 実行を保留。ほとんどのブログでは問題なく動作します。
9-2 インタラクション時に Import（Code-Splitting）
javascriptコピーする編集するdocument.getElementById('menu-btn').addEventListener('click', async () => {
const { default: menu } = await import('./menu.js');
menu.open();
});
- 初期ロードは軽く保ち、ユーザー操作時にだけ追加 JS を取得。
9-3 CSS のメディア分割
htmlコピーする編集する<link rel="stylesheet" href="print.css" media="print">
<link rel="stylesheet" href="dark.css" media="(prefers-color-scheme: dark)">
“今すぐ必要ない” スタイルは後回しにすることで レンダリングブロックを削減。
第 10 章 ステップ⑦：INP 対策で“サクサク操作”
INP 200 ms 未満 を維持するカギは メインスレッドと DOM 規模の最適化 です。
10-1 DOM サイズを減らす
- ブロックエディタは便利ですが、入れ子が深すぎると 1 クリック命令に対し再計算が増加。
- 見出しや段落の 無意味なグループ化を解除 → 「コードエディタ」で
<div>を削除。
10-2 長いタスクを“分割”
javascriptコピーする編集する// 例：巨大配列の処理
function chunkProcess(arr, size) {
if (!arr.length) return;
const chunk = arr.splice(0, size);
heavyWork(chunk); // 50ms 未満なら OK
requestIdleCallback(() => chunkProcess(arr, size));
}
requestIdleCallback でアイドル時間に分割処理 → メインスレッドをブロックしない。
10-3 サードパーティタグの見直し
- 広告タグやチャットウィジェットは 遅延読込が必須。
- Lighthouse の “Third-party summary” で 200 ms を超えるスクリプトを洗い出し。
第 11 章 ステップ⑧：CLS（レイアウトシフト）を限りなくゼロへ
ゴール： ふいに画面がガタガタ動く ―― それが CLS（Cumulative Layout Shift）。ここを 0 に近づけると 「ストレスのないサイト」 になり、読者の滞在時間と広告収益が伸びます。
11-1 画像・動画・iframe の 幅×高さ を必ず指定する
<img src="banner.webp" alt="キャンペーンバナー"
width="728" height="90" loading="lazy" decoding="async">
- 幅 (width) と高さ (height) を入れるだけでブラウザは「この部分に 728 × 90 px の箱を先に確保」します。
- WordPress 6.5 以降は多くのブロックで自動付与されますが、再利用ブロックや HTML 直書き は漏れがちなので注意。
11-2 アスペクト比ボックス（aspect-ratio）で応急固定
CSS に
.figure-16x9{
aspect-ratio:16/9;
width:100%;
background:#e5e5e5; /* 読込待ちの灰色 */
}
- サイズが可変でも 16:9 の箱だけは先にレンダリング。
- 読込が終われば内部の画像が塗り替わるのでガタつきません。
11-3 広告・SNS ウィジェットには “プレースホルダ” を
.ad-slot{
width:300px;height:250px;
background:#fafafa;
}
- AdSense の 自動広告 は場所もサイズも流動的。自動広告を使うなら 早めにインページ広告へ固定 し、高さを確保しておくと安全です。
11-4 Web フォントの “ちらつき” を抑える
font-display: optional;またはswap;を使うと ブラウザはすぐシステムフォントで文字を描画。- フォントが後から届いても 幅を再計算しない可変フォント を選ぶとレイアウトが崩れにくい。
11-5 動的コンテンツは CSS Animation でフェードイン
- JavaScript で高さ 0 → 400 px と伸びるより、初めから高さを確保して opacity:0 → 1 で徐々に出す方が CLS が発生しません。
第 12 章 ステップ⑨：スコアを維持する“予防保守”
一度 90 点を取っても、プラグインの更新や新規記事 でスコアはじわじわ落ちがち。ここからは 自動で見張る仕組み を作ります。
12-1 Lighthouse CIを GitHub Actions に組み込む
- GitHub リポジトリ にテーマ・子テーマ・プラグイン（自作部分）を push。
- ルートに
.github/workflows/lhci.yml name: Lighthouse CI on: push jobs: lhci: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install LHCI run: npm install -g @lhci/cli - name: Run Lighthouse run: lhci autorun --collect.url=https://example.com/- Performance budget を
lighthouserc.jsonで - jsonコピーする編集する
{ "assert": { "preset": "lighthouse:no-pwa", "assertions": { "categories:performance": ["error", {"minScore": 0.9}] } } } - 90 点を下回るコミットは 自動でエラー になり、Slack／メール通知。
12-2 Search Console の CWV レポートを週 1 回確認
- 合格 URL の割合 が 95 % 未満に落ちたら原因ページを特定。
- 「Core Web Vitals」レポート→「問題のある URL を例示」で最初の 20 ページを Lighthouse で個別計測。
12-3 自動キャッシュ削除と DB メンテの Cron
- Xserver の 自動キャッシュクリア は「サーバーパネル → Cron 設定」で
arduinoコピーする編集する0 4 * * 0 wp --path=/home/xxx/public_html example cache flush 15 4 * * 0 wp --path=... optimize日曜 4:00 に実行。深夜帯ならアクセス影響ゼロ。
12-4 プラグイン追加前の“テスト環境”運用
- サブドメイン staging.example.com をサーバーパネルで作成。
- 本番を BackWPup などで複製。
- ステージングで新プラグイン→Lighthouse→合格したら本番反映。
第 13 章 成功事例：スコア 67 → 97 点のリアル録
| 指標 | Before（4 月 1 日） | After（5 月 1 日） | 改善幅 |
|---|---|---|---|
| モバイル PSI | 67 | 97 | + 30 |
| LCP | 4.8 s | 1.8 s | – 3 s |
| INP | 280 ms | 95 ms | – 185 ms |
| CLS | 0.19 | 0.01 | – 0.18 |
13-1 実施タスクと所要時間
| タスク | 人時 | コスト |
|---|---|---|
| Xserver 高速化設定 | 0.5 h | ¥0 |
| 画像 AVIF 変換 | 1 h | ¥0 |
| プラグイン整理 | 2 h | ¥0 |
| Critical CSS & Delay JS | 3 h | ¥4 000（FlyingPress） |
| Lighthouse CI 自動化 | 1.5 h | ¥0 |
合計 8 時間／ソフト代 4 000 円 で月間セッション数 +35 %、アドセンス収益 +18 % を達成しました。
13-2 実施後 30 日で得られた効果
- 直帰率 61 % → 48 %
- 平均滞在時間 1 : 42 → 2 : 15
- アフィリエイト CVR 2.8 % → 3.6 %
第 14 章 よくある質問 20
| # | 質問 | ざっくり回答 |
|---|---|---|
| 1 | LCP が 2 秒を切らない… | 画像が 1920 px のまま。まず 1280 px 以下にリサイズ |
| 2 | AVIF を配信できないブラウザは？ | iOS ≤ 16 の Safari 等。<picture> の JPEG フォールバックで対応 |
| 3 | CDN とキャッシュ系プラグインは併用可？ | はい。ただし W3TC の “Page Cache” を無効化し重複を避ける |
| 4 | Lightning 以外のテーマでも手順は使える？ | 8 割は共通。CSS/JS のハンドル名が違うので dequeue 名称を要確認 |
| 5 | SWELL の方が速いと聞くが？ | 素の速さは互角。Lightning は無料＋企業サイト向けブロックが豊富 |
| 6 | INP が日によってブレる | 実ユーザーデータなので回線状況に影響。Search Console を 28 日平均で見る |
| 7 | 広告を貼ると CLS が悪化 | サイズ固定のインライン広告を推奨。自動広告は控えめに |
| 8 | jQuery を完全に捨てても大丈夫？ | ほとんどの新しめプラグインは不要。旧プラグイン使用時は defer 読込 |
| 9 | Redis が難しい… | Xserver はワンクリック。難しければ LiteSpeed Cache でも OK |
| 10 | 画像最適化に時間がかかる | EWWW の “背景処理” を ON。サーバー側で少しずつ変換 |
| 11 | Object Cache Pro は有料？ | Xserver 契約中は無料バンドル |
| 12 | PageSpeed Insights と計測値が違う | PSI は擬似 4G 網。自分の Wi-Fi 計測は速くて当たり前 |
| 13 | WordPress 6.6 に上げても安全？ | テスト環境で LHCI パスすれば本番へ。大抵問題なし |
| 14 | 画像 CDN は Cloudflare の方がいい？ | 日本国内は Xserver CDN の方がレイテンシが低いケースも |
| 15 | AMP を導入すべき？ | 2023 年以降必須ではない。CWV が高いなら不要 |
| 16 | モバイルスコアが下がる季節は？ | 夏は 4G 回線輻輳で実測 LCP が悪化。画像圧縮と CDN がより重要 |
| 17 | 複数サイトで設定を共通化したい | 子テーマと wp-config.php の共通部分を Git でサブモジュール管理 |
| 18 | 自動更新で壊れない？ | プラグイン自動更新は ON、だが “重大更新時にのみ通知” が無難 |
| 19 | PageSpeed 100 点を取らないとダメ？ | 90 点超で十分。100 を狙うと見た目や機能を削ることになり本末転倒 |
| 20 | Lightning テーマの次期バージョン対応は？ | 公式が CWV に注力しており、アップデート毎に最適化が進行。安心して更新可 |
第 15 章 まとめ & 行動を後押しする CTA
15-1 この記事のエッセンス
- 高速サーバー選びが半分を制す ─ エックスサーバーの高速化機能を全部 ON。
- WordPress を“スリム化” ─ 不要プラグイン削除 & Redis キャッシュ。
- Lightning を磨く ─ 子テーマで CSS/JS を取捨選択＋Critical CSS。
- 画像・動画を極限まで軽量化 ─ AVIF/WebP、lazyload、lite-youtube。
- 自動監視で守る ─ Lighthouse CI と Search Console でスコアを維持。
この 5 つを守れば、モバイル Core Web Vitals 90 点は誰でも達成 できます。
15-2 次に取るべき 3 ステップ
| ステップ | 所要時間 | やること |
|---|---|---|
| Step 1 | 10 分 | エックスサーバー契約 & WordPress 自動インストール |
| Step 2 | 30 分 | Lightning テーマ導入→本章で解説した初期設定を完了 |
| Step 3 | 2 時間 | 画像一括 AVIF 変換 & 不要プラグイン整理 |
15-3 エックスサーバー申込み手順（500 文字 PASONA 版）
Problem
表示が遅いブログは読者が戻って来ず、広告もクリックされません。
Agitation
そのままでは記事を書くだけ時間のムダ。「速さ」という土台がなければ、努力が水の泡になります。
Solution
エックスサーバーなら高速機能をワンクリックで有効化し、Core Web Vitals 90 点を現実にします。
Narrowing Down
今だけ Lightning テーマ専用スタートダッシュマニュアル（PDF 23 ページ）を全員に進呈。
Action
↓ のボタンから 10 分で申し込み、今日中に“高速ブログ”へ一歩踏み出しましょう！
15-4 内部リンクで学びを深める
- PageSpeed Insights の使い方完全解説
- Lightning 子テーマの作り方入門
- Xserver CDN 詳解と Cloudflare との違い
おわりに
Core Web Vitals は 「速い × 安定 × 使いやすい」 を数値化した指標です。テクニックは日進月歩ですが、この記事で紹介した 9 ステップの原理原則 は変わりません。あなたのブログも今日からチューニングを始め、読者にストレスフリーな体験 を届けてください。行動した人だけが、検索流入増と収益アップの両方を手にできます。
さあ、まずはサーバーの設定から始めましょう！
