SWELLの画像の遅延読み込みを除外するときは、ブラウザー標準のloading属性と、lazysizes.js方式を分けて考えます。
以前掲載していた、読み込み後にlazyloadedクラスを消すJavaScriptでは、画像の読み込み開始を早めることはできません。
本記事ではそのコードを撤回し、標準の画像ブロックに限って、サーバーから出力する時点でloading=”eager”を指定する方法を紹介します。
対象となる設定と画像
この例はloading=”lazy”方式の環境向けで、SWELLのlazysizes.js方式を除外するコードではありません。
WordPress標準の「画像」ブロックが対象です。ギャラリー内でも、個々の画像ブロックにno-lazyloadを付ければ対象になります。ギャラリー全体やカバーへ付けたクラスは、このコードでは内側の画像に適用されません。テーマ独自の画像出力も別途確認してください。
ファーストビューにある必要な画像だけを対象にし、記事内の全画像を一律に変更しないでください。
画像ブロックにクラスを付ける
対象の画像ブロックを選び、「高度な設定」の「追加CSSクラス」にno-lazyloadと入力します。

上の画像は旧記事の操作例です。表示される設定名や配置はWordPressのバージョンによって異なります。
PHPを1か所へ追加する
子テーマのfunctions.phpかCode Snippetsのどちらか1か所だけに追加し、編集前の内容を保存してください。
add_filter('render_block_core/image', function ($content, $block) {
$classes = preg_split('/\s+/', trim($block['attrs']['className'] ?? ''));
if (!in_array('no-lazyload', $classes, true) || !class_exists('WP_HTML_Tag_Processor')) {
return $content;
}
// SWELLのlazysizes方式は、この例の対象外です。
if (class_exists('SWELL_Theme') && SWELL_Theme::$lazy_type === 'lazysizes') {
return $content;
}
$html = new WP_HTML_Tag_Processor($content);
while ($html->next_tag('IMG')) {
$html->set_attribute('loading', 'eager');
}
return $html->get_updated_html();
}, 20, 2);確認と戻し方
キャッシュを更新して公開ページのソースを開き、対象画像にloading=”eager”があることを確認します。
対象外の画像や画像のURL、alt、幅・高さが意図せず変わっていないことも確認してください。
lazysizes.js方式では、このコードは変更を行いません。
loading属性が変わったことと、画像のHTTPリクエストが始まったことを分けて確認します。
同じ位置の対象画像と対象外画像を比較し、全体の速度改善は別途計測してください。
戻すときは追加したPHPを削除または無効化し、画像ブロックのno-lazyloadも外します。
ギャラリーで除外されないときの確認
| クラスを付けた場所・方式 | 結果 |
|---|---|
| 単独の画像ブロック | no-lazyloadを付けた画像にloading=”eager”を設定 |
| ギャラリー全体 | 親のクラスだけでは内側の画像を変更しない |
| ギャラリー内の個別画像 | 個々の画像ブロックへ付ければ、その画像だけを対象にする |
| SWELLのlazysizes方式 | クラスを付けても、このコードでは変更しない |
「SWELL設定 → 高速化」の「画像等のLazyload」が「loading=”lazy”を使用する」になっている環境で、ギャラリー内の親指定と個別画像指定を比較しました。
親のクラスと画像のクラスを公開HTMLで見分ける
| クラスを付けた場所 | 今回のloading属性 |
|---|---|
| ギャラリー全体だけ | 内側の対象外画像はlazyを維持 |
| ギャラリー内の個別画像 | その画像だけeagerへ変更 |
| クラスを付けていない通常画像 | lazyを維持 |
「高度な設定」を開く前に、リスト表示でギャラリー内の「画像」ブロックを選んでください。
ギャラリーの親を選んだままno-lazyloadを入力しても、このPHPでは内側の画像を変更しません。
検証環境では、3画像のURL・alt・幅260・高さ64を保持し、個別指定した1画像だけeagerになりました。
1280pxの公開画面と、表示領域385pxのカスタマイザー標準スマホプレビューで、3画像の読み込みと横はみ出しがないことを確認しています。
lazysizes.js方式ではeagerを追加せず、その方式の出力を維持しました。
既存の遅延読込方式を変更する場合は、変更前の設定を保存し、動画やiframeなど画像以外への影響も確認してください。

画面外の画像をブラウザーで比較した結果
| 条件 | 対象画像 | 対象外画像 |
|---|---|---|
| ページを開いた直後 | loading=”eager”で要求・読み込み完了 | loading=”lazy”で要求なし |
| 画像位置へ移動した後 | 読み込み済み | 要求されて読み込み完了 |
2026年10月2日、WordPress 7.1.2・SWELL 2.19.0で、掲載コードを標準画像ブロックの出力に適用して確認しました。
両画像を最初の画面から約7000px下に配置し、サーバー側のHTTP要求記録とブラウザーの読み込み完了を比較しました。
この結果は標準のloading属性を使う検証環境のもので、WP Rocketなどが後からHTMLを変更する環境は別途確認が必要です。
WP Rocketのキャッシュ設定を変更している場合は、更新後の公開HTMLで属性が残っていることも確認します。
Pjax後も対象画像だけeagerになっているか確認する
| 操作 | 対象画像 | 対象外画像 |
|---|---|---|
| 画像ブロックのある記事へPjaxで移動 | loading=”eager” | loading=”lazy” |
| 別ページから履歴で戻る | eagerを維持 | lazyを維持 |
標準のloading属性を使う環境では、Pjaxの移動先でも対象画像と対象外画像を並べて属性を確認します。
2026年10月3日のWordPress 7.1.2 / SWELL 2.19.0では、実Pjaxで追加された本文と履歴で戻った本文の両方で、個別指定した画像だけeagerになっていました。
撮影用に画像の表示幅を260pxへそろえ、対象と比較用の画像をラベルで区別しています。
掲載画像は両方の読み込み完了を示すもので、読み込み速度の差はこの写真から判断できません。
SWELL自身が出すアイキャッチや背景画像は標準画像ブロックとは別の出力なので、SWELLの遅延読込関連フックから適用範囲を調べます。
WP Rocketによる書き換えは今回の比較に含めていないため、実際の高速化設定を保った公開HTMLで属性を再確認してください。

実装の根拠と検証範囲
ブロック出力フィルターとWP_HTML_Tag_Processorを利用しています。
lazysizes.js方式の個別除外や、ほかの高速化プラグインが後から行う書き換えは、この例では保証しません。
除外クラスを付けるブロックを確認する
| no-lazyloadの付け先 | 掲載フィルターの適用 |
|---|---|
| 画像ブロック自身 | 標準方式では画像のloadingをeagerへ変更 |
| 画像を囲む親グループだけ | 子の画像には引き継がれない |
| カスタムHTMLブロック | core/image用のフィルターの対象外 |
| 画像ブロックでSWELLのlazysizes方式を使用 | 掲載コードは変更せず返す |
WordPress 7.1.2の実際のrender_blockで、親グループとカスタムHTMLにクラスを付けても子画像のloadingはlazyのままになることを確認しました。
除外したい画像ブロック自身の「追加CSSクラス」へno-lazyloadを指定してください。
no-lazyload-extraなど似た名前は対象になりません。
画像ブロックのクラスを空白区切りで照合する処理です。
カスタムHTMLやギャラリーなど、別のブロックへこのクラスを付けても同じ結果にはなりません。
この確認はWordPressのブロック出力が対象です。
WP Rocketなどが出力後のHTMLを変更する場合は、実際に配信される画像タグを確認してください。
今回、これらの製品設定を変更したり、速度改善を測定したりしていません。



