【動作確認済み環境】
・WordPress：6.5以降
・PHP：8.2
・確認日：2026年1月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

最近のWeb制作の現場で、「フルサイト編集でサイトをリニューアルしたけれど、表示速度がいまいち上がらない」というご相談を非常によくいただきます。

FSE（フルサイト編集）は、ブロックエディターを活用してサイト全体を直感的に管理できる優れた仕組みです。しかし、従来のPHPベースのテーマとは内部のレンダリング処理が異なるため、これまでの高速化ノウハウをそのまま当てはめても思うような結果が出ないケースが少なくありません。場合によっては、無理なチューニングが運用時のエディター動作を重くしてしまうこともあります。

この記事では、実際の案件で直面したパフォーマンス低下のボトルネックと、それを解消するために採用している具体的な設計や設定方法を正直にシェアします。読み終える頃には、表示速度と長期的な運用性を両立するための判断基準が明確になるはずです。

【この記事でわかること】
・WordPressにおける実践的な表示速度の指標と計測方法
・フルサイト編集と従来テーマで異なるパフォーマンス低下の原因
・キャッシュ系プラグインに頼る前に見直すべきサーバー設定
・ブロックエディターの動作を重くしないCSSの運用ルール
・長期的な保守を見据えたサイト設計の判断基準

1. 実案件から導き出したWordPress高速化の具体的な指標と計測方法

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：最新
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

WordPressの表示速度改善は、Web制作の現場で常に求められる重要な課題です。特にFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用した構築が増える中、デザインの自由度とパフォーマンスのバランスをどう取るか悩む場面は多いのではないでしょうか。

実際の案件で高速化のご相談を受けた際、ただ何となくプラグインを追加するのではなく、まずは具体的な指標に基づいた現状把握からスタートします。私たちが実務で重視している主な指標は、Googleが提唱するCore Web Vitals（コアウェブバイタル）の3つの項目です。

・LCP（Largest Contentful Paint）：メインコンテンツの読み込み速度
・FID（First Input Delay）またはINP（Interaction to Next Paint）：ユーザー操作への応答性
・CLS（Cumulative Layout Shift）：視覚的な安定性（画面のカクつき）

これらを計測するためのツールとして、Googleが提供しているPageSpeed Insightsを活用します。URLを入力するだけでモバイルとデスクトップ双方のスコアが算出され、改善すべき具体的なポイントがリストアップされるため、クライアントへの報告にも活用しやすいツールです。

以前、画像が多用されたコーポレートサイトの案件で、ページ表示に時間がかかり離脱率が高まっているという課題に直面しました。その際、PageSpeed Insightsで計測したところ、LCPの数値が著しく低いことが判明しました。原因は、ファーストビューで読み込まれる巨大なスライダー画像でした。結果として、画像の適切な圧縮とWebPフォーマットへの変換、そしてLazy Load（遅延読み込み）の設定を調整することで、スコアを大幅に改善することができました。

なぜPageSpeed Insightsのスコアを基準にするのかというと、検索エンジンがサイトを評価する際の公式な指標と連動しているためです。スコアを改善することは、単に表示を速くするだけでなく、長期的なSEO対策やユーザー体験の向上に直結します。

迷ったときは、まず現在のサイトのURLをPageSpeed Insightsで計測し、LCP、INP、CLSのどの項目にボトルネックがあるのかを特定することから始めるのがおすすめです。原因を切り分けることで、FSEのどのブロックが影響しているのか、あるいはサーバー側のレスポンスに問題があるのかが明確になります。

2. フルサイト編集と従来のテーマ開発で異なる表示速度のボトルネック

WordPressの構築において、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの機能）と従来のクラシックテーマとでは、表示速度が低下する原因となるボトルネックの場所が大きく異なります。実案件で高速化のご相談を受けた際、この構造の違いを理解していないと、見当違いのチューニングをしてしまうことがあります。

従来のクラシックテーマでは、主にPHPによるデータベースへの過剰なクエリ（データの呼び出し）や、全ページ共通で読み込まれる重いCSS・JavaScriptファイルがボトルネックになりがちです。とくにfunctions.php（テーマの機能を追加・カスタマイズするファイル）に処理を詰め込みすぎたり、外部ライブラリをページ問わず読み込ませたりすることで、初期表示が遅延するケースをよく見かけます。

一方、FSEを利用したブロックテーマの場合、PHPの処理よりも「DOMツリーの深さ（HTML要素の階層の深さ）」と「インラインスタイルの肥大化」が主なボトルネックになります。ブロックエディター上でグループブロックやカラムブロックを多用してレイアウトを組むと、HTMLのタグが幾重にも入れ子になり、ブラウザの描画処理に負荷がかかります。

なぜこのような違いが生まれるのかというと、FSEではデザインの大部分をtheme.jsonという設定ファイルと各ブロックが持つスタイル情報に依存しているためです。WordPressの内部処理としては、ページを開いたタイミングで必要なブロックのスタイルだけを動的に計算して出力する仕組みになっています。そのため、不要なCSSを読み込まないというメリットがある反面、ブロックのネスト（入れ子）が深すぎると、HTMLの構造が複雑化し、レンダリング（画面描画）に時間がかかってしまうのです。

正直にお話しすると、私自身もFSEを実案件に導入し始めた頃、細かいデザインを再現しようとするあまり、グループブロックの中にさらにグループブロックを配置するような構造を多用してしまった経験があります。結果として、GoogleのPageSpeed Insightsで「過大なDOMサイズの回避」という警告が消えなくなり、表示速度のスコアを落としてしまいました。それ以降は、複雑なレイアウトが必要な部分はカスタムブロックを自作するか、シンプルなCSSグリッドを併用する方針に変更しています。

ここで、それぞれのテーマ構造におけるパフォーマンスチューニングの向き不向きを整理しておきます。

迷ったときは、サイトの要件が「編集の自由度」と「厳密なレイアウト」のどちらに比重を置いているかで判断すると整理しやすいです。自由度を優先してFSEを採用する場合は、ブロックの階層を極力浅く保つコーディング規約を社内やチームで設けることをおすすめします。長期的な保守性や将来性を考慮すると、WordPress本体の開発はFSEに注力されているため、ブロックの仕組みに沿った最適化の手法を身につけておくことが、今後のWeb制作において重要になります。

3. キャッシュ系プラグインの導入前に確認しておきたいサーバー設定の基本

WordPressの表示速度を改善しようとしたとき、真っ先にキャッシュ系のプラグインを導入しようと考える方は少なくありません。実際の案件でも、「プラグインを入れたのに思ったほど速くならない」「逆に管理画面の動作が不安定になった」というご相談をよくいただきます。

実は、プラグインに頼る前に、まずはサーバー側の基本設定を見直すことが重要です。サーバーの土台が整っていない状態でキャッシュ処理を追加しても、根本的な解決にはつながりません。

ここでは、実務で必ず確認している3つのサーバー設定をシェアします。

■ 1. PHPのバージョンとメモリ制限の確認
WordPressはPHPというプログラミング言語で動いています。古いバージョンのPHPを使用していると、それだけで処理速度が低下します。ご利用のサーバーのコントロールパネルから、推奨される新しいバージョン（現在であればPHP 8系など）が適用されているか確認してみてください。

また、PHPのメモリ制限（memory_limit）も重要です。フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を利用するテーマはメモリを消費しやすいため、wp-config.php（WordPressの基本設定ファイル）で制限を引き上げることで、管理画面の動作が改善するケースがあります。

// wp-config.php に追記してメモリ制限を256MBに引き上げる例
// ※編集前に必ずバックアップを取得してください
define( 'WP_MEMORY_LIMIT', '256M' );

■ 2. サーバー側のキャッシュ機能の活用
エックスサーバーやさくらのレンタルサーバ、ConoHa WINGなど、国内の主要なレンタルサーバーでは、サーバー独自のキャッシュ機能や高速化機能が標準で用意されています。プラグインを追加する前に、まずはこれらの設定をオンにしてみてください。サーバー層で処理されるキャッシュは、WordPressのプラグインよりも効率的に動作することが多いです。

■ 3. ブラウザキャッシュの有効化（.htaccessの設定）
画像の読み込み速度を上げるために、訪問者のブラウザにデータを一時保存させる「ブラウザキャッシュ」の設定も有効です。サーバーの動作を制御する設定ファイルである「.htaccess」に記述を追加することで対応できます。

// .htaccess に追記するブラウザキャッシュの設定例
// サーバー環境によっては動作しない場合があるため、検証環境でお試しください
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
ExpiresByType image/webp "access plus 1 months"
ExpiresByType text/css "access plus 1 weeks"
ExpiresByType application/javascript "access plus 1 weeks"
</IfModule>

正直に言うと、以前は細かい設定をすべてプラグイン任せにしていました。しかし、他のプラグインとの競合で画面が真っ白になるトラブルを経験してからは、できる限りサーバー側の設定で解決する方針に変えました。この手法は、現在私たちの保守案件でもデフォルトの対応としています。

キャッシュプラグインは強力ですが、サーバー設定という土台があってこそ活きるものです。迷ったときは、まずサーバーパネルの機能を確認し、それでも不足する場合にプラグインの導入を検討すると整理しやすいです。長期的な保守性や安定稼働を考えると、シンプルな構成を保つことがトラブル防止につながります。

4. ブロックエディターのパフォーマンスを落とさないためのCSS設計と運用ルール

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用する際、CSSの書き方ひとつでサイトの表示速度は大きく変わります。従来のクラシックテーマと同じ感覚でひとつの大きなCSSファイル（style.cssなど）にすべてのスタイルを記述してしまうと、ブロックエディターの利点である「必要なスタイルだけを読み込む」という仕組みを活かしきれません。

ここでは、実務でパフォーマンスを最適化しつつ、保守性を高めるための具体的なCSS設計と運用ルールをシェアします。

theme.jsonをスタイリングの主軸にする

ブロックテーマにおけるスタイリングの基本は、`theme.json`を使用することです。色、タイポグラフィ、余白などのグローバルな設定は、すべてこのファイル内で完結させるのが現在の基本的なアプローチです。

/<strong> theme.jsonの記述例 </strong>/
{
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "primary",
"color": "#0056b3",
"name": "Primary"
}
]
},
"spacing": {
"units": ["px", "em", "rem", "vh", "vw"]
}
},
"styles": {
"blocks": {
"core/button": {
"border": {
"radius": "4px"
}
}
}
}
}

この書き方が推奨される理由は、WordPressが`theme.json`の記述を解析し、そのページで使用されているブロックに必要なCSSだけをインラインで生成・出力してくれるからです。これにより、無駄なCSSの読み込みを防ぎ、レンダリングブロック（ブラウザが画面を描画するのを遅らせる要因）を最小限に抑えることができます。

独自のCSSはブロックごとに分割して読み込む

`theme.json`だけでは表現できない複雑なアニメーションや特有のレイアウトが必要な場合は、追加のCSSを書くことになります。このとき、すべての追加スタイルをひとつのファイルにまとめるのではなく、ブロックごとにCSSファイルを分割して読み込ませる方法が有効です。

/<strong> functions.phpなどでの読み込み例 </strong>/
// 特定のブロックがレンダリングされるときだけCSSを読み込む
add_action( 'init', 'custom_enqueue_block_styles' );
function custom_enqueue_block_styles() {
wp_enqueue_block_style(
'core/quote', // 対象のブロック名
array(
'handle' => 'custom-quote-style',
'src'    => get_theme_file_uri( '/assets/css/blocks/quote.css' ),
'path'   => get_theme_file_path( '/assets/css/blocks/quote.css' ),
)
);
}

内部でこう動いているからこそ、この関数を使用します。`wp_enqueue_block_style`関数を使うと、指定したブロックがページ内に存在する場合のみ、該当のCSSが読み込まれます。

正直に言うと、以前は全部style.cssに書いていました

以前、ある企業サイトの構築案件で、従来のクセが抜けずすべてのカスタムスタイルを数千行に及ぶ`style.css`に記述してしまったことがありました。その結果、トップページでは全く使っていない下層ページ専用の複雑なCSSまで毎回読み込まれ、PageSpeed Insightsのスコアが伸び悩むという問題に当たりました。

その時の解決策が、上記の「theme.jsonの徹底」と「ブロックごとのCSS分割」です。これを実装しただけで、不要なリソースの読み込みが減り、スコアが大きく改善しました。うちでは現在、この設計を案件のデフォルトにしています。

やりがちだけどNGな方法と注意点

エディター画面の「追加CSS」機能や、ブロックごとのカスタムCSS入力欄に大量のスタイルを直書きするのは避けた方がよいです。管理画面から手軽に修正できる反面、どこに何を書いたか分からなくなり、後任の制作者が保守できなくなるというトラブルをよく見かけます。

長期的な保守性を考えると、コードはバージョン管理システム（Gitなど）で追跡可能なファイルとして管理するのが安全です。

CSS設計の使い分けまとめ

WordPressの今後の方向性を見ても、ブロックベースでのリソース最適化はさらに進んでいくと考えられます。迷ったときは、「このCSSは今表示している画面で本当に必要か？」を基準に整理すると、パフォーマンスと保守性を両立したきれいな設計が維持できます。

5. 長期的な保守性を考慮した高速化とフルサイト編集のバランスの取り方

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入しつつ、サイトの表示速度を維持するのは、実務でも悩ましいポイントです。

以前、企業サイトのフルリニューアル案件で、ページ読み込み速度の改善とFSEの導入を両立させる課題に直面しました。
FSEは非常に柔軟なレイアウトが可能ですが、複雑なブロック構成にするとDOM（HTMLの階層構造）が深くなり、描画に時間がかかる傾向があります。
一方で、キャッシュプラグインで強力に静的化しすぎると、動的なブロックの表示が崩れたり、エディターでのプレビューと実際の画面にズレが生じたりするトラブルが起きました。

結果として私たちが選んだ解決策は、「過度なプラグイン依存を減らし、サーバー側のキャッシュ機能とWordPressコアの標準機能を最大限に活かす」というアプローチです。
複雑なCSSやJavaScriptの結合処理はあえて行わず、シンプルな構成を保つことで、長期的な保守性が格段に向上しました。

FSEと高速化のバランスを取る際の目安として、以下の表に整理しました。

迷ったときは、以下のように考えると整理しやすいです。

・速度スコアの数字だけを追わず、実際の体感速度を重視する
・プラグインで無理に最適化するより、使用するブロックの数を減らす
・サーバー自体のスペック見直しも視野に入れる

WordPressのコア機能はバージョンアップのたびにパフォーマンスが改善されています。
長期的に見れば、標準機能から逸脱しないシンプルな設計こそが、最も保守性が高く、結果として高速化につながると感じています。

この記事を読んだ方には、サイト設計の基礎を見直すテーマ選びの解説記事もおすすめです。

Webサイトのパフォーマンス改善や保守性の高い構築についてお悩みの際は、お気軽にeBIZクリエイト株式会社までご相談ください。
https://ebiz-create.co.jp/contact/