WordPress Lazy Load設定とLCP対策｜遅延読み込みの実務設計

WordPressのLazy Loadは、画像やiframeを必要なタイミングまで遅らせて、初期表示の負荷を下げるための仕組みです。

ただし、実務では「Lazy Loadを有効にするかどうか」だけでは判断できません。WordPress標準機能、テーマ、高速化プラグイン、画像最適化プラグイン、CDN、YouTube埋め込み、広告タグがそれぞれ遅延読み込みを触ると、どの設定が効いているのか分からなくなります。

さらに、Largest Contentful Paintでは、ビューポート内で最大の画像やテキストなどが表示されるまでの時間が重要な指標になります。トップページのメインビジュアル、記事のアイキャッチ、サービスページのファーストビュー画像がLCP対象なら、その画像をLazy Loadしてはいけません。

GoogleのブラウザレベルのLazy Load解説でも、最初のビューポートに表示される画像、とくにLCP画像は通常読み込みにして、画面外の画像だけをloading="lazy"にする考え方が示されています。

WordPressのLazy Load設定で最初に決めるべきなのは、有効化するかではなく、どの画像とiframeを遅らせ、どれを遅らせないかです。

この記事では、WordPressのLazy Load設定を、LCP改善と保守運用の両方から整理します。

Lazy Loadで速くなる場合と遅くなる場合

Lazy Loadで速くなりやすいのは、ユーザーが最初に見ない要素です。

記事後半の画像、制作事例一覧の下部、ギャラリー、地図、YouTube埋め込み、SNS埋め込み、記事下の関連記事などは、初期表示時にすべて読み込む必要がありません。こうした要素を遅らせると、最初に必要な通信量を減らせます。

一方で、次の要素をLazy Loadすると逆効果になりやすいです。

要素	Lazy Loadすると起きること	基本方針
メインビジュアル	LCPが遅くなる	除外する
記事上部のアイキャッチ	記事本文の表示開始が遅く見える	LCP対象なら除外する
ファーストビュー内のCTA画像	クリック導線の表示が遅れる	除外または個別確認
ファーストビュー内のYouTube	動画枠やサムネイル表示が遅れる	目的に応じて通常読み込みか軽量埋め込みにする
カルーセル1枚目	最初のスライドが空白になりやすい	1枚目は除外する
広告枠	レイアウトずれや収益低下が起きる	枠を固定して検証する

Lazy Loadは「下にあるものを後で読む」設定です。だから、下にある画像が多い記事やメディアでは効果が出やすいです。逆に、ファーストビューに大きな画像や埋め込みがあるLPでは、設定を間違えるとLCPが悪化します。

Lazy Loadは画面外の画像やiframeには有効ですが、LCP画像、ファーストビューCTA、カルーセル1枚目を遅らせると体感速度を悪くします。

まずは、ページごとに「最初に見せる要素」と「スクロール後でよい要素」を分けます。

WordPress標準のLazy Loadの挙動

現在のWordPressでは、画像やiframeに対して読み込み最適化の属性を付ける仕組みがCore側にあります。

wp_get_loading_optimization_attributes()は、imgやiframeに対してloading、fetchpriority、decodingなどの属性を返すWordPress Coreの関数です。すでに属性が指定されている場合は、それを勝手に変更しない挙動もあります。

WordPress 6.3では、LCP画像候補にfetchpriority="high"を付ける改善や、Lazy Loadの扱い改善が進められました。

WordPress 6.3: Image performance enhancements

WordPress 6.4では、wp_get_loading_optimization_attributes()まわりのロジックが整理され、decoding="async"の扱いやフィルターによる制御も拡張されています。

WordPress 6.4: Image loading optimization enhancements

ただし、WordPress Coreの挙動だけを信じて終わりにしない方がよいです。テーマが画像タグを独自に出力している、ページビルダーが別のHTMLを生成している、プラグインがloading属性を後から書き換えている、CDNがHTMLを最適化している、といったことがあるからです。

確認する場所	見ること
HTMLソース	LCP画像にloading="lazy"が付いていないか
WordPressテーマ	wp_get_attachment_image()などCoreの出力を使っているか
カスタムテンプレート	手書きのimgや背景画像がないか
ページビルダー	画像やiframeのLazy Load設定を持っていないか
高速化プラグイン	Coreの属性を上書きしていないか

WordPress標準のLazy Loadは出発点として使えますが、最終判断は実際に出力されたHTMLとLCP対象を見て行います。

特に古いテーマや独自テンプレートを使っているサイトでは、WordPress標準の改善が期待通りに効かないことがあります。

プラグイン・テーマ・CDNの重複チェック

WordPressのLazy Loadで多い失敗は、同じ機能を複数の層で重ねることです。

たとえば、WordPress標準のLazy Loadが効いている状態で、テーマ、Autoptimize系の高速化プラグイン、画像最適化プラグイン、CDN、YouTube軽量埋め込みプラグインがそれぞれLazy Loadを追加すると、HTMLの出力や実際の読み込みタイミングが追いにくくなります。

層	よく触る内容	重複時の問題
WordPress Core	loading、fetchpriority、decoding	テーマやプラグインと判定がズレる
テーマ	メイン画像、アイキャッチ、背景画像	LCP画像にLazy Loadが付く
高速化プラグイン	画像・iframeの遅延、JS遅延	フォームやメニューも壊れる
画像最適化プラグイン	WebP配信、Lazy Load、プレースホルダー	画像URLやsrcsetが複雑になる
CDN	画像最適化、HTML書き換え、キャッシュ	変更反映や除外条件が追いにくい
YouTube系プラグイン	iframe置換、サムネイル化	計測や表示確認が別になる

重複チェックでは、管理画面の設定名だけで判断しません。対象URLのHTML、DevToolsのNetwork、PageSpeed InsightsのLCP要素、スマホ実機を見て、どの層が最終的な出力を作っているかを確認します。

実務では、次のように担当を分けると安全です。

役割	担当候補
画像の読み込み属性	WordPress Coreまたはテーマ側
画像形式・圧縮	画像最適化プラグインまたはCDN
iframe・YouTube軽量化	専用プラグインまたはテーマ実装
HTMLキャッシュ	キャッシュプラグインまたはサーバー
CDN配信	CDN側

Lazy Loadの重複は、速くするための保険ではなく、LCP悪化、表示崩れ、原因不明の不具合を増やすリスクです。

「どれをオンにするか」より「どの層に任せ、どの層では触らないか」を決めます。

LCP画像とファーストビューを除外する設計

Lazy Load設計で最も重要なのは、LCP画像とファーストビュー画像を除外することです。

LCP画像は、ページごとに変わります。トップページではメインビジュアル、記事ではアイキャッチ、サービスページでは見出し横の画像、LPではファーストビューの背景画像が対象になることがあります。

まず、PageSpeed InsightsやLighthouseで対象URLを測り、LCP要素を確認します。そのうえで、HTMLやDevToolsで次を見ます。

確認項目	合格の目安
LCP画像	loading="lazy"が付いていない
優先画像	必要に応じてfetchpriority="high"が1つに絞られている
画像サイズ	表示サイズに近く、過剰に大きくない
width / height	レイアウトずれを防ぐため指定されている
背景画像	CSS背景がLCP候補なら読み込みタイミングを確認する
スマホ表示	PCと別画像の場合も個別に確認する

WordPress 6.3以降は、Core側でLCP候補へのfetchpriority="high"付与やLazy Load除外の改善が入っています。ただし、カスタムテーマやページビルダーが独自に画像を出している場合は、Coreの判定だけでは足りないことがあります。

また、loading="lazy"とfetchpriority="high"を同じ画像に付けるのは避けます。WordPressの関数リファレンスでも、これらを同じ要素に付けるべきではない前提で扱われています。

LCP画像の基本は「Lazy Loadしない」「必要なら優先度を上げる」「ただし高優先度画像を増やしすぎない」です。

ファーストビュー内の画像が複数ある場合は、すべてを高優先度にするのではなく、実際にLCP対象になっている要素を特定してから調整します。

iframe・YouTube埋め込みの扱い

iframeやYouTube埋め込みは、Lazy Loadの効果が出やすい領域です。

YouTube、Googleマップ、SNS埋め込み、予約ウィジェット、チャット、外部フォームなどは、ページ本体とは別のJavaScriptや通信を伴うことがあります。記事下部や補足コンテンツなら、初期表示時に読み込まない方が体感速度は改善しやすいです。

一方で、次のような埋め込みは個別判断が必要です。

埋め込み	注意点
ファーストビューのYouTube	サムネイルや再生ボタンが遅れると訴求が弱くなる
LP中央のデモ動画	スクロール直後に表示されないと離脱につながる
Googleマップ	店舗ページでは場所確認の導線になる
予約ウィジェット	遅延しすぎると予約開始まで待たせる
外部フォーム	キャッシュやJS遅延と競合しやすい
チャット	営業導線だが初期表示を重くしやすい

WordPress Coreの読み込み最適化関数は、iframeに対してloading属性を扱う前提も持っています。ただし、YouTube軽量化プラグインがiframeをサムネイルに置き換える場合、実際の出力はプラグイン側の実装になります。

YouTubeでは、通常のiframeを遅延読み込みする方法だけでなく、クリックされるまでiframeを作らない軽量埋め込みにする方法もあります。この場合、最初に出すサムネイル画像の画質、サイズ、代替テキスト、クリック後の再生、計測イベントを確認します。

iframeとYouTubeはLazy Loadの効果が出やすい一方で、予約、地図、動画CTA、外部フォームのような業務導線は遅らせすぎない判断が必要です。

埋め込みごとに「初期表示に必要か」「CVに近いか」「クリック後でよいか」を分けて設計します。

CTA・広告・カルーセルで崩さない注意点

Lazy Load設定では、CTA、広告、カルーセルを必ず確認します。

これらは「少し表示が遅れるだけ」に見えて、問い合わせ、資料請求、予約、広告収益、回遊に影響することがあります。

対象	よくある不具合	確認すること
CTA画像	表示が遅れてボタン周辺が空白になる	スマホでCTA到達時の見え方
CTAボタン	JS遅延でクリック計測が取れない	GA4/GTMイベント
広告枠	読み込み後に本文が押し下げられる	枠の高さ固定、CLS
カルーセル1枚目	初期表示で画像が出ない	1枚目の読み込み除外
カルーセル2枚目以降	すべて先読みして重くなる	遅延と先読みのバランス
固定ヘッダー	画像遅延後に重なりが変わる	モバイル実機

広告枠は、画像やiframeと同じように遅延読み込みできますが、枠の高さを確保しないとCLSが悪化します。広告が後から入って本文やCTAを押し下げると、ユーザーのタップ位置がずれます。

カルーセルは、1枚目と2枚目以降を分けて扱います。1枚目はファーストビューに出るならLazy Loadしない。2枚目以降は、ユーザーが次に見る前に読み込めるよう、完全な後回しにしすぎない。この調整が必要です。

CTAは、画像だけでなく計測も見ます。JavaScript遅延、キャッシュ、CDN最適化が入ると、見た目は正常でもGTMやGA4イベントだけ止まることがあります。

Lazy Loadの完了条件は、画像が遅れて表示されることではなく、CTA、広告、カルーセル、計測が壊れずに初期表示だけ軽くなっていることです。

速度改善後は、必ずログアウト状態のスマホで、ファーストビューからCTAまで実際にスクロールして確認します。

PageSpeed Insightsと実機での検証手順

Lazy Load設定は、変更前後を同じURLで比較します。

トップページだけではなく、記事、サービスページ、LP、フォームページ、YouTube埋め込みがあるページ、広告があるページを分けて確認します。WordPressではページ種別ごとにテンプレートや読み込みリソースが違うためです。

手順	確認内容
1	重要URLを決める
2	変更前のPageSpeed Insightsを記録する
3	LCP要素を確認する
4	HTMLでloading、fetchpriority、width、heightを見る
5	DevTools Networkで画像・iframeの読み込み順を見る
6	スマホ実機でファーストビューとCTAを確認する
7	YouTube、地図、広告、カルーセルを確認する
8	フォーム送信とCTAクリック計測を確認する
9	変更後に同じURLを再測定する

PageSpeed Insightsでは、スコアより先にLCP、CLS、INP、診断結果のLCP要素を見ます。LCPが改善していないのにスコアだけ少し上がっている場合、重要なファーストビュー改善にはつながっていない可能性があります。

実機確認も必須です。PageSpeed Insightsのラボデータでは問題なく見えても、実際のスマホ、低速回線、SNSアプリ内ブラウザ、広告流入では見え方が変わることがあります。

Lazy Load設定の検証は、PageSpeed Insightsの点数ではなく、LCP要素、HTML属性、読み込み順、スマホ表示、CTA計測をセットで確認します。

変更後には「どの設定を変えたか」「どのURLで確認したか」「LCP画像は何だったか」「除外した画像やiframeは何か」を保守メモに残します。

画像圧縮・WebP記事との役割分担

画像圧縮・WebPとLazy Loadは、どちらも表示速度に関係します。ただし、改善する対象が違います。

領域	主な役割	見るべきこと
画像圧縮	画像の容量を小さくする	画質、圧縮率、元画像バックアップ
リサイズ	表示サイズに合わせる	過剰なピクセルを配っていないか
WebP/AVIF	軽い形式で配信する	互換性、キャッシュ、CDN
Lazy Load	読み込み順を変える	画面外だけ遅らせているか
LCP除外	主役画像を先に読む	ファーストビュー画像の属性
fetchpriority	重要画像の優先度を上げる	高優先度を増やしすぎない

画像圧縮の記事で扱うべきなのは、重い画像の棚卸し、リサイズ、WebP/AVIF、生成サイズ、既存画像の一括最適化、アップロード運用です。

Lazy Loadの記事で扱うべきなのは、読み込みタイミング、LCP画像除外、iframe、YouTube、広告、CTA、カルーセル、検証手順です。

たとえば、LCP画像が4000pxのJPEGなら、画像圧縮とリサイズが必要です。しかし、その画像にloading="lazy"が付いているなら、Lazy Load設計も直す必要があります。逆に、記事後半の画像が大量にあるなら、圧縮だけでなくLazy Loadも効きます。

WordPress画像圧縮とWebP最適化では画像そのものを軽くする観点を整理し、この記事では読み込み順とLCP除外を扱います。

画像圧縮は画像を軽くする作業、Lazy Loadは画像やiframeを読む順番を決める作業です。両方を混ぜると、何を直すべきか分からなくなります。

まずはLCP画像を特定し、その画像には「サイズ・形式」と「読み込みタイミング」の両方から手を入れます。

WordPress高速化を保守改善につなげる相談導線

WordPressのLazy Load設定は、単体の高速化テクニックとして見ると軽く見えます。

しかし実際には、LCP画像、テーマ出力、画像最適化、キャッシュ、CDN、YouTube、広告、CTA、GA4/GTM、フォーム、スマホ表示が絡みます。設定を一つ変えただけで、表示速度は上がってもCV導線や計測が壊れることがあります。

Bitlightに相談する場合は、次の材料があると診断しやすくなります。

相談材料	例
対象URL	トップ、記事、LP、フォーム、動画ページ
困っている症状	LCPが遅い、YouTubeが重い、CTA表示が遅い
現在の設定	高速化プラグイン、画像プラグイン、CDN
LCP対象	メイン画像、アイキャッチ、背景画像、見出し
壊せない導線	問い合わせ、予約、電話、広告CV、会員機能
検証した内容	PageSpeed Insights、実機、フォーム送信、GA4/GTM

相談の目的は、Lazy Loadをオンにすることではありません。ページごとに「何を先に読み、何を後に回し、どこを除外するか」を決め、変更後にLCP、CTA、フォーム、計測が正常なまま改善していることを確認することです。

WordPressのLazy Load改善は、速度設定ではなく、LCP改善、CV導線確認、計測確認、保守メモ化まで含めた運用改善として扱うべきです。

古いWordPressほど、テーマ、プラグイン、CDN、外部タグが積み重なっています。だからこそ、表示速度だけでなく、壊さず直せる順番と、次回の更新で再発しない保守ルールまで整えることが重要です。