



WithCodeMedia-1-pc
WithCodeMedia-2-pc
WithCodeMedia-3-pc
WithCodeMedia-4-pc




WithCodeMedia-1-sp
WithCodeMedia-2-sp
WithCodeMedia-3-sp
WithCodeMedia-4-sp









生徒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月(手元環境での目安) |
計測手順は以下だ。
pagespeed.web.dev)にURLを入力最初の状態(プラグイン50個・最適化なし)の計測値は以下だった。
| 指標 | Before(最適化前) | 目標値 |
|---|---|---|
| PageSpeed モバイルスコア | 34点 | 70点以上 |
| PageSpeed デスクトップスコア | 62点 | 90点以上 |
| LCP(モバイル) | 5.8秒 | 2.5秒以内 |
| TBT | 890ms | 200ms以内 |
| CLS | 0.28 | 0.1以下 |
| ページ総サイズ | 4.2MB | 1MB以内 |
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が安定している。
// 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);
静的ファイル(画像・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点 |
| LCP | 5.8秒 | 3.9秒 | -1.9秒 |
| TBT | 890ms | 620ms | -270ms |
| ページ総サイズ | 4.2MB | 4.0MB | -0.2MB |
ページサイズの大部分を占める画像は、WebP変換と遅延読み込み(Lazy Load)の2つで大きく改善できる。WebPはJPEGより平均25〜35%、PNGより最大80%ファイルサイズを削減できる次世代フォーマットだ。
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;
});
手動でWebP変換するのが面倒な場合は、Smush(無料)・ShortPixel・Imagifyなどの画像最適化プラグインを使う。設定のポイントを整理する。
施策1+2の合計結果:
| 指標 | Before | 施策1後 | 施策1+2後 | 改善幅(累計) |
|---|---|---|---|---|
| モバイルスコア | 34点 | 51点 | 67点 | +33点 |
| LCP | 5.8秒 | 3.9秒 | 2.8秒 | -3.0秒 |
| ページ総サイズ | 4.2MB | 4.0MB | 1.6MB | -2.6MB |
WordPressでは全ページに全プラグインのCSS/JSが読み込まれるのがデフォルトだ。Contact Form 7のCSSを投稿一覧ページで読み込む必要はない。wp_dequeue_scriptとwp_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標準の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 は別管理なので影響なし)
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点 |
| TBT | 890ms | 580ms | 310ms | -580ms |
| 読み込みリソース数 | 142個 | 98個 | 71個 | -71個 |
WordPressを長期運用すると、以下のデータがDBに蓄積してクエリが遅くなる。
<?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」を使えば、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適用後の変化:
| 項目 | Before | After |
|---|---|---|
| DBサイズ | 約180MB | 約42MB(-77%) |
| wp_options行数 | 12,400行 | 3,200行 |
| 管理画面の応答時間 | 2.1秒 | 0.8秒 |
| TTFBの改善 | 980ms | 340ms(-65%) |
CDN(Content Delivery Network)は、世界中に分散配置されたサーバー群から、ユーザーに地理的に近いサーバーからコンテンツを配信する仕組みだ。日本のユーザーが日本のサーバーから静的ファイルを受け取ることで、レイテンシ(遅延)が大幅に削減される。
WordPressでよく使われるCDNサービス:
| サービス | 無料プラン | 特徴 |
|---|---|---|
| Cloudflare | あり | 設定が最も簡単。DNSをCloudflareに向けるだけ。DDoS保護も含む |
| KeyCDN | なし(従量課金) | 日本PoP(拠点)あり。WordPressプラグインで簡単設定 |
| CloudFront(AWS) | 無料枠あり | 大規模サイト向け。設定がやや複雑 |
| BunnyCDN | なし(従量課金) | コスパ最高。日本PoP2拠点 |
管理画面をキャッシュすると編集が反映されなくなる。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
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%) |
| TBT | 890ms | 140ms | -750ms(-84%) |
| CLS | 0.28 | 0.04 | -0.24 |
| ページ総サイズ | 4.2MB | 0.8MB | -3.4MB(-81%) |
| TTFB | 980ms | 180ms | -800ms(-82%) |
効果と手間のバランスから、以下の順番で実施することを推奨する。
| 優先度 | 施策 | 効果 | 難易度 | 備考 |
|---|---|---|---|---|
| ★★★ | キャッシュプラグイン | 大 | 低 | 最初に入れるべき |
| ★★★ | 画像最適化(WebP・Lazy) | 大 | 低 | プラグインでOK |
| ★★☆ | CSS/JS削減 | 中 | 中 | 動作確認必須 |
| ★★☆ | DBクリーンアップ | 中 | 低 | バックアップ後に実施 |
| ★☆☆ | CDN | 中〜大 | 中 | 効果はサーバー品質による |
モダンなサーバー環境では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%向上するケースが報告されている。
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);
PageSpeedスコアだけでなく、Core Web Vitalsの各指標に応じた対策を整理する。
| 指標 | 意味 | 目標値 | 主な改善策 |
|---|---|---|---|
| LCP(最大コンテンツ描画) | 最も大きい画像またはテキストが表示されるまでの時間 | 2.5秒以内 | 画像最適化・キャッシュ・CDN |
| INP(インタラクションへの応答) | クリック等の操作から応答までの時間 | 200ms以内 | JS削減・TBT改善 |
| CLS(レイアウトシフト) | 読み込み中にコンテンツが動く量 | 0.1以下 | 画像サイズ明示・広告の高さ確保 |
| TTFB(最初のバイト到達時間) | サーバーから最初のレスポンスが届くまでの時間 | 800ms以内 | キャッシュ・サーバースペック改善 |
画像のwidthとheight属性を必ず指定する。ブラウザがスペースを事前確保するため、画像読み込み後にレイアウトがズレなくなる。
<!-- ❌ 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 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(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
# 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 Insights | GoogleのCrUX実データと計測値の両方を表示。SEOへの影響を直接確認 | 施策前後の変化を追う主要指標として使う |
| GTmetrix | ウォーターフォールチャートで重いリソースを特定しやすい | ボトルネックのリソースを特定する際に使う |
| WebPageTest | 複数ロケーション・複数回計測が可能。細かいチューニング向け | 最終確認・ロケーション別検証に使う |
| Chrome DevTools | リアルタイムで詳細なパフォーマンスプロファイルを取得 | 開発中のデバッグに使う |
| Lighthouse(CLI) | CI/CDに組み込んでデプロイ前に自動チェック | 継続的な品質管理に組み込む |
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
# }
PageSpeedスコアはあくまで指標の一つだ。LCP・FID・CLSなどのCore Web Vitalsが良ければ、スコアが多少低くても問題ない。ただし、SEOへの影響はPageSpeedスコアよりもCore Web Vitalsの実測値で評価されるため、LCPを2.5秒以内に収めることを最優先にしよう。
更新後はキャッシュをクリアする必要がある。W3 Total CacheやWP Fastest Cacheには「キャッシュクリア」ボタンが管理画面にある。また、投稿更新時に自動クリアするよう設定することも可能だ。
SWELLには標準でCSS/JSの最適化機能(ダッシュボード → 高速化設定)がある。まずSWELL標準の設定を活用してから、追加プラグインを検討するのが順序だ。W3 Total CacheよりWP Fastest Cacheのほうが競合しにくい傾向がある。
WebPはEdge 18・Chrome 32以降ほぼ全ブラウザが対応している(2026年現在)。サポートが心配な場合は<picture>要素でfallbackを設定するか、ShortPixelなどのプラグインが自動的にフォールバック対応してくれる。
はい、役割が異なるため併用できる。キャッシュプラグインはサーバーサイドのキャッシュ(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でWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。
公式サイト より
今すぐ
無料カウンセリング
を予約!