DOM (Document Object Model) е програмен интерфейс за HTML и XML документи и наименование на структурата на HTML документ, състояща се от разклонения и възли, съдържащи обекти.
Историята на модела на обекта на документа датира от така наречените"войни на браузърите" в края на 90-те години на миналия век между Netscape Navigator и Microsoft Internet Explorer, както и JavaScript и JScript - първите скриптови езици, които бяха широко реализирани в JavaScript енджините на уеб браузърите.
DOM структура в WordPress: дърво, клони и възли
DOM в WordPress не се различава много от този на всеки друг уебсайт.
<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>и т.н. представлява клон от дървото. - Възли: Всички елементи на HTML, като
<p>,<img>или<a>, са възли, които висят на разклонения. Тези възли могат да бъдат вътрешни (съдържащи други възли) или външни ("листата" на дървото, които нямат други деца).
По този начин плътността на клоните ще зависи от вида и броя на елементите, които ги изграждат. Например едно сложно навигационно меню в WordPress може да генерира няколко нива на разклонения и десетки възли поради броя на връзките и подменютата.
Можете да си представите възлите като всички HTML елементи на страницата. Колкото повече са елементите, толкова повече време отнема страницата, което води до по-голямо общо време на блока(TBT).
Оптимизирането на този процес в WordPress може да се окаже трудно, тъй като не можете просто да премахнете елементите DOM, които изграждат структурата на страницата. Можем обаче избирателно да показваме тези елементи и да зареждаме низ от обекти под сгъвката, като по този начин намаляваме общия размер на DOM.
Защо да намалявате размера на DOM?
Обемистото дърво на DOM може да забави времето за зареждане на сайта ви по няколко начина, като увеличи използването на паметта, причинявайки по-дълги и по-бавни изчисления на стила, както и да изразходва ненужни разходи за данни за потребителите.
Тези различни сценарии могат да включват ненужно зареждане на възли, които не са видими при първото зареждане на страницата от потребителя, постоянно повтаряне на изчисленията на позицията на възлите и стила, както и съхраняване на прекомерен брой препратки към възли, които претоварват паметта на устройствата на потребителите.
Краткосрочните и дългосрочните ползи от оптимизирането на скоростта на зареждане на страницата вече са обяснени в хиляди и една статии. Накратко, в краткосрочен план избягвате хората да напускат страницата ви, отегчени от чакането, и най-вероятно те ще прекарат повече време на нея и ще посетят повече страници, което намалява процента на отпадане. Скоростта на зареждане е един от факторите, признати от Google при SEO позициониране, а разбирам, че е така и за останалите търсачки, така че в дългосрочен план ценният органичен трафик ще се увеличи.
Какво причинява увеличаването на размера на DOM?
Окончателният размер на DOM се влияе от много фактори, като например самия шаблон, какво добавят различните плъгини, които използвате, и вида на съдържанието, което добавяте, като например сложни блокове или гнусните "плъзгачи" на изображения и т.н. . Също така кодът, генериран от някои "Builders".
Например до 2022 г., годината, в която се отказах от Elementor, защото той се съпротивляваше на оптимизацията и рядко се случваше да не счупи нещо при почти всяка актуализация, плюс няколко лоши опита с техническата им поддръжка, този конструктор превърна уеб кода в истинска азбучна супа и кошмар с хиляди
През април същата година Elementor включи "контейнера" Flexbox като съвсем нова и революционна новост, докато контейнерът вече беше в основата на GenerateBlocks от години.
Как да измерваме DOM?
За измерването избрах публикация, която все още не е много оптимизирана, малко дълга и с различни видове елементи.
Нека започнем с най-известната и най-популярната: PageSpeed Insights . Там Google отбелязва като предупреждение(в оранжево), когато елементът body има повече от 800 възела, и като съобщение за грешка(в червено), когато елементът body има повече от 1400 възела, и съобщение със следната препоръка:"Избягвайте прекомерния размер на DOM".
В зависимост от съдържанието и структурата на всяка страница, която анализирате, ще намерите повече или по-малко подсказки за това кои елементи можете да атакувате. Предимството е, че обикновено се показва изображение, насочващо към въпросния елемент.
Още веднъж искам да ви напомня, че всички тези предупреждения са само препоръки и че не трябва да изпадате в паника или да се вманиачавате по тези показатели. Има страници, които предлагат добро потребителско изживяване и добра възприемана скорост с ниски резултати по PageSpeed.
С GTmetrix като цяло ще получим същите резултати в DOM.
Въпреки това тук неговата графика на заявките "водопад" е много полезна, за да се разгледат с един поглед всички елементи, подредени по вид и по времето, което отнема зареждането им.
Други подобни опции са Pingdom или isitwp.
Но най-лесният и бърз начин е чрез всеки браузър. Отворете страницата, която искате да анализирате, и щракнете с десния бутон на мишката / "инспектирай" и в раздела "Мрежа" ще намерите много по-подробен водопад , защото можете да го завършите, като превъртите страницата и всички заявки ще бъдат добавени към списъка. След това можете да ги сортирате по тегло, тип, време и т.н.
Под този прозорец ще намерите обобщение на резултатите. Вляво е броят на заявките. Вдясно, в синьо, времето на събитието DOMContentLoaded, а в червено - времето за зареждане на тази страница.
Намаляване на размера на DOM с "мързеливи елементи" на Perfmatters.
Perfmatters, този важен плъгин, който никога не се уморявам да препоръчвам, добави в своята версия 2.3.3 от 28 август 2024 г. опция, наречена Lazy Elements, която, въпреки че все още е в бета версия, работи наистина добре за улесняване на задачата за олекотяване на DOM.
Тази функция позволява добавянето на неправилното наименование "LazyLoad" (мързеливозареждане) към определени елементи и техните наследници (деца) чрез добавяне на всяка отделна част от низ от атрибути (class="example") на родителския контейнер.
Можете също така да добавите класа perfmatters-lazy-element към конкретен контейнер в използвания от вас шаблон или конструктор на страници.
В документацията, предоставена от Perfmatters за тази нова функционалност, сме предупредени да не се опит ваме да прилагаме "мързеливо зареждане" за елементи, които са над сгъвката. Тоест това, което се зарежда на екрана и е първото нещо, което потребителят вижда, без да скролва надолу.
Също така е отбелязано, че ако видите, че нещо е визуално счупено, уверете се, че сте използвали уникален низ на страницата, който не се споделя с други елементи.
Както и при бавно зареждащите се изображения, съдържанието се поставя в . Това означава, че всичко, което се зарежда мързеливо, все още е технически достъпно за обхождане и индексиране от Google. Въпреки това те не могат да кажат със сигурност как Google ще третира елементите с Lazy Load в низ. Затова препоръчват от гледна точка на SEO оптимизацията първо да се тества.
Той също така предупреждава да не се опитвате да прилагате Lazy Load към елементи, съдържащи изображения, които стартират "lightbox". И така е, успях да проверя, че нативната функция Lightbox на WordPress спира да работи, когато класът на елемент, който я реализира, се добави към списъка.
В противен случай "мързеливи елементи" работи перфектно. Благодарение на тази функция спестих много време за редене на DOM с добри резултати. Надявам се, че Perfmatters ще продължи развитието си, за да подобри и разшири възможностите си.
