O DOM (Document Object Model) é uma interface de programação para documentos HTML e XML e o nome dado à estrutura de um documento HTML, composta por ramos e nós que contêm objectos.
A história do Modelo de Objeto de Documento remonta às chamadas"guerras dos browsers" do final dos anos 90 entre o Netscape Navigator e o Microsoft Internet Explorer, bem como ao JavaScript e ao JScript, as primeiras linguagens de scripting a serem amplamente implementadas nos motores JavaScript dos browsers da Web.
Estrutura DOM no WordPress: árvore, ramos e nós
O DOM no WordPress não é muito diferente de qualquer outro sítio Web.
<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)
- Árvore: A página inteira é representada como uma árvore com um nó raiz
(<html>)e seus elementos filhos. - Ramos: Cada elemento dentro de um
<div>,<header>,<footer>,etc.,representa um ramo da árvore. - Nós: Todos os elementos HTML, como
<p>,<img>,ou<a>,são nós que pendem de ramos. Esses nós podem ser internos (contendo outros nós) ou externos (as "folhas" da árvore que não têm outros filhos).
Assim, a densidade dos ramos dependerá do tipo e do número de elementos que o compõem. Por exemplo, um menu de navegação complexo no WordPress pode gerar vários níveis de ramificações e dezenas de nós devido ao número de ligações e submenus.
Pode pensar nos nós como todos os elementos HTML de uma página. Quanto mais elementos tiver, normalmente mais tempo demora, o que leva a um Tempo Total de Bloqueio(TBT) mais elevado.
Isto pode ser uma coisa complicada de otimizar no WordPress, uma vez que não se pode simplesmente remover os elementos DOM que compõem a estrutura de uma página. No entanto, podemos exibir esses elementos de forma selectiva e carregar uma sequência de objectos abaixo da dobra, reduzindo assim o tamanho total do DOM.
Porquê reduzir o tamanho do DOM?
Uma árvore DOM volumosa pode abrandar o tempo de carregamento do seu sítio de várias formas, aumentando a utilização de memória ao provocar cálculos de estilo mais longos e mais lentos, bem como gastando custos de dados desnecessários para os utilizadores.
Estes diferentes cenários podem incluir o carregamento desnecessário de nós que não são visíveis quando o utilizador carrega a página pela primeira vez, a repetição constante de cálculos de posição e estilo de nós e o armazenamento de um número excessivo de referências a nós que sobrecarregam a memória dos dispositivos dos utilizadores.
Os benefícios a curto e longo prazo da otimização da velocidade de carregamento da página já foram explicados em mil e um artigos. Resumindo, a curto prazo evita que as pessoas deixem o seu sítio aborrecidas de esperar e, muito provavelmente, passarão mais tempo no mesmo. A velocidade de carregamento é um dos factores reconhecidos pelo Google no posicionamento SEO e, segundo sei, também o é para os restantes motores de busca, pelo que, a longo prazo, o precioso tráfego orgânico aumentará.
O que faz com que a DOM aumente de tamanho?
O tamanho final do DOM é influenciado por muitos factores, como o próprio modelo, o que os diferentes plugins que utiliza acrescentam e o tipo de conteúdo que adiciona, como blocos complexos ou os nefastos "sliders" de imagens, etc. . Também o código gerado, por exemplo, pelos chamados "Builders".
Por exemplo, até 2022, ano em que abandonei o Elementor porque resistia à otimização e era raro que não partisse alguma coisa em quase todas as actualizações, além de um par de más experiências com o seu apoio técnico, este construtor transformou o código web numa verdadeira sopa de letras e num pesadelo com milhares de
Em abril do mesmo ano, o Elementor incorporou o "Container" Flexbox como uma novidade muito nova e revolucionária, quando o contentor já era a base do GenerateBlocks há anos.
Como medir a DOM?
Para a medição, escolhi um post que ainda não está muito optimizado, um pouco longo e com diferentes tipos de elementos.
Comecemos pelo mais conhecido e mais popular: PageSpeed Insights . O Google assinala como aviso(a laranja) quando o elemento body tem mais de 800 nós e como mensagem de erro(a vermelho) quando o elemento body tem mais de 1400 nós e uma mensagem com esta recomendação:"Evitar o tamanho excessivo do DOM".
Dependendo do conteúdo e da estrutura de cada página que analisar, encontrará mais ou menos pistas sobre os elementos que pode atacar. A vantagem é que normalmente mostra uma imagem que aponta para o elemento em questão.
Mais uma vez, gostaria de lembrar que todos estes alertas são apenas recomendações e que não deve entrar em pânico ou ficar obcecado com estas métricas. Há páginas que oferecem uma boa experiência ao utilizador e uma boa velocidade percebida com pontuações PageSpeed baixas.
Com o GTmetrix, obteremos geralmente os mesmos resultados no DOM.
No entanto, aqui o seu gráfico de "cascata" de pedidos é muito útil para inspecionar num relance todos os itens ordenados por tipo e pelo tempo que demoram a carregar.
Mas a forma mais fácil e rápida é através de qualquer browser. Abra a página a analisar e clique com o botão direito do rato / "inspecionar" e, no separador "Rede", encontrará uma cascata muito mais detalhada, pois pode completá-la percorrendo a página e todos os ficheiros que ela contém serão adicionados. Pode então ordená-los por peso, tipo, tempo, etc.
Abaixo desta janela, encontra-se um resumo dos resultados. À esquerda, o número de pedidos. À direita, em azul, o tempo do evento DOMContentLoaded e em vermelho o tempo de carregamento dessa página.
Reduzir o tamanho do DOM com os "Lazy Elements" do Perfmatters.
O Perfmatters, esse plugin essencial que não me canso de recomendar, adicionou na sua versão 2.3.3 de 28 de agosto de 2024 uma opção chamada Lazy Elements que, embora ainda em Beta, funciona muito bem para facilitar a tarefa de aligeirar o DOM.
Esta função permite adicionar o mal chamado"Lazy Load" a elementos específicos e aos seus descendentes (filhos), adicionando qualquer parte de uma cadeia de atributos (class="example") de um contentor principal.
Na documentação fornecida pela Perfmatters sobre esta nova funcionalidade, somos avisados para não tentar aplicar o "Lazy Load" a elementos que estão acima da dobra. Ou seja, o que é carregado no ecrã e a primeira coisa que o utilizador vê sem fazer scroll para baixo.
Note-se ainda que, se vir que algo está visualmente partido, certifique-se de que utilizou uma cadeia de caracteres única na página que não é partilhada com outros elementos.
Tal como acontece com as imagens de carregamento lento, o conteúdo é colocado dentro de um ficheiro . Isso significa que qualquer coisa que carregue lentamente ainda é tecnicamente rastreável e indexável pelo Google. No entanto, não podem dizer com certeza como o Google tratará os elementos com Lazy Load numa cadeia de caracteres. Por isso, recomendam, em termos de SEO, testar primeiro.
Também avisa para não tentar aplicar o Lazy Load a elementos que contenham imagens que iniciem uma "lightbox". E assim é, consegui verificar que a função lightbox nativa do WordPress deixa de funcionar quando a classe de um elemento que a implementa é adicionada à lista.
Caso contrário, "Lazy Elements" funciona perfeitamente. Graças a esta funcionalidade, poupei muito tempo a diluir o DOM com bons resultados. Espero que o Perfmatters continue o seu desenvolvimento para melhorar e expandir as suas opções.
