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

上の画像は旧記事の操作例です。表示される設定名や配置はWordPressのバージョンによって異なります。
PHPを1か所へ追加する
子テーマのfunctions.phpのPHP領域かCode SnippetsのPHPスニペットのどちらか1か所だけに追加し、編集前の内容を保存してください。掲載コードには開始タグを含めていません。既存のPHP領域には <?php を重ねて追加しません。使用する WP_HTML_Tag_Processor はWordPress 6.2で追加された機能で、このクラスがない環境では掲載コードは本文を変更せず返します。
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が対象外画像へ loading="lazy" を付けるわけではありません。対象外の属性はWordPress・テーマ・プラグインの処理に従うため、比較前の出力も確認してください。
同じ位置の対象画像と対象外画像を比較し、全体の速度改善は別途計測してください。
戻すときは追加したPHPを削除または無効化し、画像ブロックのno-lazyloadも外します。
ギャラリーで除外されないときの確認
| クラスを付けた場所・方式 | 結果 |
|---|---|
| 単独の画像ブロック | no-lazyloadを付けた画像にloading=”eager”を設定 |
| ギャラリー全体 | 親のクラスだけでは内側の画像を変更しない |
| ギャラリー内の個別画像 | 個々の画像ブロックへ付ければ、その画像だけを対象にする |
| SWELLのlazysizes方式 | クラスを付けても、このコードでは変更しない |
「SWELL設定 → 高速化」の「画像等のLazyload」が「loading="lazy"を使用する」になっている環境で、ギャラリー内の親指定と個別画像指定を比較しました。
親のクラスと画像のクラスを公開HTMLで見分ける
公開HTMLで見ると、ギャラリー全体にだけクラスを付けた場合は内側の画像が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で属性を再確認してください。

除外クラスを付けるブロックを確認する
| 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を変更する場合は、実際に配信される画像タグを確認してください。今回、これらの製品の設定を変更したり、速度改善を測定したりはしていません。
実装の根拠と検証範囲
ブロック出力フィルターとWP_HTML_Tag_Processorを利用しています。
lazysizes.js方式の個別除外や、ほかの高速化プラグインが後から行う書き換えは、この例では保証しません。
ほかのカスタマイズはSWELLカスタマイズまとめから探せます。
よくある質問:SWELLで特定の画像の遅延読み込み(Lazy Load)を除外するとき
この方法は、SWELLのどの遅延読み込み設定が対象ですか?
記事では、この例はloading属性にlazyを使う方式の環境向けで、SWELLのlazysizes.js方式を除外するコードではありません。「SWELL設定 → 高速化」の「画像等のLazyload」が「loading="lazy"を使用する」になっている環境で確認しています。lazysizes方式では、クラスを付けても、このコードでは変更しません。
以前の、lazyloadedクラスを消すJavaScriptは使えますか?
使えません。記事では、読み込み後にlazyloadedクラスを消すJavaScriptでは、画像の読み込み開始を早めることはできないため、そのコードを撤回しています。標準の画像ブロックに限って、サーバーから出力する時点でeagerを指定する方法を紹介しています。
どの画像が対象ですか?
記事では、WordPress標準の「画像」ブロックが対象です。ファーストビューにある必要な画像だけを対象にし、記事内の全画像を一律に変更しません。テーマ独自の画像出力も別途確認します。
クラスは、どこに付けますか?
記事では、対象の画像ブロックを選び、「高度な設定」の「追加CSSクラス」にno-lazyloadと入力します。画像を囲む親グループやカスタムHTMLブロックにクラスを付けても、子画像のloadingはlazyのままです。除外したい画像ブロック自身に指定します。
ギャラリーの画像にも使えますか?
個々の画像ブロックに付ければ使えます。記事では、ギャラリー全体やカバーへ付けたクラスは、このコードでは内側の画像に適用されません。「高度な設定」を開く前に、リスト表示でギャラリー内の「画像」ブロックを選びます。
PHPは、どこに追加しますか?
記事では、子テーマのfunctions.phpかCode Snippetsのどちらか1か所だけに追加し、編集前の内容を保存します。
SWELLのアイキャッチや背景画像も、除外できますか?
このコードでは除外できません。記事では、SWELL自身が出すアイキャッチや背景画像は標準画像ブロックとは別の出力なので、SWELLの遅延読込関連フックから適用範囲を調べます。
WP Rocketなどを使っている場合は、どうしますか?
記事では、WP Rocketによる書き換えは今回の比較に含めていないため、実際の高速化設定を保った公開HTMLで属性を再確認します。WP Rocketなどが出力後のHTMLを変更する場合は、実際に配信される画像タグを確認します。なお、記事では掲載画像は読み込み完了を示すもので、読み込み速度の差は判断できないとしています。



