O Caminho de Renderização Crítica é a sequência de tarefas que o navegador executa para primeiro renderizar uma página na tela, ou seja, para baixar, processar e converter código HTML, CSS e JavaScript em pixels reais, e pintá-los na tela.
A Otimização do Caminho de Renderização Crítica é o processo de minimizar o tempo gasto pelo navegador para realizar cada etapa da seqüência priorizando a exibição do conteúdo relacionado com a ação atual do usuário.
Grande parte deste processo diz respeito à parte da página que é visível sem rolar pela janela do navegador. Essa seção também é conhecida como Above the Fold. Para uma melhor usabilidade, a ATF deve ser entregue o mais rápido possível, e isto pode ser feito reduzindo ao mínimo o número de viagens de ida e volta da rede. Os recursos necessários para renderizar a ATF são considerados críticos, e otimizar o Above the Fold significa minimizar o impacto dos recursos críticos no tempo para a primeira renderização da página.
Neste post, vamos caminhar pela seqüência de otimização do Critical Rendering Path.
- Em primeiro lugar, vou fornecer uma visão geral das tarefas que o navegador executa para renderizar o conteúdo de uma página.
- Em seguida, vou dissecar as ações mais relevantes que podemos realizar para otimizar o Caminho de Renderização Crítica.
- Finalmente, vou listar alguns plugins de otimização WordPress úteis (e populares).
A Sequência do Caminho de Renderização Crítica
Aqui está a sequência de passos executados pelo navegador para renderizar uma página:
- Primeiro, o navegador faz o download e analisa a marcação HTML e constrói o DOM
- Em seguida, faz o download e processa a mark-up do CSS e constrói o Modelo de Objetos CSS
- Ela combina nós DOM e CSSOM necessários para renderizar a página na árvore de renderização, que é uma estrutura de árvore de todos os nós visíveis
- Ele calcula as dimensões e a posição de cada objeto na página
- Finalmente, pinta pixels na tela
O DOM
Como bem explicado no guia Optimização do Caminho de Renderização Crítica do Google, o browser constrói o Modelo de Objetos de Documento numa sequência de quatro passos:
- Primeiro, o navegador lê os bytes de linha e os traduz para caracteres individuais.
- Depois converte as cordas dos caracteres entre parênteses angulares em fichas
- Estes tokens são convertidos em objetos de nó
- Os objetos de nó são ligados em uma estrutura de dados em forma de árvore que contém conteúdo HTML, propriedades e todas as relações entre os nós. Esta estrutura é o Modelo de Objeto de Documento.
O que é importante notar aqui é que o navegador constrói o DOM de forma incremental. Isto dá-nos a oportunidade de acelerar a renderização da página através da criação de estruturas DOM eficientes.
O CSSOM
Quando o analisador encontra uma tag de link que se refere a uma folha de estilo CSS externa, ele bloqueia o analisador e envia um pedido para este recurso. Uma vez recebido o arquivo CSS, o navegador começa a construir uma estrutura de dados em árvore dos nós CSS.
- O navegador lê os bytes de linha do arquivo . css e os traduz para caracteres individuais
- Converte as cordas de caracteres entre parênteses curvos em fichas
- Estes tokens são convertidos em objetos de nó
- Os objetos de nó são ligados em uma estrutura de dados em forma de árvore que contém as propriedades CSS de cada nó, e as relações entre nós. Esta estrutura é o Modelo de Objetos CSS (CSSOM).
Ao contrário da construção DOM, a construção CSSOM não é incremental. O navegador não pode usar uma parte de uma folha de estilos, porque os estilos podem ser refinados e redeclarados na mesma folha de estilos. Por este motivo, o navegador bloqueia o processo de renderização até receber e analisar todo o CSS. Isto significa que o CSS está a tornar o bloqueio.
A árvore de Renderização
O navegador combina DOM e CSSOM na árvore de renderização, que é a estrutura de árvore final contendo todos os nós e propriedades que estão sendo usados para renderizar a página para a tela.
A árvore de Renderização contém apenas os nós necessários para renderizar uma página. Como consequência, os nós invisíveis são omitidos.
O navegador usa a árvore de Renderização para calcular as dimensões e a posição do nó e, finalmente, como um input para o processo de pintura.
Layout e Pintura
Na etapa de layout, o navegador calcula as dimensões e a posição de cada nó da árvore de Renderização. Nesta fase, o navegador atravessa a árvore Render a partir da sua raiz e produz um modelo de caixa. Esta informação é finalmente utilizada para converter cada nó da árvore de renderização em pixels reais na tela.
Otimização do Caminho de Renderização Crítica
O tempo necessário para executar o processo inteiro pode ser variável. Depende de muitos fatores como o tamanho do documento, o número de pedidos, os estilos aplicados, o dispositivo do usuário, etc.
Uma das recomendações mais relevantes do Google é priorizar o conteúdo visível de modo a tornar o Above the Fold o mais rápido possível, e fornece duas regras principais a seguir:
- Estruturar o HTML para carregar primeiro o conteúdo crítico, acima do conteúdo dobrado
- Reduzir a quantidade de dados utilizados pelos recursos HTML, CSS e JS
Como bem explicado no guia PageSpeed do Google, se a quantidade de dados necessários para renderizar a ATF exceder a janela inicial de congestionamento (14,6kb), será necessário fazer viagens adicionais de ida e volta à rede entre o servidor e o navegador. Em redes móveis, com altas latências, isso atrasaria significativamente o carregamento da página (leia-se more on latency).
O browser constrói o DOM de forma incremental, e isto dá-nos a oportunidade de reduzir o tempo necessário para renderizar a ATF, estruturando o HTML de modo a carregar primeiro o acima-dobrável e adiar o resto da página.
Mas a otimização não termina com a construção de uma estrutura DOM eficaz. Ao contrário, é um processo de melhoria e medição que envolve toda a sequência do Critical Rendering Path.
Vamos mergulhar fundo.
Minimizar as dimensões dos recursos
Podemos reduzir a quantidade de dados que o navegador vai baixar, minificando, comprimindo e armazenando em cache recursos HTML, CSS e JavaScript:
- Minificação é o processo de remover caracteres desnecessários como comentários e espaço em branco do código fonte. Estes caracteres são extremamente úteis no desenvolvimento, mas são inúteis para o navegador para renderizar a página.
- Compressão é a capacidade dos servidores web e clientes de reduzir o tamanho dos arquivos transmitidos, a fim de melhorar a velocidade e a utilização da largura de banda
- Caching: cada browser vem com uma implementação de um cache HTTP. O que precisamos fazer é garantir que cada resposta do servidor forneça os cabeçalhos HTTP corretos para instruir o navegador sobre quando e por quanto tempo ele deve armazenar os recursos solicitados.
Optimize o CSS
Agora sabemos que o navegador tem que esperar até que ele pegue e processe o código CSS antes que ele possa renderizar a página (CSS é o bloqueio de renderização). Mas nem todos os recursos do CSS estão a bloquear a renderização.
O CSS pode ser escopo para condições particulares, e podemos otimizá-lo usando tipos de mídia e consultas de mídia. Se você estiver visualizando uma página na tela, o navegador enviará um pedido de tipo de mídia impressa, mas não bloqueará a renderização da página para este recurso.
Pegue a seguinte etiqueta de link:
<link rel="stylesheet" href="style.css" />A folha de estilo referenciada desta etiqueta aplica-se em qualquer condição, independentemente do tipo de mídia atual, resolução de tela, orientação do dispositivo, etc. Isto significa que o recurso CSS está sempre em bloqueio de renderização.
Felizmente, podemos enviar um pedido para um recurso CSS sob condições específicas. Podemos mover estilos de impressão para um arquivo separado e usar o atributo de media para dizer ao navegador que a folha de estilo especificada só deve ser carregada ao imprimir a página, e não precisa bloquear a renderização na tela:
<link rel="stylesheet" href="print.css" media="print" />O navegador ainda faz o download da folha de estilo print.css, mas ela não bloqueia a renderização. Além disso, o navegador tem que baixar menos dados para o arquivo CSS principal, o que nos ajudaria a acelerar o download. Podemos especificar qualquer consulta de mídia no atributo do link, para que possamos dividir o CSS em vários arquivos e carregá-los condicionalmente:
<link rel="stylesheet" href="style.css" media="screen" />
<link rel="stylesheet" href="portrait.css" media="orientation:portrait" />
<link rel="stylesheet" href="widescreen.css" media="(min-width: 42rem)" />Certifique-se de que os seus estilos são realmente necessários para renderizar a página. Se não estiverem, você pode adicionar um valor apropriado ao atributo media tag e desbloquear a renderização.
Tipos de mídia e consultas podem nos ajudar a acelerar a renderização da página, mas nós podemos fazer muito mais.
- Minify CSS: espaço em branco e comentários apenas nos ajudam a ler as declarações CSS. Ao remover comentários e espaços em branco da folha de estilos podemos reduzir significativamente o número de bytes de um arquivo CSS
- Combinar vários arquivos CSS: isso reduziria o número de solicitações HTTP. Esta ação é particularmente importante nas conexões móveis, onde o desempenho é afetado pela alta latência (leia-se more on latency).
- CSS críticos em linha: alguns estilos são críticos no sentido em que são necessários para renderizar o acima-o-dobra da página. Você deve sempre considerar estilos críticos inline diretamente na marcação HTML para evitar solicitações HTTP adicionais. Mas evite a formatação de grandes arquivos CSS, pois isso pode exigir viagens adicionais de ida e volta para renderizar o arquivo acima, e isso resultaria em um aviso de PageSpeed.
Você pode executar um impulso rápido e fácil em seu site diretamente no painel de controle MyKinsta. Basta usar o recurso de minificação de código que lhe é fornecido para ativar a modificação automática de CSS e Javascript com o clique de um botão.
Aceleração do Layout e Processos de Pintura
O tempo despendido pelo navegador para fazer o layout do documento depende do número de elementos DOM a serem layoutados e da complexidade desses layouts.
- Se você tiver muitos elementos DOM, o navegador pode demorar muito tempo para calcular a posição e as dimensões de todos eles: evite o layout sempre que possível.
- Prefira o novo modelo Flexbox, pois é mais rápido que o antigo Flexbox e layouts flutuantes.
- Evite layout síncrono forçado com JavaScript
O tamanho e a posição dos elementos de computação leva tempo e reduz o desempenho. Tornar o DOM o mais simples possível, e evitar o uso do JavaScript para antecipar o processo de layout ajudaria o navegador a acelerar a renderização da página (ler more on layout optimization).
Estritamente ligado ao Layout está o processo de Pintura, que é provavelmente a etapa mais demorada na sequência do Caminho de Renderização Crítica, porque sempre que você muda o layout de um elemento ou qualquer propriedade não geométrica, o navegador aciona um evento de pintura. Tornar as coisas tão simples quanto possível nesta fase pode ajudar o navegador a acelerar o processo de pintura. Por exemplo, uma propriedade de box-shadow, que requer algum tipo de cálculo, levaria mais tempo para pintar do que uma cor de borda sólida.
A otimização do processo de pintura pode não ser tão fácil, e você deve fazer uso das ferramentas de desenvolvimento do seu navegador para medir o tempo que o navegador leva para acionar cada evento de pintura. Você pode ler mais sobre este tópico no guia de desempenho do Google Rendering Performance.
Faça o desbloqueio do JavaScript
Quando o navegador encontra uma tag de script, ele tem que parar de analisar o código HTML. Os scripts em linha são executados no ponto exato em que estão no documento e bloqueiam a construção do DOM até o motor JS terminar de funcionar. Em outras palavras, o JavaScript em linha pode atrasar significativamente a renderização inicial da página. Mas o JavaScript também permite manipular as propriedades do CSS, então o navegador tem que pausar a execução do script até que ele tenha terminado de baixar e construir o CSSOM, também. Isto significa que o JavaScript é um bloqueio de parser.
No caso de arquivos JS externos, o analisador também deve esperar até que o recurso tenha sido buscado no cache ou no servidor remoto, o que pode atrasar bastante o tempo para a primeira renderização da página.
Dito isto, o que podemos fazer para minimizar o tempo gasto pelo navegador para carregar e executar o JavaScript?
- Carregar o JavaScript de forma assíncrona: o atributo boolean
asyncda tag do script instrui o navegador a executar oscriptde forma assíncrona, se possível, sem bloquear a construção do DOM. O navegador envia o pedido HTTP para o script, e continua analisando o DOM. Além disso, o script não bloqueia a construção do CSSOM, o que significa que ele não bloqueará o Caminho de Renderização Crítica (consulte os documentos MDN para obter mais informações sobre os atributos da etiqueta do script) - Deferir JavaScript: o atributo booleano
deferda tagscriptdiz ao navegador para executar o script após o documento ter sido analisado, mas antes de disparar o eventoDOMContentLoaded. Este atributo não deve ser utilizado se o atributo src estiver ausente, ou seja, scripts em linha (leia mais em Mozilla Hacks) - Adiar o JavaScript inline: muitos scripts não manipulam o DOM ou o CSSOM, por isso não há uma boa razão para que eles bloqueiem a análise. Infelizmente, não podemos usar atributos
asyncedeferpara scripts em linha, então a única maneira de carregá-los depois que o documento for carregado é movendo-os para o fundo. A vantagem é que os scripts inline não requerem solicitações HTTP adicionais. No entanto, scripts inlining usados em várias páginas resultariam em código redundante.
Regras de Otimização de Embalagem
Isso é muita coisa, não é? Vamos respirar fundo e escrever uma lista das ações de otimização descritas até agora.
- Minimize, comprima e armazene recursos HTML, CSS e JavaScript.
- Minimizar o uso de recursos de bloqueio de render (especificamente CSS)
- Use consultas de mídia em etiquetas de
link - Folhas de estilo divididas e CSS em linha crítica
- Combinar vários arquivos CSS
- Use consultas de mídia em etiquetas de
- Minimizar o uso de recursos de bloqueio de parser (JavaScript)
- Use o atributo
defernas etiquetas do script - Usar atributo
asyncnas etiquetas do script - JavaScript em linha e mover etiquetas de
scriptpara a parte inferior do documento
- Use o atributo
Agora que conhecemos os conceitos básicos da Critical Rendering Path Optimization, podemos dar uma olhada em alguns plugins de otimização populares do WordPress.
Otimizando o Caminho Crítico de Renderização no WordPress
Os usuários do WordPress podem tirar proveito de vários plugins que cobrem quase todos os aspectos do processo de otimização. Você pode instalar um plugin completo, ou pode instalar vários plugins ao mesmo tempo, cada um fornecendo recursos de otimização específicos.
Se o seu site é hospedado pela Kinsta, você não precisará de um plugin de cache porque não há necessidade de plugins de cache do WordPress na Kinsta.
W3 Total Cache
Este único plugin cobre quase todas as etapas do processo de otimização do Caminho de Renderização Crítica. À primeira vista, a configuração do plugin pode ser esmagadora, mas uma vez que você se familiarizar mais com a sequência do Critical Rendering Path, você será capaz de tirar proveito de um poderoso conjunto de ferramentas de desempenho.
Aqui está uma lista de alguns recursos de plugin:
- HTML (posts e páginas), caching CSS e JavaScript na memória, em disco ou em CDN
- Cache de feeds, resultados de pesquisa, objetos de banco de dados, objetos WordPress e fragmentos
- Minificação de HTML (posts e páginas)
- JavaScript e minificação CSS
- Optimização JavaScript com
asyncedefer - Caching de navegadores usando cache-control, cabeçalhos de expiração futura e tags de entidades
- compressão HTTP (gzip)
- Resultados do Google PageSpeed no painel de controle do WordPress
Você pode ler mais sobre todas as características, configurações e opções do plugin neste guia detalhado.
WP Super Cache
O WP Super Cache é outro plugin popular para o desempenho do site.
Ele vem com um bom número de recursos de otimização, mas é menos abrangente do que o W3 Total Cache anterior e pode parecer mais acessível para usuários iniciantes e intermediários.
Basicamente, fornece recursos de cache e compressão HTTP, mas carece de minificação de recursos e otimização JavaScript com atributos async e defer. No entanto, mais de um milhão de instalações ativas provam que o plugin vale a pena tentar.
Autoptimize
Com mais de 1.000.000 instalações ativas, o Autoptimize é um dos plugins gratuitos mais populares para minificação.
Ele vem com uma página de opções dividida em várias seções onde o administrador do site pode configurar separadamente a minificação HTML, CSS e JavaScript.
Você também pode agregar scripts ou folhas de estilo independentes e definir exceções para recursos específicos. Além disso, o Autoptimize permite o cache de recursos minificados em disco ou em CDN e salvar ativos otimizados como arquivos estáticos. Para encontrar as melhores configurações para o seu site WordPress, você pode seguir nosso guia detalhado do Autoptimize bem aqui.
Outros plugins de otimização que você pode querer tentar:
Swift Performance
O Swift Performance é outro plugin que você pode querer verificar. Este é um plugin premium que pode ajudar a aumentar as suas pontuações de desempenho e foi desenvolvido especificamente para o ajudar a tentar alcançar aquelas 100/100 pontuações do Google PageSpeed Insights.
Algumas das suas principais características incluem:
- Você não só pode minificar e combinar arquivos CSS e javascript, mas também pode criar CSS críticos na hora para as suas páginas.
- Caching inteligente, assim como AJAX e solicitações dinâmicas.
- Compressão de imagem sem perdas incorporada.
- Suporte CDN.
Você encontrará uma visão mais profunda nos plugins de otimização do WordPress em Como eliminar o Render-Blocking JavaScript e CSS
Conclusões
A Otimização do Caminho de Renderização Crítica é um processo de melhoria e medição que requer uma compreensão clara de cada tarefa que o navegador executa para converter o código em pixels e assim renderizar uma página na tela. Você pode saber mais sobre o Critical Rendering Path no guia de otimização do Google.
Aqui na Kinsta Blog, nós tentamos cobrir qualquer aspecto da otimização de desempenho. Aqui está uma lista de outras leituras:
- Network Latency – Comparando o impacto em seu site WordPress
- WordPress CDN – Por que você deveria estar usando um
- Como Optimizar Imagens para Web e Desempenho
- Como reduzir o TTFB para melhorar os tempos de carregamento da página do WordPress
- Um mergulho profundo na ferramenta de teste de velocidade GTmetrix
- 14 Ferramentas Grátis de Teste de Velocidade de Website para Usuários do WordPress
- 8 Plugins de Desempenho WordPress de Menor Difusão (mas Úteis)
- Como pontuar 100/100 no Google PageSpeed Insights com WordPress
Quanto tempo demora para optimizar o Caminho Crítico de Renderização dos seus sites? E quais são os aspectos do processo de otimização que você mais deve dominar? Informe-nos nos comentários abaixo.
Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.
Deixe um comentário