DOM (문서 객체 모델)은 HTML 및 XML 문서를 위한 프로그래밍 인터페이스로, 객체를 포함하는 브랜치와 노드로 구성된 HTML 문서의 구조에 부여된 이름입니다.
문서 객체 모델의 역사는 1990년대 후반 넷스케이프 네비게이터와 마이크로소프트 인터넷 익스플로러, 그리고 웹 브라우저의 자바스크립트 엔진에 널리 구현된 최초의 스크립트 언어인 자바스크립트 및 JScript 간의 이른바'브라우저 전쟁'으로 거슬러 올라갑니다.
워드프레스의 DOM 구조: 트리, 브랜치 및 노드
워드프레스의 DOM은 다른 웹사이트와 크게 다르지 않습니다.
<html> <-- Árbol (nodo raíz)
│
├── <head> <-- Rama
│ ├── <title> <-- Nodo (hoja)
│ └── <meta> <-- Nodo (hoja)
│
└── <body> <-- Rama
├── <header> <-- Rama
│ └── <h1> <-- Nodo (hoja)
│
├── <div> <-- Rama
│ ├── <p> <-- Nodo (interno)
│ └── <img> <-- Nodo (hoja)
│
└── <footer> <-- Rama
└── <a> <-- Nodo (hoja)
- 트리: 전체 페이지가 루트 노드
(<html>)
와 그 하위 요소로 구성된 트리로 표시됩니다. - 브랜치:
<div>,
<header>,
<footer>
등의 각요소는
트리의 가지를 나타냅니다. - 노드:
<p>,
<img>
또는<a>와
같은 모든 HTML 요소는 가지에 매달려 있는 노드입니다. 이러한 노드는 내부(다른 노드를 포함)이거나 외부(더 이상 자식이 없는 트리의 '잎')일 수 있습니다.
따라서 분기의 밀도는 분기를 구성하는 요소의 유형과 수에 따라 달라집니다. 예를 들어 워드프레스의 복잡한 탐색 메뉴는 링크와 하위 메뉴의 수에 따라 여러 수준의 분기와 수십 개의 노드를 생성할 수 있습니다.
노드는 페이지에 있는 모든 HTML 요소로 생각할 수 있습니다. 요소가 많을수록 일반적으로 시간이 오래 걸리므로 총 블록 시간(TBT)이 길어집니다.
페이지 구조를 구성하는 DOM 요소를 단순히 제거할 수 없기 때문에 워드프레스에서 최적화하기 까다로운 작업일 수 있습니다. 하지만 이러한 요소를 선택적으로 표시하고 접힌 부분 아래에 일련의 객체를 로드하여 DOM의 전체 크기를 줄일 수 있습니다.
DOM 크기를 줄이는 이유는 무엇인가요?
부피가 큰 DOM 트리는 여러 가지 방식으로 사이트의 로드 시간을 늦출 수 있으며, 스타일 계산이 길어지고 느려져 메모리 사용량이 증가하고 사용자에게 불필요한 데이터 비용이 지출될 수 있습니다.
이러한 다양한 시나리오에는 사용자가 페이지를 처음 로드할 때 보이지 않는 불필요한 노드 로드, 노드 위치 및 스타일 계산이 지속적으로 반복되는 경우, 사용자 디바이스의 메모리에 과부하를 주는 과도한 수의 노드 참조 저장 등이 포함될 수 있습니다.
페이지 로딩 속도 최적화의 장단기적 이점은 이미 수많은 글에서 설명한 바 있습니다. 요컨대, 단기적으로는 사람들이 기다리다 지쳐서 사이트를 떠나는 것을 방지하고 사이트에 더 많은 시간을 보낼 가능성이 높습니다. 로딩 속도는 SEO 포지셔닝에서 Google이 인정하는 요소 중 하나이며 나머지 검색 엔진에서도 마찬가지이므로 장기적으로는 귀중한 유기적 트래픽이 증가 할 것으로 이해합니다.
DOM 크기가 커지는 원인은 무엇인가요?
DOM의 최종 크기는 템플릿 자체, 사용하는 다양한 플러그인이 추가하는 내용, 복잡한 블록이나 이미지의 사악한 "슬라이더" 등 추가하는 콘텐츠 유형 등 여러 요소의 영향을 받습니다. 또한 소위 "빌더"에 의해 생성된 코드도 영향을 받습니다.
예를 들어, 최적화에 저항하고 거의 모든 업데이트에서 무언가를 깨뜨리지 않는 경우가 드물고 기술 지원에 대한 몇 가지 나쁜 경험과 더불어이 빌더가 웹 코드를 실제 알파벳 수프와 수천 개의 .
같은 해 4월, Elementor는 컨테이너가 이미 수년간 생성블록의 기반이 되어 왔던 플렉스박스 '컨테이너' 를 매우 새롭고 혁신적인 신제품으로 통합했습니다.
DOM은 어떻게 측정하나요?
측정을 위해 아직 최적화되지 않은, 약간 길고 다양한 유형의 요소가 있는 게시물을 선택했습니다.
가장 잘 알려져 있고 가장 많이 사용되는 페이지스피드 인사이트부터 시작하겠습니다. Google은 본문 요소에 800개 이상의 노드가 있으면 경고(주황색)로, 본문 요소에 1,400개 이상의 노드가 있으면 오류 경고(빨간색)로 표시하고"과도한 DOM 크기 피하기"라는 권장 사항과 함께 메시지를 표시합니다.

분석하는 각 페이지의 콘텐츠와 구조에 따라 공격할 수 있는 요소에 대한 단서를 어느 정도 찾을 수 있습니다. 장점은 일반적으로 해당 요소를 가리키는 이미지가 표시된다는 것입니다.
다시 한 번 말씀드리지만, 이러한 알림은 모두 권장 사항일 뿐이며 이러한 지표에 당황하거나 집착해서는 안 됩니다. 페이지 속도 점수가 낮지만 좋은 사용자 경험과 체감 속도를 제공하는 페이지도 있습니다.
GTmetrix를 사용하면 일반적으로 DOM에서 동일한 결과를 얻을 수 있습니다.

그러나 여기서는 요청의 '폭포수' 그래프를 통해 모든 항목을 유형별, 로드 시간별로 정렬하여 한눈에 살펴볼 수 있습니다.

그러나 가장 쉽고 빠른 방법은 모든 브라우저를 이용하는 것입니다. 분석할 페이지를 열고 마우스 오른쪽 버튼으로 클릭 / "검사"를 클릭하면 "네트워크" 탭에서 페이지를 스크롤하여 완료할 수 있고 포함된 모든 파일이 추가되므로 훨씬 더 자세한 워터폴을 찾을 수 있습니다. 그런 다음 무게, 유형, 시간 등을 기준으로 정렬할 수 있습니다.

이 창 아래에는 결과 요약이 표시됩니다. 왼쪽에는 요청 수가 표시됩니다. 오른쪽의 파란색은 DOMContentLoaded 이벤트 시간, 빨간색은 해당 페이지의 로드 시간입니다.
퍼프매터스의 '레이지 엘리먼트'로 DOM 크기를 줄이세요.
제가 추천해도 질리지 않는 필수 플러그인 Perfmatters는 2024년 8월 28일 버전 2.3.3에서 아직 베타 버전이지만 DOM을 가볍게 만드는 작업을 원활하게 하는 데 매우 효과적인 Lazy Elements라는 옵션을 추가했습니다.

이 함수를 사용하면 부모 컨테이너의 속성 문자열(예시)의 단일 부분을 추가하여 특정 요소와 그 하위 요소(자식)에 잘못된 이름의"지연 로드"를 추가할 수 있습니다.
퍼프매터스가 이 새로운 기능에 대해 제공한 문서에는 스크롤 위에 있는 요소에 '지연 로드'를 적용하지 말라는 경고가 있습니다. 즉, 사용자가 아래로 스크롤하지 않고 가장 먼저 보게 되는 화면에서 로드되는 내용입니다.
시각적으로 무언가가 깨진 것을 발견하면 페이지에서 다른 요소와 공유되지 않는 고유한 문자열을 사용했는지 확인하세요.
느리게 로드되는 이미지와 마찬가지로 콘텐츠는 . 즉, 느리게 로드되는 모든 콘텐츠는 기술적으로 여전히 Google에서 크롤링 및 색인화할 수 있습니다. 그러나 Google이 문자열에서 지연 로드가 있는 요소를 어떻게 처리할지는 확실하게 말할 수 없습니다. 따라서 SEO 측면에서 먼저 테스트해 볼 것을 권장합니다.
또한 '라이트박스'를 시작하는 이미지가 포함된 요소에 지연 로드를 적용하지 말라고 경고합니다. 그래서 저는 네이티브 워드프레스 라이트박스 기능이 이를 구현하는 요소의 클래스가 목록에 추가되면 작동이 중지되는 것을 확인할 수 있었습니다.
그렇지 않으면 '게으른 요소'가 완벽하게 작동합니다. 이 기능 덕분에 DOM을 얇게 만드는 데 많은 시간을 절약하고 좋은 결과를 얻을 수 있었습니다. Perfmatters가 계속 개발하여 옵션을 개선하고 확장하기를 바랍니다.