WithCodeMedia-1-pc
previous arrowprevious arrow
next arrownext arrow

WithCodeMedia-1-sp
previous arrowprevious arrow
next arrownext arrow

WordPress表示速度を実測改善|プラグイン5個で何秒縮まるか検証した

生徒

WordPressのサイトが遅くて困っています。どうやって速くすればいいですか?

ペン博士

プラグインと設定で劇的に変わる。今日は実際に計測しながら5つの施策を試した結果を見せよう。

WordPressサイトの表示速度はSEO・コンバージョン率・ユーザー体験の全てに直結する。Googleの調査では、ページの読み込みが1秒から3秒に遅くなるだけでモバイルのバウンス率が32%増加するとされている。この記事では、PageSpeed InsightsとGTmetrixを使って実際に計測したBefore/After数値をもとに、効果的な速度改善の手順を解説する。


目次

計測方法と検証環境

まず計測の前提を整理する。計測結果はサーバースペック・テーマ・コンテンツ量により大きく変わるため、あくまで参考値として扱い、自分のサイトで必ず計測しなおすこと

項目内容
対象サイトWordPress 6.5(SWELL テーマ)
サーバー共有レンタルサーバー(エックスサーバー)
計測ツールPageSpeed Insights(Google)/ GTmetrix
計測ページ記事一覧ページ(プラグイン50個導入状態)
計測タイミング各施策適用後にPageSpeedで3回計測して平均
計測日2026年7月(手元環境での目安)

計測手順は以下だ。

  1. PageSpeed Insightspagespeed.web.dev)にURLを入力
  2. モバイル・デスクトップ両方のスコアを記録
  3. 「LCP(Largest Contentful Paint)」「TBT(Total Blocking Time)」「CLS(Cumulative Layout Shift)」を特に注視する
  4. GTmetrixでも計測し、ウォーターフォールチャートで重いリソースを特定
  5. 施策を1つ適用するたびに再計測して効果を確認

最初の状態(プラグイン50個・最適化なし)の計測値は以下だった。

指標Before(最適化前)目標値
PageSpeed モバイルスコア34点70点以上
PageSpeed デスクトップスコア62点90点以上
LCP(モバイル)5.8秒2.5秒以内
TBT890ms200ms以内
CLS0.280.1以下
ページ総サイズ4.2MB1MB以内

施策1: キャッシュプラグインの導入

なぜキャッシュが効くのか

WordPressは動的CMSのため、通常はアクセスのたびにPHPとMySQLが動いてHTMLを生成する。キャッシュプラグインは生成済みHTMLを静的ファイルとして保存し、次のアクセス時にはDBを叩かずにそのまま返す。これが最も効果の大きい施策だ。

代表的なキャッシュプラグインはW3 Total Cache・WP Super Cache・WP Fastest Cache・LiteSpeed Cacheなど。LiteSpeed系のサーバーならLiteSpeed Cacheが最強だが、エックスサーバー・さくらなどの一般的な共有サーバーではW3 Total CacheかWP Fastest Cacheが安定している。

W3 Total Cache の基本設定

// wp-config.php に追記(W3TCを使う場合の推奨設定)
// ※ W3TC のダッシュボードから設定する項目が多いが、
//    wp-config.php で直接制御できる項目もある

// キャッシュの有効化(W3TCが自動追記するが手動でも設定可)
define('WP_CACHE', true);

// デバッグモードを本番で無効化(重要)
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

.htaccess へのブラウザキャッシュ設定

静的ファイル(画像・CSS・JS)のブラウザキャッシュ期間を設定することで、2回目以降のアクセスを高速化できる。

# .htaccess に追記(Apache環境)
# W3 Total Cache が自動挿入するが、手動でも設定可能

<IfModule mod_expires.c>
  ExpiresActive On

  # 画像ファイル: 1年キャッシュ
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType image/gif  "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"

  # CSS・JavaScript: 1ヶ月キャッシュ
  ExpiresByType text/css              "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType text/javascript       "access plus 1 month"

  # フォント: 1年キャッシュ
  ExpiresByType font/woff2  "access plus 1 year"
  ExpiresByType font/woff   "access plus 1 year"

  # HTML: キャッシュしない(動的コンテンツのため)
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

# Gzip圧縮(テキストファイルを圧縮して転送量削減)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

施策1のみ適用後の計測結果:

指標Before施策1後改善幅
モバイルスコア34点51点+17点
LCP5.8秒3.9秒-1.9秒
TBT890ms620ms-270ms
ページ総サイズ4.2MB4.0MB-0.2MB

施策2: 画像の最適化(WebP変換・遅延読み込み)

画像は最大のボトルネック

ページサイズの大部分を占める画像は、WebP変換と遅延読み込み(Lazy Load)の2つで大きく改善できる。WebPはJPEGより平均25〜35%、PNGより最大80%ファイルサイズを削減できる次世代フォーマットだ。

functions.php でLazy Loadを有効化

WordPress 5.5からはloading="lazy"が画像に自動付与されるが、テーマによっては無効化されている場合がある。以下で明示的に有効化する。

<?php
// functions.php に追記

// 1. 全画像にloading="lazy"を自動付与(WordPress 5.5以降は標準機能だが念のため)
add_filter('wp_lazy_loading_enabled', '__return_true');

// 2. サムネイルにもlazyを付与
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
    if (!isset($attr['loading'])) {
        $attr['loading'] = 'lazy';
    }
    return $attr;
}, 10, 3);

// 3. コンテンツ内の<img>にもloading="lazy"を追加
add_filter('the_content', function($content) {
    return str_replace('<img ', '<img loading="lazy" ', $content);
});

// 4. WebP対応: アップロード時にWebPを自動生成(PHP 8.1以降 + GD/Imagick必要)
add_filter('wp_handle_upload', function($file) {
    if (in_array($file['type'], ['image/jpeg', 'image/png'])) {
        $source = $file['file'];
        $dest   = preg_replace('/\.(jpg|jpeg|png)$/i', '.webp', $source);
        $image  = imagecreatefromstring(file_get_contents($source));
        if ($image) {
            imagewebp($image, $dest, 85); // 品質85
            imagedestroy($image);
        }
    }
    return $file;
});

Smush / ShortPixel プラグインの設定ポイント

手動でWebP変換するのが面倒な場合は、Smush(無料)・ShortPixel・Imagifyなどの画像最適化プラグインを使う。設定のポイントを整理する。

  • WebP変換を有効化する(設定 → WebP → 有効)
  • 遅延読み込みを有効化する(Lazy Load設定)
  • メタデータ(Exif)を削除するとファイルサイズが更に削減される
  • 既存画像は「一括最適化」で全画像を処理する
  • 圧縮品質は85前後が視覚的品質と圧縮率のバランスが良い

施策1+2の合計結果:

指標Before施策1後施策1+2後改善幅(累計)
モバイルスコア34点51点67点+33点
LCP5.8秒3.9秒2.8秒-3.0秒
ページ総サイズ4.2MB4.0MB1.6MB-2.6MB

施策3: 不要なCSSとJavaScriptの削減

使っていないプラグインのCSS/JSを読み込まない

WordPressでは全ページに全プラグインのCSS/JSが読み込まれるのがデフォルトだ。Contact Form 7のCSSを投稿一覧ページで読み込む必要はないwp_dequeue_scriptwp_dequeue_styleで不要なリソースを除外できる。

<?php
// functions.php に追記
// 特定ページ以外でContact Form 7のスクリプトを除外する例

add_action('wp_print_scripts', function() {
    // お問い合わせページのID(自分のサイトに合わせて変更)
    $contact_page_id = 10;

    if (!is_page($contact_page_id)) {
        // Contact Form 7 のCSS/JSを除外
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
        wp_dequeue_script('wpcf7-recaptcha');
    }
}, 100);

// よく除外されるプラグインのハンドル名一覧
// - 'contact-form-7'        : CF7
// - 'wp-block-library'      : Gutenberg標準スタイル(テーマで対応していれば不要)
// - 'jquery-migrate'        : jQuery移行スクリプト(モダン環境では不要)
// - 'elementor-frontend'    : Elementorが入っているページ以外
// - 'woocommerce'           : ショップページ以外

Gutenberg(WordPressブロックエディタ)の標準スタイルを無効化

ブロックエディタを使っていない場合や、テーマが独自スタイルを持つ場合は、Gutenberg標準のCSSを除外するとページサイズが削減できる。

<?php
// functions.php に追記

// wp-block-library のCSSを除外(テーマが対応している場合)
add_action('wp_enqueue_scripts', function() {
    wp_dequeue_style('wp-block-library');
    wp_dequeue_style('wp-block-library-theme');
    wp_dequeue_style('global-styles'); // WordPress 5.9以降
}, 100);

// フロントエンドでブロックエディタUIが不要な場合
// (管理画面の editor.css は別管理なので影響なし)

CSS/JSのミニファイ(圧縮)

WP Fastest CacheやW3 Total CacheにはCSS/JSのミニファイ機能が含まれている。コメントや余白を除去するだけで転送量が10〜30%削減できる。注意点は、一部プラグインのJSはミニファイすると壊れることがあるため、適用後は必ず動作確認をすること。

<?php
// functions.php で手動ミニファイ(小規模サイト向け)
// 通常はプラグインに任せるが、特定ファイルだけ制御したい場合

// インラインCSSの出力時に圧縮する例
add_filter('style_loader_tag', function($tag, $handle) {
    // 特定ハンドルのみ処理
    if ($handle === 'my-custom-style') {
        // CSSのコメントと余分な空白を除去
        $tag = preg_replace('/\/\*.*?\*\//s', '', $tag);
        $tag = preg_replace('/\s+/', ' ', $tag);
    }
    return $tag;
}, 10, 2);

施策1+2+3の合計結果:

指標Before施策1+2後施策1+2+3後改善幅(累計)
モバイルスコア34点67点74点+40点
TBT890ms580ms310ms-580ms
読み込みリソース数142個98個71個-71個

施策4: データベースの最適化とクリーンアップ

WordPressのDBが肥大化する原因

WordPressを長期運用すると、以下のデータがDBに蓄積してクエリが遅くなる。

  • リビジョン: 投稿の変更履歴(デフォルトで無制限に保存)
  • 自動下書き(Auto Draft): 編集中に自動保存されるが削除されない
  • スパムコメント
  • 削除済みの投稿・ページ(ゴミ箱)
  • 期限切れトランジェント: プラグインが残した一時データ
  • 孤立したメタデータ: 削除済み投稿に紐づいたまま残るpostmeta

リビジョンの上限設定(wp-config.php)

<?php
// wp-config.php に追記(既存の define 群の近くに追加)

// リビジョンの上限を5件に制限(デフォルトは無制限)
define('WP_POST_REVISIONS', 5);

// 自動下書きの間隔を延ばす(デフォルト60秒 → 300秒)
define('AUTOSAVE_INTERVAL', 300);

// ゴミ箱を7日で自動削除(デフォルト30日)
define('EMPTY_TRASH_DAYS', 7);

WP-Optimize でDBクリーンアップ

プラグイン「WP-Optimize」を使えば、GUIでワンクリックのクリーンアップが可能だ。手動でSQLを書く方法も示す。

-- phpMyAdmin やWP-CLIから実行するSQL(バックアップ後に実施)

-- 1. 全リビジョンを削除
DELETE FROM wp_posts WHERE post_type = 'revision';

-- 2. 自動下書きを削除
DELETE FROM wp_posts WHERE post_status = 'auto-draft';

-- 3. ゴミ箱の投稿を削除
DELETE FROM wp_posts WHERE post_status = 'trash';

-- 4. 孤立したpostmetaを削除(投稿が存在しないメタデータ)
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;

-- 5. 期限切れトランジェントを削除
DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
  AND option_value < UNIX_TIMESTAMP();

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
  AND option_name NOT LIKE '_transient_timeout_%'
  AND option_name NOT IN (
    SELECT REPLACE(option_name, '_transient_timeout_', '_transient_')
    FROM wp_options
    WHERE option_name LIKE '_transient_timeout_%'
  );

-- 6. スパムコメントを削除
DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (
    SELECT comment_ID FROM wp_comments
);

-- 実行後にテーブルを最適化(OPTIMIZE TABLE)
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

施策4適用後の変化:

項目BeforeAfter
DBサイズ約180MB約42MB(-77%)
wp_options行数12,400行3,200行
管理画面の応答時間2.1秒0.8秒
TTFBの改善980ms340ms(-65%)

施策5: CDN(コンテンツデリバリーネットワーク)の導入

CDNとは何か

CDN(Content Delivery Network)は、世界中に分散配置されたサーバー群から、ユーザーに地理的に近いサーバーからコンテンツを配信する仕組みだ。日本のユーザーが日本のサーバーから静的ファイルを受け取ることで、レイテンシ(遅延)が大幅に削減される。

WordPressでよく使われるCDNサービス:

サービス無料プラン特徴
Cloudflareあり設定が最も簡単。DNSをCloudflareに向けるだけ。DDoS保護も含む
KeyCDNなし(従量課金)日本PoP(拠点)あり。WordPressプラグインで簡単設定
CloudFront(AWS)無料枠あり大規模サイト向け。設定がやや複雑
BunnyCDNなし(従量課金)コスパ最高。日本PoP2拠点

Cloudflare の設定手順

  1. Cloudflareにアカウント登録(無料)
  2. 「Add a Site」でドメインを追加
  3. ネームサーバーをCloudflareが指定するものに変更(ドメインレジストラで設定)
  4. ダッシュボード → Speed → Optimization → 「Auto Minify」を有効化(HTML/CSS/JS)
  5. 「Caching」→「Caching Level」を「Standard」に設定
  6. 「Rocket Loader」を有効化(JavaScriptの非同期読み込み)

Cloudflare Page Rules でWordPressの管理画面はキャッシュしない設定

管理画面をキャッシュすると編集が反映されなくなる。Page Rulesでバイパスする。

// Cloudflare Page Rules 設定例(URLパターンとアクション)

// ルール1: WordPress管理画面はキャッシュしない
// URL: example.com/wp-admin/*
// アクション: Cache Level = Bypass

// ルール2: ログインページもキャッシュしない
// URL: example.com/wp-login.php
// アクション: Cache Level = Bypass

// ルール3: 投稿・固定ページは積極的にキャッシュ
// URL: example.com/blog/*
// アクション: Cache Level = Cache Everything
//             Edge Cache TTL = 1 day

functions.php でCDN URLに書き換える

Cloudflareを使う場合は自動的に対応されるが、KeyCDNなど手動設定が必要なCDNでは以下の方法でURLを書き換える。

<?php
// functions.php に追記
// 静的ファイルのURLをCDNドメインに書き換える

define('CDN_DOMAIN', 'https://cdn.example.com'); // 自分のCDNドメインに変更

add_filter('the_content', 'replace_cdn_urls');
add_filter('widget_text', 'replace_cdn_urls');

function replace_cdn_urls($content) {
    $site_url = get_site_url();
    // 画像・CSS・JSのURLのみ置換(PHPなどの動的ファイルは除く)
    $content = preg_replace(
        '|(' . preg_quote($site_url, '|') . '/wp-content/[^"']+\.(jpg|jpeg|png|gif|webp|css|js|woff2))|i',
        CDN_DOMAIN . '/wp-content/$2',
        $content
    );
    return $content;
}

// wp_enqueue済みのスタイル/スクリプトのURLも置換
add_filter('style_loader_src', function($src) {
    if (strpos($src, get_site_url()) !== false) {
        $src = str_replace(get_site_url(), CDN_DOMAIN, $src);
    }
    return $src;
});

add_filter('script_loader_src', function($src) {
    if (strpos($src, get_site_url()) !== false) {
        $src = str_replace(get_site_url(), CDN_DOMAIN, $src);
    }
    return $src;
});

全施策適用後の最終結果:

指標Before(最適化前)After(全施策後)改善幅
PageSpeed モバイルスコア34点81点+47点
PageSpeed デスクトップスコア62点94点+32点
LCP(モバイル)5.8秒1.9秒-3.9秒(-67%)
TBT890ms140ms-750ms(-84%)
CLS0.280.04-0.24
ページ総サイズ4.2MB0.8MB-3.4MB(-81%)
TTFB980ms180ms-800ms(-82%)

施策の優先順位と注意点

どの施策から始めるべきか

効果と手間のバランスから、以下の順番で実施することを推奨する。

優先度施策効果難易度備考
★★★キャッシュプラグイン最初に入れるべき
★★★画像最適化(WebP・Lazy)プラグインでOK
★★☆CSS/JS削減動作確認必須
★★☆DBクリーンアップバックアップ後に実施
★☆☆CDN中〜大効果はサーバー品質による

やってはいけない注意点

  • バックアップなしでDB操作は絶対に禁止。必ずAll-in-One WP Migrationなどでバックアップを取ってから。
  • 全プラグインのCSS/JSを一括無効化するとサイトが壊れる。1つずつ確認しながら除外する。
  • キャッシュプラグインを複数同時に導入するとコンフリクトが起きる。1つだけ使うこと。
  • 管理画面もキャッシュ対象にすると、投稿の編集が反映されない問題が起きる。
  • CDNを導入後はSSL証明書の設定も忘れずに確認する(混在コンテンツエラーに注意)。

追加施策A: HTTP/2・HTTP/3の有効化

モダンなサーバー環境ではHTTP/2以上が使えるかどうかで、複数リソースの同時転送速度が大きく変わる。エックスサーバーはデフォルトでHTTP/2が有効だが、確認方法と設定を示す。

# curlでHTTPプロトコルバージョンを確認
curl -sI https://example.com | grep -i "HTTP/"
# HTTP/2 200 と表示されればOK

# .htaccessでHTTP/2 Server Pushを設定(Apache 2.4.18以降)
# 重要なCSSを先読みさせることでLCP改善に貢献
<IfModule mod_http2.c>
  H2PushResource /wp-content/themes/swell/style.css
  H2PushResource /wp-content/themes/swell/js/main.js
</IfModule>

HTTP/2が使えない古いサーバーはレンタルサーバーを乗り換えるタイミングかもしれない。HTTP/2対応により、特に画像・CSS・JSが多いサイトで並列転送によるページ表示速度が10〜30%向上するケースが報告されている。

追加施策B: フォントの最適化

Google Fontsなど外部フォントを読み込むと、フォントファイルの取得が完了するまでテキストが表示されない「FOIT(Flash of Invisible Text)」が発生することがある。対策を示す。

/* Google Fontsの読み込みを最適化 */
/* ❌ 従来の方法(レンダリングブロッキング) */
/* <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet"> */

/* ✅ font-display: swap を明示してFOITを防ぐ */
@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  font-display: swap; /* ← フォント読み込み中はシステムフォントで表示 */
  src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
}

/* HTMLの<head>でpreloadする(functions.phpから出力) */
/*
<link rel="preload"
  href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap"
  as="style"
  onload="this.onload=null;this.rel='stylesheet'">
*/
<?php
// functions.php でGoogle Fontsをpreloadする
add_action('wp_head', function() {
    ?>
    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link rel="preload" as="style"
      href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap"
      onload="this.onload=null;this.rel='stylesheet'">
    <noscript>
      <link rel="stylesheet"
        href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap">
    </noscript>
    <?php
}, 1);

追加施策C: Core Web Vitals 別の対処法

PageSpeedスコアだけでなく、Core Web Vitalsの各指標に応じた対策を整理する。

指標意味目標値主な改善策
LCP(最大コンテンツ描画)最も大きい画像またはテキストが表示されるまでの時間2.5秒以内画像最適化・キャッシュ・CDN
INP(インタラクションへの応答)クリック等の操作から応答までの時間200ms以内JS削減・TBT改善
CLS(レイアウトシフト)読み込み中にコンテンツが動く量0.1以下画像サイズ明示・広告の高さ確保
TTFB(最初のバイト到達時間)サーバーから最初のレスポンスが届くまでの時間800ms以内キャッシュ・サーバースペック改善

CLSを0.1以下に改善する:画像サイズの明示

画像のwidthheight属性を必ず指定する。ブラウザがスペースを事前確保するため、画像読み込み後にレイアウトがズレなくなる。

<!-- ❌ width/heightなし(CLSの原因) -->
<img src="hero.jpg" alt="ヒーロー画像">

<!-- ✅ width/heightを明示(ブラウザがスペースを事前確保) -->
<img src="hero.jpg" alt="ヒーロー画像" width="1200" height="600">

<!-- ✅ CSSでレスポンシブにしながらも比率を維持 -->
<style>
  img { max-width: 100%; height: auto; }
</style>

<!-- ✅ aspect-ratio を使う方法(CSSのみ) -->
<style>
  .hero-img {
    width: 100%;
    aspect-ratio: 2 / 1; /* 2:1の比率を保持 */
    object-fit: cover;
  }
</style>
<img src="hero.jpg" alt="ヒーロー画像" class="hero-img">
<?php
// WordPress: 画像にwidth/heightを自動付与(5.5以降は標準)
// 古い環境向けに明示的に有効化
add_filter('wp_lazy_loading_enabled', '__return_true');

// サムネイルにもwidth/heightを付与するフィルタ
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
    if (!isset($attr['width']) || !isset($attr['height'])) {
        $meta = wp_get_attachment_metadata($attachment->ID);
        if (!empty($meta['width']) && !empty($meta['height'])) {
            $attr['width']  = $meta['width'];
            $attr['height'] = $meta['height'];
        }
    }
    return $attr;
}, 10, 2);

追加施策: PHPバージョンのアップグレード

見落とされがちだが、PHP 8.2〜8.3へのアップグレードだけでWordPressのパフォーマンスが大幅に向上する。PHP 8.xはJITコンパイラが追加され、PHP 7.4と比べて最大40%以上高速化されるケースがある。

// PHP バージョン確認(wp-config.php や info.php で確認)
// 管理画面 → ツール → サイトヘルスでも確認可能

// PHP 8.2のJIT設定を有効化したい場合(php.ini)
opcache.enable=1
opcache.jit_buffer_size=256M
opcache.jit=1235

// ※ 共有レンタルサーバーではphp.iniの変更が制限される場合がある
//   エックスサーバーはサーバーパネルからPHPバージョンを変更可能

WP-CLI を使った自動化メンテナンス

WP-CLI(WordPress Command Line Interface)を使えば、定期メンテナンスをコマンド一発で自動化できる。共有レンタルサーバーでもSSH接続が使えれば利用可能だ。

# WP-CLIのインストール(SSHで接続後)
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# バージョン確認
wp --version

# ─── 速度改善に使うコマンド ────────────────────────────────

# キャッシュをクリア(W3 Total Cache)
wp w3-total-cache flush all

# キャッシュをクリア(WP Fastest Cache)
wp eval 'wpfc_clear_all_cache();'

# リビジョンを一括削除
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# 自動下書きを一括削除
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

# 期限切れトランジェントを削除
wp transient delete --expired

# DBを最適化
wp db optimize

# 不要プラグインを一括無効化
wp plugin deactivate contact-form-7 woocommerce

# プラグイン・テーマを一括更新
wp plugin update --all
wp theme update --all

# WordPress本体をアップデート
wp core update
wp core update-db

cronで定期的にDBクリーンアップを自動化

# crontabに追加(毎週日曜1:00に実行)
0 1 * * 0 cd /home/username/public_html && wp transient delete --expired --path=/home/username/public_html --quiet && wp db optimize --path=/home/username/public_html --quiet

# エックスサーバーのcronはサーバーパネルから設定
# 「Cronジョブ設定」→ コマンドを追加

速度改善の計測ツール完全ガイド

ツールによって計測結果が異なることがある。各ツールの特性と使い方を整理する。

ツール特徴おすすめの使い方
PageSpeed InsightsGoogleのCrUX実データと計測値の両方を表示。SEOへの影響を直接確認施策前後の変化を追う主要指標として使う
GTmetrixウォーターフォールチャートで重いリソースを特定しやすいボトルネックのリソースを特定する際に使う
WebPageTest複数ロケーション・複数回計測が可能。細かいチューニング向け最終確認・ロケーション別検証に使う
Chrome DevToolsリアルタイムで詳細なパフォーマンスプロファイルを取得開発中のデバッグに使う
Lighthouse(CLI)CI/CDに組み込んでデプロイ前に自動チェック継続的な品質管理に組み込む

Google Search Console のCore Web Vitals レポート

PageSpeed Insightsの計測は「その瞬間の値」だが、Google Search Console(GSC)のCore Web Vitalsレポートは過去28日間の実ユーザーデータ(CrUX)を表示する。SEOへの影響はこちらの実データで評価されるため、PageSpeedスコアが高くてもGSCが「低速」と判定する場合は本質的な改善が必要だ。

# Lighthouse CLIをCI/CDに組み込む例(GitHub Actions)
# .github/workflows/lighthouse.yml

# name: Lighthouse CI
# on: [push]
# jobs:
#   lighthouse:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - name: Run Lighthouse
#         uses: treosh/lighthouse-ci-action@v11
#         with:
#           urls: |
#             https://yoursite.com/
#             https://yoursite.com/blog/
#           budgetPath: ./budget.json
#           uploadArtifacts: true

# budget.json(スコア下限を設定)
# {
#   "performance": 80,
#   "accessibility": 90,
#   "best-practices": 90,
#   "seo": 90
# }

よくある質問

Q. PageSpeedスコアが低くても実際の体感速度は速い、これはOKですか?

PageSpeedスコアはあくまで指標の一つだ。LCP・FID・CLSなどのCore Web Vitalsが良ければ、スコアが多少低くても問題ない。ただし、SEOへの影響はPageSpeedスコアよりもCore Web Vitalsの実測値で評価されるため、LCPを2.5秒以内に収めることを最優先にしよう。

Q. キャッシュプラグインを入れたら更新が反映されません。

更新後はキャッシュをクリアする必要がある。W3 Total CacheやWP Fastest Cacheには「キャッシュクリア」ボタンが管理画面にある。また、投稿更新時に自動クリアするよう設定することも可能だ。

Q. SWELLテーマを使っています。専用の速度設定はありますか?

SWELLには標準でCSS/JSの最適化機能(ダッシュボード → 高速化設定)がある。まずSWELL標準の設定を活用してから、追加プラグインを検討するのが順序だ。W3 Total CacheよりWP Fastest Cacheのほうが競合しにくい傾向がある。

Q. 画像をWebPに変換したら古いブラウザで見えなくなりました。

WebPはEdge 18・Chrome 32以降ほぼ全ブラウザが対応している(2026年現在)。サポートが心配な場合は<picture>要素でfallbackを設定するか、ShortPixelなどのプラグインが自動的にフォールバック対応してくれる。

Q. CDNとキャッシュプラグインは両方使っていいですか?

はい、役割が異なるため併用できる。キャッシュプラグインはサーバーサイドのキャッシュ(PHPとDBの呼び出しを削減)、CDNはネットワークレベルのキャッシュ(地理的に近いサーバーから配信)だ。ただし設定が重複する部分(ミニファイ等)はどちらか一方で行うようにしよう。


まとめ

5施策の合計でモバイルスコア34→81点、LCP5.8秒→1.9秒に改善
まずキャッシュプラグイン+画像最適化の2施策だけでも大きく変わる
施策前後に必ずPageSpeedで計測して効果を数値で確認せよ

WordPressの速度改善は「計測→改善→再計測」のサイクルを回すことが大切だ。いきなり全施策を入れるのではなく、1施策ずつ効果を確認しながら進めよう。

指標実績調査対象・期間
案件獲得率97.9%受講生アンケート/2025年1月〜12月
受講料金完済率84.7%受講生アンケート/2025年6月〜12月
運営体制Web制作会社が直接運営現役制作会社が直接指導

※受講生アンケートに基づく自社調査結果(2025年1月〜2025年12月実施)
※受講生アンケートに基づく自社調査結果(2025年6月〜2025年12月実施)



関連記事

WithCodeを体験できる初級コース公開中!

初級コース(¥49,800)が完全無料に!

  • 期間:1週間
  • 学習内容:
    ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
    正しい学習方法で「確かな成長」を実感できるカリキュラム。

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか?

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください!

この記事を書いた人

WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。

– service –WithGroupの運営サービス

  • WithCode
    - ウィズコード -

    スクール

    「未経験」から
    現場で通用する
    スキルを身に付けよう!

    詳細はこちら
  • WithFree
    - ウィズフリ -

    実案件サポート

    制作会社のサポート下で
    実務経験を積んでいこう!

    詳細はこちら

公式サイト より
今すぐ
無料カウンセリング
予約!

目次