DOM（DocumentObject Model）とは、HTML文書やXML文書のためのプログラミング・インターフェースであり、オブジェクトを含む枝とノードで構成されるHTML文書の構造につけられた名前である。
Document Object Modelの歴史は、1990年代後半のNetscape NavigatorとMicrosoft Internet Explorerのいわゆる「ブラウザ戦争」、そしてウェブブラウザのJavaScriptエンジンに広く実装された最初のスクリプト言語であるJavaScriptとJScriptにまでさかのぼる。
WordPressのDOM構造：ツリー、ブランチ、ノード
WordPressのDOMは、他のウェブサイトとあまり変わりません。
<html> <-- ツリー (ルートノード)
│
├── <head> <-- 支店
│ ├── <title> <-- ノード（葉）
│ └── <meta> <-- ノード（葉）
│
└── <body> <-- 支店
├── <header> <-- 支店
│ └── <h1> <-- ノード（葉）
│
├── <div> <-- 支店
│ ├── <p> <-- ノード（内部）
│ └── <img> <--ノード（葉）
│
└── <footer> <-- 支店
└── <a> <-- ノード（葉）
- ツリー：ページ全体は、ルートノード
（<html>）とその子要素を持つツリーとして表現されます。 - 枝：
<div>、<header>、<footer>などの中の各要素は、ツリーの枝を表します。 - ノード：
<p>、<img>、<a>などのすべてのHTML要素は、枝からぶら下がるノードです。これらのノードは内部ノード（他のノードを含む）と外部ノード（他の子を持たないツリーの「葉」）があります。
したがって、ブランチの密度は、それを構成する要素の種類と数に依存します。例えば、WordPressの複雑なナビゲーションメニューは、リンクやサブメニューの数により、数レベルの分岐と数十のノードを生成することができます。
ノードは、ページ上のすべてのHTML要素と考えることができます。要素が多ければ多いほど、通常は時間がかかり、総ブロック時間（TBT）が長くなります。
ページの構造を構成するDOM要素を単純に削除することはできないからだ。しかし、これらの要素を選択的に表示し、フォールドの下にオブジェクトの連鎖を読み込むことで、DOM全体のサイズを小さくすることができます。
なぜDOMのサイズを小さくするのか？
かさばる DOM ツリーは、サイトのロード時間をいくつかの方法で遅くし、スタイルの計算が長くなることでメモリ使用量を増やし、ユーザーに不必要なデータ コストを費やす可能性があります。
このようなさまざまなシナリオには、ユーザーが最初にページをロードしたときに表示されないノードの不要なロード、ノードの位置とスタイルの計算の一定ベースでの繰り返し、ユーザーのデバイスのメモリに過負荷をかけるノードへの過剰な数の参照の保存などが含まれます。
ページの読み込み速度を最適化することの短期的なメリットと長期的なメリットは、すでに千差万別の記事で説明されている。要するに、短期的には、待ちくたびれた人々があなたのサイトから離れるのを防ぎ、より多くの時間をサイトに費やしてくれる可能性が高いということです。読み込み速度は、SEOのポジショニングにおいてGoogleが認識する要素の一つであり、他の検索エンジンにとっても同様であると私は理解しています。
DOMが大きくなる原因は何ですか？
DOMの最終的なサイズは、テンプレート自体、使用するさまざまなプラグインが追加するもの、複雑なブロックや画像の極悪な「スライダー」など追加するコンテンツの種類など、多くの要因に影響されます。また、例えばいわゆる「ビルダー」によって生成されるコードも影響します。
例えば、2022年まで、Elementorは 最適化に抵抗があり、ほとんどすべてのアップデートで何かが壊れないことは稀だったため、私はElementorを見捨てた 。
同じ年の4月、ElementorはFlexboxの「コンテナ」を非常に新しく画期的なものとして取り入れた。
DOMの測定方法は？
測定には、まだあまり最適化されておらず、少し長く、さまざまなタイプの要素を含む記事を選んだ。
まず、最も有名で人気のあるPageSpeedInsightsから見て みよう。Googleは、body要素に800以上のノードがあると警告（オレンジ色）、body要素に1,400以上のノードがあるとエラー警告（赤色）としてマークし、この勧告のメッセージを表示します："過度のDOMサイズを避ける"。
分析する各ページの内容や構造によって、どの要素を攻撃できるかの手がかりが多かれ少なかれ見つかるだろう。利点は、通常、問題の要素を指し示す画像が表示されることです。
繰り返しになるが、これらの警告はすべて推奨に過ぎず、パニックに陥ったり、これらの指標にとらわれたりしてはならない。PageSpeedのスコアが低くても、良好なユーザーエクスペリエンスと良好な知覚速度を提供するページがあります。
GTmetrixを使えば、DOM上で同じ結果が得られる。
しかしここでは、リクエストの "ウォーターフォール "グラフは、すべてのアイテムをタイプ別に、ロードにかかる時間ごとにソートして一目で検査するのに非常に役立つ。
しかし、最も簡単で迅速な方法は、任意のブラウザを使用することです。分析したいページを開き、右クリック／"inspect "で "Network "タブを開くと、より詳細なウォーターフォールが 表示される。そして、重量、タイプ、時間などでソートすることができる。
このウィンドウの下に、結果の概要が表示されます。左はリクエスト数。右側は、青がDOMContentLoadedイベントの時間、赤がそのページのロード時間です。
Perfmattersの "Lazy Elements "でDOMサイズを削減。
Perfmattersは、2024年8月28日にリリースされたバージョン2.3.3で、Lazy Elementsというオプションが追加された。
この関数は、親コンテナの属性文字列(class="example")の任意の一部分を追加することで、特定の要素やその子孫(子)に「遅延ロード」という誤った名前を付けることを可能にします。
Perfmattersが提供するこの新機能に関するドキュメントでは、フォールドより上にある要素に "Lazy Load "を適用しようとしないよう警告されている。つまり、画面上にロードされ、ユーザーがスクロールダウンせずに最初に目にするものです。
さらに、何かが視覚的に壊れていることがわかったら、他の要素と共有されていない、ページ上でユニークな文字列を使用していることを確認するよう注意されたい。
読み込みの遅い画像と同様に、コンテンツは .つまり、遅延ロードされるものは、技術的にはまだGoogleによってクロール可能であり、インデックス可能である。しかし、文字列の中にLazy Loadを含む要素をGoogleがどのように扱うかは断言できない。そのため、SEOの観点からは、まずテストすることを推奨している。
また、「lightbox」を開始する画像を含む要素にLazy Loadを適用しようとしないよう警告している。そしてその通り、WordPressネイティブのライトボックス 機能は、それを実装する要素のクラスがリストに追加されると動作しなくなることが確認できました。
そうでなければ、"Lazy Elements "は完璧に機能する。この機能のおかげで、私はDOMを間引く時間を大幅に節約し、良い結果を得ることができた。Perfmattersが今後も開発を続け、そのオプションを改善・拡張してくれることを願っている。
