Lighthouseのavoid excessive-DOM size警告を修正する

Excessive-DOM sizeを回避してCore Web Vitalsを改善する

Arjen Karel - linkedin

Last update: 2026-03-02

'Avoid excessive-DOM size'の概要

Excessive DOM sizeとは、ページ上のDOMノード（HTMLタグ）が多すぎる、あるいはHTMLタグのネストが深すぎることを意味します。

大量のDOMノードを持つページを読み込む際、ブラウザはページのレンダリングにより多くの計算能力を必要とします。これは通常、ページのレンダリング遅延を引き起こします。

ブラウザがより多くのノードを読み込み解析する必要があるため、JavaScriptやCSSの実行も遅くなることがよくあります。

これらすべてが、ページスピードスコアの低下につながります。

最終確認: Arjen Karel (2026年2月)

'avoid excessive-DOM size' Lighthouse警告とは？

avoid axcessive dom size lighthouse

Lighthouseのavoid excessive-DOM size警告とは何でしょうか？Lighthouseは以下のいずれかに該当するページにフラグを立てます：

合計DOMノード数が1,500を超える場合。
これは、ページ上に1,500以上のHTML要素があることを意味します。
最大ノード深度が32を超える場合。
これは、要素が32レベルの深さまでネストされている場合に発生します。
親ノードが60以上の小ノードを持つ場合。
これは、親要素（テーブルやリストなど）が60以上の子要素（テーブルの行やリスト要素）を持っている場合に発生します。

これらの数字を客観的に見ると、2024 Web Almanacによれば、ページの中央値は594 DOM要素です。90パーセンタイルでは1,716に跳ね上がり、これは既にLighthouseの閾値を超えています。Web上の全ページの約10%がこの警告をトリガーしています。

Lighthouse 13（2025年10月）以降、この監査は"Optimize DOM size"インサイトへと進化しました。現在は単なる静的なノード数ではなく、40msを超える実際のスタイル再計算やレイアウト作業に基づいてトリガーされます。上記の閾値は依然として参照点として報告されています。

確認：DOMとは何か？

DOMはDocument Object Modelの略です。DOMはHTMLのツリー構造のオブジェクト表現であり、各HTML要素（例：bodyやh1）が独自のノードによって表現されます。

Excessive DOM sizeの原因は？

Excessive DOM sizeには様々な理由が考えられます。通常、以下のような原因があります：

CMSの不適切にコーディングされたプラグイン。
JavaScriptによって作成されたDOMノード。
肥大化したHTMLを生成するページビルダー（例：ElementorやWP Bakery）。
WYSIWYGエディタ（TinyMCEなど）にコピー＆ペーストされたテキスト。
不適切なテンプレートコーディング。

2024 Web Almanacによると、<div>要素だけで全ページ要素の28.7%を占めていることがわかりました。この「divitis（div病）」は、特にページビルダーの出力において、DOMサイズ肥大化の主要な要因となっています。

Excessive DOM sizeはページ速度にどう影響するか？

巨大なDOMはLighthouseのメトリクスに直接影響するわけではありません。しかし、ウェブページのレンダリングを不必要に複雑にし、高いLighthouseスコアの獲得をほぼ不可能にします。ブラウザはウェブページを画面に表示する前に、より多くの作業を行う必要があります。巨大なDOMには4つの問題があります：

コードが肥大化しているため、HTMLのサイズが大きくなります。これにより、ページのダウンロードにかかる時間が増加します。
巨大なDOMサイズはレンダリングパフォーマンスを低下させます。ブラウザは初回ロード時や、ユーザーやスクリプトがページと対話するたびに、より多くの（DOM）計算を行う必要があります。
JavaScriptを介してDOMを操作する際、ブラウザがより多くのメモリを使用する可能性があります。
巨大なDOMはInteraction to Next Paint (INP)に直接影響します。ユーザーがクリック、タップ、または入力するたびに、ブラウザは影響を受ける要素のスタイルとレイアウトを再計算する必要があります。ページ上のDOMノードが多いほど、これに時間がかかります。スタイルの再計算が300以上の要素に影響するか、40ms以上かかる場合、INPにとって測定可能な問題となります。これが、JavaScriptが高速であっても、数千のDOMノードを持つページがしばしばINPに失敗する理由です。

'avoid excessive DOM size'警告は、Largest Contentful Paint (LCP)やCumulative Layout Shift (CLS)といった重要なCore Web Vitalsに間接的に影響する可能性が高いです。しかし、最大の影響は、最も失敗しやすいCore Web VitalであるINPに及びます。

'avoid excessive-DOM size'の修正方法

'avoid excessive-DOM size'警告を修正するには、まずその発生源を突き止める必要があります。Lighthouseは、最大DOM深度と最大子要素数がどこにあるかを示してくれます。そこからは少し調査が必要です。Chrome DevToolsのDOMインスペクタを使用してDOMをチェックしてください。何が大量のDOMノードを作成しているのかを突き止めてみましょう。通常、5つの容疑者が考えられます：

CMSの不適切にコーディングされたプラグイン。
スライダーやカレンダープラグインなどが大量のDOMノードを作成している場合、より軽量なプラグインへの置き換えを検討してください。
JavaScriptによって作成されたDOMノード。
チャットウィジェットなどのJavaScriptが、DOMに大量のノードを注入している場合があります。この場合、そのJavaScriptファイルを削除するか、同じ機能を持つ代替品を見つけてください。
肥大化したHTMLを生成するページビルダー。
ElementorやWP Bakeryのようなページビルダーは、大量のDOMノードを持つ肥大化したコードを生成することがよくあります。これに対する簡単な修正方法はありません。ページビルダーは多くの場合ワークフローの一部です。解決策には、肥大化したコードのクリーンアップやワークフローの変更が含まれます。
WYSIWYGエディタにコピー＆ペーストされたテキスト。
TinyMCEのようなほとんどのWYSIWYGエディタは、特にMicrosoft Wordのような他のリッチテキストソースからペーストされた場合、コードのクリーンアップが不十分です。テキストだけでなくスタイルもコピーしてしまいます。それらのスタイルは大量のDOMノードに埋め込まれている可能性があります。この問題の解決策は単純です。エディタへのコンテンツのペーストをやめ、すでにペーストされた肥大化したテキストがあるページをクリーンアップしてください。
不適切な（テンプレート）コーディング。
巨大なDOMサイズがエディタによって作成されたり、テンプレートによって引き起こされている場合、事態は厄介です。これは、肥大化したコードがWebサイトのコアの一部であることを意味します。エディタを変更するか、テンプレートの一部を書き直すか、あるいはゼロから作り直す必要があります。

巨大なDOMの影響を軽減するテクニック

サイトの大部分を書き直したり、ワークフロー全体を変更したりせずに、excessive DOM sizeを解消することが不可能な場合もあります。excessive DOM sizeの影響を軽減するためのテクニックがいくつかあります：

.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Webページの一部を遅延読み込み（Lazy load）する。
初回のレンダリングを高速化するために、Webサイトの一部（例えばフッターなど）の遅延読み込みを検討すると良いでしょう。
content-visibility: autoを使用して画面外コンテンツのレンダリングをスキップする。
CSSのcontent-visibilityプロパティは、ユーザーがスクロールして近づくまで、画面外要素のスタイリング、レイアウト、描画をスキップするようブラウザに指示します。現在では93%のブラウザサポート（Chrome 85+、Firefox 125+、Safari 18+）があります。レイアウトシフトを防ぐために、常にcontain-intrinsic-sizeと組み合わせて使用してください：
巨大なページを複数のページに分割する。
コンテンツ自体が多くのDOMノードを作成している場合、巨大なページを複数のページに分割することでDOMノード数を減らすことができます。
仮想スクロール（Virtual Scrolling）を実装する。
長いリスト、データテーブル、画像ギャラリーの場合、仮想スクロールはビューポートに表示されているアイテムのみをレンダリングします。react-window (React) やCDK Virtual Scrollingモジュール (Angular) のようなライブラリは、DOMノード数を数千ではなく、表示されているアイテム（通常10～30ノード）だけに抑えます。
メモリを大量消費するJavaScriptを避ける。
ページ上で大量のDOMノードを扱う際は、JavaScriptに特に注意してください。document.getElementsByTagName('div');は大量のDOMノードを読み込む可能性があり、メモリ使用量を増加させます。
複雑なCSS宣言を避ける。
ページ上で大量のDOMノードを扱う際は、複雑なCSS宣言に特に注意してください。div:last-child;はページ上のすべてのdivに対してlast-childの状態をチェックする必要があります。セレクタが単純であればあるほど、ブラウザのトラバーサル作業は少なくなります。これはINPにとって最も重要であり、スタイルの再計算は1ミリ秒単位で重要になります。

DOMサイズを削減した後、Real User Monitoringを使用して実際のユーザーへの影響を追跡してください。CoreDashのデータによると、DOMノード数を1,500以下に削減すると、モバイルデバイスでのINPが通常35%改善します。

著者について

Arjen Karelはウェブパフォーマンスコンサルタントであり、数百のサイトでCore Web Vitalsデータを追跡するReal User MonitoringプラットフォームであるCoreDashの作成者です。また、CLS Visualizer Chrome拡張機能も開発しました。彼はクライアントが925,000以上のモバイルURLでCore Web Vitalsの合格スコアを達成するのを支援してきました。