WordPressで記事を執筆していると、気づかないうちにデータベース（DB）が肥大化し、サイトの動作が重くなってしまうことがあります。その大きな原因の一つが「リビジョン」機能です。

この記事では、リビジョン機能のメリット・デメリットから、適切な保持数の目安、さらにはwp-config.phpやfunctions.phpを使ったカスタマイズ方法まで分かりやすく解説します。

WordPressのリビジョン機能とは？

機能の概要

WordPressのリビジョン（Revision）とは、記事（投稿や固定ページ）を保存・更新するたびに、過去のデータを自動的にバックアップとして保存しておく機能です。

• リビジョンの目的: 「編集前の状態に戻したい」「ブラウザが急に閉じてデータが消えた」という際、過去のセーブポイントからデータを復元できます。
• 初期状態の挙動: wp-config.php等に設定がない場合、WordPressのデフォルトは「制限なし（無限保存）」です。1つの記事を100回更新すれば、100件分のデータがデータベース（wp_posts テーブル）にそのまま蓄積されます。

リビジョンへのアクセス方法

ブロックエディターの使用中、サイドバーに「リビジョン」の項目がある場合、そちらからアクセスいただけます（「2」などの数値をクリックくださいませ）。

その後、以下のような画面が現れます。画面上部のツマミを動かし、戻したい箇所で「このリビジョンを復元」を押下すれば、その時点でのリビジョンが復元されます（復元後に「保存」いただくことが必要です）。

補足

WordPress 7.0以降、一部の環境においてはリビジョン表示の画面が以下のように変わります。

リビジョン数を制限するメリット・デメリット

無限に増え続けるリビジョンを「最大〇個まで」と制限することには、以下のような一長一短があります。

メリット

• データベースの軽量化
  不要な過去データが激減するため、データベースの容量肥大化をピンポイントで防げます。
• サイト動作・管理画面の高速化
  データベースが軽くなることで、記事の読み込みや検索、管理画面の切り替えなどがスムーズになります。
• バックアップ効率の向上
  サイト全体のバックアップデータが小さくなり、保存先のストレージ節約や実行時間の短縮につながります。

デメリット

• 古い履歴に遡れなくなる
  例えば上限を「5個」にした場合、6回以上更新すると、一番古い（最初の頃の）編集データは自動的に消去され、復元できなくなります。
• 大幅なリライト（書き直し）時に不便
  長文を何度も推敲しながら書き直す場合、「数日前のあの文章に戻したい」と思っても、上限を超えていると過去データが残っていません。

適切なリビジョン数の目安

一般的には、運用バランスが最も良い「3個 〜 10個」への制限が推奨されます。自身の運用スタイルに合わせて以下の目安を参考にしてください。

リビジョン数を制限・カスタマイズする3つの方法

サイトの構成やスキルに合わせて、以下の3つの方法から選択して設定を行います。

方法①：サイト全体を一括制限する（wp-config.php）

サーバーへの負荷が最も少ない制限方法です。サイトのルートディレクトリにある wp-config.php を編集します。

ファイル内の /* 編集が必要なのはここまでです... */ という記述よりも上に、以下のいずれかのコードを追記します。

• 数を「5個」に制限したい場合：define( 'WP_POST_REVISIONS', 5 );
• 機能を完全に「無効」にしたい場合：define( 'WP_POST_REVISIONS', false );

//　記述例
define( 'WP_POST_REVISIONS', 5 );

/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */

方法②：投稿タイプごとに保存数を変える（functions.php）

「通常のブログ記事は10個でいいけれど、重要な固定ページは5個残したい」「カスタム投稿『ニュース』は3個にしたい」といった場合は、子テーマの functions.php にフィルターフックを記述します。

functions.php の末尾に以下のコードを追記してください。

/**
 * 投稿タイプごとにリビジョンの保存数を変更する
 */
function custom_revisions_to_keep( $num, $post ) {
    
    // 通常の「投稿 (post)」は 10個
    if ( $post->post_type === 'post' ) {
        return 10;
    }
    
    // 「固定ページ (page)」は 5個
    if ( $post->post_type === 'page' ) {
        return 5;
    }
    
    // カスタム投稿タイプ「お知らせ (news)」は 3個
    if ( $post->post_type === 'news' ) {
        return 3;
    }
    
    // カスタム投稿タイプ「制作実績 (portfolio)」はリビジョン無効
    if ( $post->post_type === 'portfolio' ) {
        return 0;
    }

    // 上記の条件に該当しないその他の投稿タイプは一律5個にする
    // ※wp-config.php で設定したデフォルト数値にしたい場合は return $num; に変更してください。
    // 　なお、wp-config.php で無設定の場合は「無限保存」となります。
    return 5; 
}
add_filter( 'wp_revisions_to_keep', 'custom_revisions_to_keep', 10, 2 );

方法③：プラグインで手軽に管理する

コードを触るのが不安な場合や、「すでに溜まってしまった過去のリビジョンを掃除したい」という場合は、プラグインの導入が手軽です。

• WP Revisions Control
  シンプル設計のプラグイン。管理画面の「設定」から、投稿タイプごとの保持数を数字で入力するだけで制限できます。余計な機能が要らない場合はこちらで十分です。
• WP-Optimize / LiteSpeed Cache
  リビジョン数の制限だけでなく、データベース内にすでに溜まっている過去の大量のリビジョンを一括クリーンアップ（削除）する機能が備わっています。中級者・上級者向けのプラグインのため、触り始めのときに導入いただくことはおすすめしません。
  特に LiteSpeed Cache は導入環境が限定されておりますので、注意が必要です。

まとめ

WordPressのリビジョンは強力で便利なバックアップ機能ですが、初期状態の「無限保存」のまま運用を続けると、サイトのパフォーマンス低下を招きます。

リビジョンの制限を事前に行っておくだけで、データベースが劇的に軽くなり、WordPressサイトを長期にわたって快適に維持できるようになります。ぜひご自身のサイトでも設定を見直してみてください。

解決すべき問題

HTMLでは、1ページにつき1箇所のH1見出しを配置することが強く推奨されています（2箇所以上配置すべきかそうでないかといった問題はしばしば論争となりますが、本記事では問題にしません）。

ただ、フロントページの場合、記事一覧のみが表示されているなどの状況になりやすく、H1見出しがページ内に配置されない状況が発生しやすいです。そのため、意図的にH1タグの含まれたページをフロントページとして作成するなどの対応が必要になります。

サイトのロゴの箇所をH1見出しとして扱うのも1つの方法です。ただ、サイトロゴの箇所は<h1>タグではなく<div>タグなどで囲われている場合が主流のため、大多数の環境では一工夫する必要がございます。

「サイトロゴ」をH1化する対応策

プラグイン「VK Blocks」にて対応する方法

Vektor社が提供しているプラグイン「VK Blocks」では、バージョン v1.119.0より、フロントページのみ、「サイトロゴ」ブロックがH1である旨の設定ができるようになりました。

詳しくは以下のページをご確認くださいませ。

• VK Blocks 1.119.0 でサイトロゴブロックにh1を指定できるようになりました。 | 株式会社ベクトル

対策済みのテーマを使う

例えば、以下のテーマでは、H1タグが記事箇所等に存在しない場合、サイトロゴ箇所がDIVからH1見出しに切り替わるようになっています。

• Xwrite
• SWELL
• Cocoon
• Lightning

上記のようなテーマを利用できるのであれば、そちらを利用するのが手っ取り早いと思います。

functions.php に追記する方法（上級者向け）

上記のような環境・解決方法を取り入れるのが難しいようであれば、以下のようなコードを子テーマの functions.php 等に追記いただくのが手っ取り早いと思います。

/**
 * サイトロゴブロックの出力をトップページとそれ以外で切り替える
 */
add_filter( 'render_block', function( $block_content, $block ) {
    // サイトロゴブロック（core/site-logo）が対象
    if ( 'core/site-logo' === $block['blockName'] ) {
        if ( is_front_page() ) {
            // トップページなら h1 で囲む
            return '<h1>' . $block_content . '</h1>';
        } else {
            // それ以外なら div で囲む
            return '<div>' . $block_content . '</div>';
        }
    }
    return $block_content;
}, 10, 2 );

/**
 * サイトロゴブロックの出力をトップページとそれ以外で切り替える
 */
add_filter( 'get_custom_logo', function ( $html ) {
    if ( is_front_page() ) {
        // トップページ：ロゴ全体を h1 で囲む
        $html = sprintf(
            '<h1 class="custom-logo-wrapper">%1$s</h1>',
            $html
        );
    } else {
        // それ以外：ロゴ全体を div で囲む
        $html = sprintf(
            '<div class="custom-logo-wrapper">%1$s</div>',
            $html
        );
    }
    return $html;
} );

補足：運用でのカバーも検討する

サイトロゴの箇所がH1にならなくとも、上記に書いたとおり、記事エディター内にH1見出しを意図的に設置することによっても対応することが可能です。

実際、当ブログのトップページでも、「サイトロゴ」画像ではなく別の箇所をH1見出しとしています。

結局のところ、最後にものを言うのは、運用方針や「どのように組み立てていくか」というところだと思います。既存の事例を参考にしながらも、「どうしたいか」は大切にしたいものでございます。

WordPress標準の「タグ」の仕様について

インストール時点において、タグのアーカイブのページでは「カスタム投稿タイプ」の記事が表示されないようになっています。プラグイン「Custom Post Type UI」などでいくら設定しようとしても、うまくいかないのですね。

実を申し上げますと、「タグアーカイブ」を表示しようという場合に、標準の「投稿」以外は表示しないよう、WordPress側で自動制御されております。

そのため、functions.php等にコードを追記する必要がございます。

functions.php等に追記するコード

function add_cpt_to_tag_archive( $query ) {
    if ( !is_admin() && $query->is_main_query() && is_tag() ) {
        $query->set( 'post_type', array( 'post', 'your_cpt_slug' ) );
    }
}
add_action( 'pre_get_posts', 'add_cpt_to_tag_archive' );

コードの意味

• add_action()：WordPressであらかじめ設定されているアクションフックについて、コードを追加で適用するための関数です。
• if ( !is_admin() && $query->is_main_query() && is_tag() ) { ... } ：通常 !is_admin() （管理ページでないか）および is_tag() （タグアーカイブページかどうか）で判定できそうな気もしますが、こちらがメインクエリに手を加える処理であるため、そもそもメインクエリ処理であるかどうか確認するために $query->is_main_query()も条件に加えています。
• array( 'post', 'your_cpt_slug')：your_cpt_slug にはカスタム投稿タイプのスラッグを記載してください。
• 複数のカスタム投稿タイプに標準のタグを設定したい場合は、例えば3行目の箇所を以下のように記載してください（コンマ記号は省略しないようにお願いします）。
  $query->set( 'post_type', array( 'post', 'cpt_slug_1' , 'cpt_slug_2', 'cpt_slug_3') );
• pre_get_posts ：メインクエリに変更を加えるのに使用するアクションフックです。

関連リンク

• WordPressのクエリを正しく扱う ― pre_get_postsの仕組みと使い分け – Cleysense
• WordPress開発者必見！pre_get_postsでクエリを自在に操るチートシート | Edel Hearts

インストール直後のWordPressでは、コメント欄について見出しなどの箇所を変更としたいと思うことがあるかもしれません。特に「コメントを残す」¹という見出しの文言については違和感を覚える方も多いのではないでしょうか。

その箇所については functions.php にコードを追記することによって簡単に実現可能です。

例1：見出しを変更したい場合

functions.php に追記するコード

function custom_comment_form_text( $defaults ) {
	$defaults['title_reply'] = 'コメントはこちらからどうぞ'; // 好きな文言に変更
	return $defaults;
}
add_filter( 'comment_form_defaults', 'custom_comment_form_text' );

コードの意味

• add_action()：WordPressであらかじめ設定されているアクションフックについて、コードを追加で適用するための関数です。
• $defaults['title_reply']：こちらの変数に値を代入することにより、コメント欄見出しの文言の変更が可能です。
• comment_form_defaults：コメントフォームのデフォルト設定を司っているフックです。

例2：その他の箇所も含めて変更したい場合

functions.php に追記するコード

function custom_comment_form_text( $defaults ) {
	$defaults['title_reply'] = 'ご感想をどうぞ';
	$defaults['title_reply_to'] = '%s さんへの返信';
	$defaults['cancel_reply_link'] = '返信をやめる';
	$defaults['label_submit'] = '送信する';
	return $defaults;
}
add_filter( 'comment_form_defaults', 'custom_comment_form_text' );

対応表

上記コードの $defaults['xxx'] について、xxxの箇所は以下のとおり対応しています。

詳細情報（技術的なもの）はこちら

• comment_form() – Function | Developer.WordPress.org

要約（主な配列キー）

脚注

1. 恐らく英語版デフォルトの「Leave a Reply」をほぼ直訳したものと思われます。 ↩︎
2. %s にはコメントを入れた方の名前が入ります。 ↩︎

WordPressでは、初期状態であれば、出力されるHTML内に、以下のようなコードが出力されているはずです（場所としてはheadタグ内にあります）。

<meta name="generator" content="WordPress 6.8.1" />

昨今のテーマやセキュリティプラグインでは上記コードが出てこないように設定することも可能ですが、たとえ設定ができない場合でも、 functions.php に1行追記するだけで出てこないようにすることができます。

目次

functions.php に追記するコード

remove_action('wp_head', 'wp_generator');

コードの意味

• remove_action()：WordPressであらかじめ設定されているアクションフック（add_actionで追加された処理）を削除（無効化）するための関数です。
• wp_head：出力されるHTMLのhead要素内を司っているフックです。
• wp_generator：ここを remove_action() で無効化することにより、<meta name="generator"> のHTMLを出力されないようにします。

補足

上記HTMLはそのままでも動作そのものに支障は無いのですが、使用しているWordPressのバージョンを世に晒していることとなります。そして、万が一古いWordPressであることが、これにより明らかになってしまうと、セキュリティリスクになってしまいかねません（常日頃更新していれば問題ないのですが、そうもいかないのがWordPressの難しいところだと思います）。

したがって、できれば運用の最初期のうちに対応しておきたい問題でございます。

WordPressでサイトを運営する際、「テーマのカスタマイズをしたいけど、アップデートで消えてしまうのが心配……」という方も多いのではないでしょうか？　そんなときに便利なのが「子テーマ」です。

この記事では、WordPressの子テーマのメリット・デメリット、作成方法、子テーマを使わない場合の影響について簡単にまとめています。

子テーマとは？

子テーマ（Child Theme） とは、親テーマ（Parent Theme）のデザインや機能を引き継ぎつつ、一部をカスタマイズできる仕組みです。

親テーマを直接編集せずにカスタマイズできるため、テーマのアップデートがあっても変更内容を維持できます。

子テーマのメリット

子テーマを使う最大の利点は、カスタマイズを安全に行えることです。 

• アップデートに強い：親テーマの更新があっても、子テーマを使えばカスタマイズ内容が消えません。 
• 親テーマの機能をそのまま活用できる：親テーマのデザインや機能をベースにできるので、ゼロから作る必要がなく、手間が省けます。 
• カスタマイズ管理がしやすい：カスタマイズ内容が子テーマ内にまとまるので、後から見直しや修正がしやすくなります。
• 失敗しても簡単に復元可能：子テーマのファイルを編集して問題が起きても、子テーマの変更部分だけを修正すれば元に戻せます。

子テーマのデメリット

• 親テーマに依存する：親テーマが大幅に変更されると、子テーマのカスタマイズ内容が影響を受けることがあります。 
• 親テーマのアップデート内容を反映しにくい：子テーマでテンプレートファイルを上書きすると、親テーマのアップデートが適用されないことがあります。
• コードの知識が必要：CSSやPHPの基本的な知識がないと、子テーマの作成やカスタマイズが難しく感じるかもしれません。
• 外観のカスタマイズ設定などは親テーマとは別：「子テーマ」といえども別テーマ扱いなので、外観の「カスタマイズ」設定など、「子テーマ」有効化時に引き継がない箇所もあることに注意してください。

WordPressの子テーマの作成方法

以下はプラグインなどを一切使用せずに対応する方法です。自己責任でお願いします。

• 「Child Theme Configurator」などのプラグインを使えばもっと簡単に作成できます（こちらも自己責任でお願いします）。
• 自作する場合は事前にバックアップを取っておくことを強くおすすめします。
• テーマによっては公式で子テーマを提供している場合があります（「Cocoon」「XWRITE」など）。こちらがある場合は、わざわざ自作する必要はなく、公式版を使った方が非常に安全に導入できます。

子テーマ用のフォルダを作成

wp-content/themes/ の中に 親テーマ名-child というフォルダを作成します。

style.cssを作成

/*
Theme Name: 親テーマ名 Child
Template: 親テーマ名
Version: 1.0
*/

• Theme Name：子テーマの名前
• Template：親テーマのフォルダ名（正確に入力）

functions.php を作成

<?php
function my_theme_enqueue_styles() {
    wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
}
add_action('wp_enqueue_scripts', 'my_theme_enqueue_styles');

これで、親テーマのCSSを読み込みつつ、子テーマのカスタマイズが可能になります。

WordPress管理画面で子テーマを有効化

「外観」→「テーマ」から、作成した子テーマを有効化すれば完了です！

（なお、テーマ公式版の「子テーマ」を使う場合も有効化は必要なので忘れないように！）

子テーマを使わない場合のメリット・デメリット

メリット

• 手間がかからない → 子テーマを作成・管理しなくて済む
• 親テーマの新機能をそのまま使える → アップデート時に問題が起こりにくい

デメリット

• アップデートでカスタマイズが消える → 親テーマを直接編集すると、更新時に上書きされる
• 管理が大変 → どこをカスタマイズしたか分かりにくくなる

カスタマイズするなら子テーマが必須

小さな変更なら「追加CSS」や「Code Snippets」プラグインを使う方法もありますが、 テーマをしっかりカスタマイズするなら子テーマの利用が圧倒的におすすめです。

まとめ

WordPressでカスタマイズするなら、子テーマを使うのが基本です。子テーマなら、アップデートでカスタマイズが消える心配もありません。手順も簡単で、フォルダを作成して、所定のCSSとPHPファイルを準備するだけです。なお、「Cocoon」など、テーマによっては公式の子テーマを提供しているものもあります。

WordPressを長く運用するなら、ぜひ子テーマを活用してみてください。

ブロックエディターの「続き」ブロックでは「続きを読む」テキストを任意で変更することができますが、テキストをデフォルトから変更しようと考えている場合、毎度毎度変更するのは面倒この上ありません。

そのため、functions.phpにコードを追記することによってデフォルト設定を更新し、変更後のテキストをあらかじめ反映できるようにします。

目次

functions.php に追記するコード

function custom_read_more_text($more_link_text) {
    return '<a class="more-link" href="' . get_permalink() . '#more-' . get_the_ID() . '">▶ 続きを見る</a>';
}
add_filter('the_content_more_link', 'custom_read_more_text');

※「▶ 続きを見る」の箇所は変えようと思っている文言に変更をお願いします。

コードの意味

• get_permalink()：投稿のURLを取得します。
• get_the_ID()：投稿IDを取得し、#more-123 のようなアンカーリンクを作ります。
• class="more-link"：テーマやCSSで装飾しやすくするためのクラス名です。
• add_filter('the_content_more_link', '（関数名）')：該当するフックに関数を適用し、変更した内容が反映されるようにする。

補足

• このフィルターは、<!--more--> を使って分割された記事にも影響します。
• ブロックエディター（Gutenberg）の「続きブロック」も実際にはこの <!--more--> と同じ仕組みで処理されています。

本記事では、WordPressの表示速度向上に役立つ「EWWW Image Optimizer」プラグインによる画像圧縮と、テーマにカスタム画像サイズを追加して不要な大きい画像読み込みを防ぐ方法について、理由と具体的手順を丁寧に解説します。

なぜ画像最適化が必要なのか

ページ表示速度の改善

大きな画像ファイルをそのまま読み込むと、ユーザーの通信回線（特にモバイル）で表示に時間がかかります。読み込みが遅いと、離脱率が上がりSEO（検索エンジン最適化）にも悪影響を及ぼします。

※離脱率（Bounce Rate）：ユーザーが1ページだけ見てサイトを離れる割合です。

帯域（バンド幅）とサーバー負荷の軽減

画像サイズが小さければ、それだけ転送データ量が減るため、サーバーやCDNのコストを抑えられます。高画質を保ちつつ圧縮率を上げられると理想的です。

レスポンシブ対応の強化

ユーザーの画面幅に合わせた最適な画像サイズを提供すると、無駄な大きい画像のダウンロードを防げます。WordPressはsrcset機能で自動的に最適画像を選択しますが、カスタムサイズを用意しておくことで、さらに細かく制御できます。

EWWW Image Optimizer の導入と設定

プラグインのインストール

1. 管理画面の「プラグイン」→「新規追加」で「EWWW Image Optimizer」を検索
2. “今すぐインストール” → “有効化”

基本設定

有効化後、管理画面の「設定」→「EWWW Image Optimizer」メニューに移動します。

［Basic Settings］
・『Remove metadata』：チェック → 画像に含まれる撮影情報などの余分なデータを削除  
・『Enable Jumbo Mode』：好みで → 圧縮率をさらに高める（サーバーCPUに負荷がかかる場合あり）

• Metadata（メタデータ）とは、撮影日時やカメラ情報などの付帯情報
• Jumbo Mode：高圧縮モード。時間がかかるがファイルサイズを大きく削減できます。

WebP 変換の有効化

「WebP Conversion」タブを開き、

1. 『Convert existing images to WebP』にチェック
2. 『Also convert to WebP in Media Library』にチェック

WebPはJPEG/PNGよりもさらに圧縮効率に優れた次世代フォーマットです。

一括最適化（Bulk Optimize）

既存メディアを一度に最適化するため、「Tools」→「Image Optimization」→「Run All Optimizations」で一括処理を実行します。時間がかかる場合があるので、深夜帯など負荷の低い時間に行いましょう。

画像サイズ（サムネイル）の追加と活用

なぜカスタム画像サイズが有効か

• テーマやテンプレートごとに必要な画像サイズは異なります。
• デフォルトの「サムネイル（150×150px）」「中サイズ（300×300px）」「大サイズ（1024×1024px）」以外に、独自サイズを追加すると、余分に大きいサイズを読み込まずに済みます。

functions.php に設定を追加

子テーマ（Child Theme）の functions.php に以下コードを追記します。

<?php
// カスタム画像サイズを追加
function mytheme_setup_custom_image_sizes() {
    // 幅800px、高さ450px、トリミングは中央基準
    add_image_size( 'hero-large', 800, 450, array( 'center', 'center' ) );
    // 幅400px、高さ225px、トリミングなし（縦横比を維持）
    add_image_size( 'hero-medium', 400, 225, false );
}
add_action( 'after_setup_theme', 'mytheme_setup_custom_image_sizes' );

コードの解説

• add_image_size( $name, $width, $height, $crop )
  • $name：画像サイズの識別名
  • $width, $height：ピクセル単位
  • $crop：切り抜き設定。true（センターで切り抜き）/array( ‘x’,’y’ )/false

サムネイル再生成

新規登録画像には自動生成されますが、過去画像には適用されません。
再生成には「Regenerate Thumbnails」などのプラグインを使い、以下手順で実行します。

1. プラグインをインストール・有効化
2. ツール→「Regenerate Thumbnails」→「Regenerate All Thumbnails」を実行

テンプレートでのサイズ指定

記事一覧やヘッダーなどテーマ内で画像を出力する際、以下のように呼び出します。

if ( has_post_thumbnail() ) {
    // hero-large サイズで出力
    the_post_thumbnail( 'hero-large' );
}

WordPressは自動的に srcset 属性を付与し、画面幅に合わせて最適な画像を選びます。さらに細かく制御したい場合は、wp_get_attachment_image_srcset() や sizes 属性を併用しましょう。

さらに効果を高めるポイント

Lazy Load（遅延読み込み）

EWWW Image Optimizer では「Lazy Load」タブから有効化でき、ユーザー画面内に到達した画像だけを読み込みます。WordPress 5.5以降は標準で loading="lazy" が付きますが、プラグインでさらに最適化可能です。

• CDN（コンテンツ配信ネットワーク）
  画像をCDNに配信すると、ユーザーからの地理的な距離による遅延を減らせます。EWWWのCDNオプション（有料）や、Cloudflare・AWS CloudFront・KeyCDNなどと併用しましょう。
• SVG（ベクター画像）の活用
  アイコンやロゴなど単色・簡易図形はSVG化できると、ファイルサイズ・解像度の両面でメリットがあります。

まとめ

1. EWWW Image Optimizer でメタデータ削除・圧縮・WebP変換・遅延読み込みを設定し、既存画像を一括最適化
2. カスタム画像サイズ を add_image_size() で定義し、不要な大きいサイズ読み込みを防ぐ
3. 再生成プラグイン で過去画像にも適用
4. テーマテンプレートで the_post_thumbnail() などを活用し、srcset でレスポンシブ配信

これらを組み合わせることで、ページの表示速度・ユーザー体験・SEOが同時に向上します。ぜひ試してみてください！