O desempenho de renderização de sua página da web atende aos padrões atuais? A renderização é o processo de traduzir a resposta de um servidor na imagem que o navegador “pinta” quando um usuário visita um site. Um desempenho de renderização ruim pode se traduzir em uma taxa de rejeição relativamente alta.
Existem diferentes respostas do servidor que determinam se uma página é renderizada ou não. Neste artigo, vamos nos concentrar na renderização inicial da página da Web, que começa com a análise de HTML (desde que o navegador tenha recebido HTML como resposta do servidor). Vamos explorar as coisas que podem levar a tempos de renderização altos e como corrigi-los.
Caminho de renderização crítico
O caminho crítico de renderização (CRP) é o processo pelo qual seu navegador passa para converter o código em pixels exibíveis na tela. Tem várias etapas, algumas das quais podem ser executadas em paralelo para economizar tempo, mas algumas partes precisam ser feitas de forma consequente. Aqui é visualizado:
Em primeiro lugar, uma vez que o navegador obtém a resposta, ele começa a analisá-la. Quando encontra uma dependência, tenta baixá-la.
Se for um arquivo de folha de estilo, o navegador terá que analisá-lo completamente antes de renderizar a página, e é por isso que o CSS é chamado de bloqueio de renderização .
Se for um script, o navegador precisa: parar de analisar, baixar o script e executá-lo. Só depois disso ele pode continuar analisando, porque os programas JavaScript podem alterar o conteúdo de uma página da web (HTML, em particular). E é por isso que JS é chamado de bloqueio do analisador .
Uma vez que toda a análise é feita, o navegador tem o Document Object Model (DOM) e o Cascading Style Sheets Object Model (CSSOM) construídos. Combiná-los dá a Árvore de Renderização. As partes não exibidas da página não entram na Árvore de Renderização, pois ela contém apenas os dados necessários para desenhar a página.
O penúltimo passo é traduzir a Árvore de Renderização para o Layout. Essa etapa também é chamada de Reflow. É aí que cada posição de cada nó da Árvore de Renderização, bem como seu tamanho, são calculados.
Por fim, o último passo é o Paint. Envolve literalmente colorir os pixels de acordo com os dados que o navegador calculou durante os estágios anteriores.
Conclusões relacionadas à otimização
Como você pode imaginar, o processo de otimização de desempenho do site envolve alterações no site que reduzem:
- A quantidade de dados que devem ser transferidos
- O número de recursos que o navegador precisa baixar (especialmente os de bloqueio)
- A duração do PCR
Além disso, vamos mergulhar nos detalhes de como isso é feito, mas primeiro, há uma regra importante a ser observada.
Como medir o desempenho
Uma regra importante de otimização é: primeiro meça, otimize conforme necessário . A maioria das ferramentas de desenvolvedor dos navegadores tem uma guia chamada Performance , e é aí que as medições acontecem. Ao otimizar para a renderização inicial (primeira) mais rápida, a coisa mais importante a se observar é o tempo dos seguintes eventos:
- Primeira pintura
- Primeira pintura de conteúdo
- Primeira pintura significativa
Aqui, “Pintar” significa renderização bem-sucedida de uma página, o último estágio no caminho crítico de renderização. Algumas renderizações podem acontecer uma após a outra porque os navegadores tentam exibir algo o mais rápido possível e atualizar mais tarde.
Além do tempo de renderização, há outras coisas a serem consideradas—o mais importante, quantos recursos de bloqueio são usados e quanto tempo leva para baixá-los. Essas informações são encontradas na guia Desempenho após as medições serem feitas.
Estratégias de otimização de desempenho
Dado o que aprendemos acima, existem três estratégias principais para a otimização do desempenho do site:
- Minimizando a quantidade de dados a serem transferidos pelo fio,
- Reduzindo o número total de recursos a serem transferidos pela rede e
- Encurtando o caminho crítico de renderização
1. Minimize a quantidade de dados a serem transferidos
Antes de tudo, remova todas as partes não utilizadas, como funções inacessíveis em JavaScript, estilos com seletores que nunca correspondem a nenhum elemento e tags HTML que ficam ocultas para sempre com CSS. Em segundo lugar, remova todas as duplicatas.
Então, eu recomendo colocar um processo automático de minificação no lugar. Por exemplo, ele deve remover todos os comentários do que seu back-end está servindo (mas não o código-fonte) e todos os caracteres que não contêm informações adicionais (como caracteres de espaço em branco em JS).
Feito isso, o que nos resta pode ser como texto. Isso significa que podemos aplicar com segurança um algoritmo de compactação como o GZIP (que a maioria dos navegadores entende).
Por fim, há o cache. Não ajudará na primeira vez que um navegador renderizar a página, mas economizará muito nas visitas subsequentes. No entanto, é crucial manter duas coisas em mente:
- Se você usar um CDN, certifique-se de que o cache seja suportado e configurado corretamente.
- Em vez de esperar pela data de expiração dos recursos, você pode querer ter uma maneira de atualizá-lo mais cedo do seu lado. Incorpore as “impressões digitais” dos arquivos em seus URLs para poder invalidar o cache local.
Obviamente, as políticas de cache devem ser definidas por recurso. Alguns podem raramente mudar ou nunca mudar. Outros estão mudando mais rápido. Alguns contêm informações confidenciais, outros podem ser considerados públicos. Use a diretiva “private” para impedir que as CDNs armazenem dados privados em cache.
A otimização de imagens da Web também pode ser feita, embora as solicitações de imagem não bloqueiem a análise ou a renderização.
2. Reduzir a contagem total de recursos críticos
“Crítico” refere-se apenas aos recursos necessários para que a página da Web seja renderizada corretamente. Portanto, podemos pular todos os estilos que não estão envolvidos diretamente no processo. E todos os roteiros também.
Folhas de estilo
Para informar ao navegador que arquivos CSS específicos não são necessários, devemos definir mediaatributos para todos os links que fazem referência às folhas de estilo. Com esta abordagem, o navegador tratará apenas os recursos que correspondem ao atual media(tipo de dispositivo, tamanho da tela) conforme necessário, enquanto diminui a prioridade de todas as outras folhas de estilo (elas serão processadas de qualquer maneira, mas não como parte do caminho crítico de renderização ). Por exemplo, se você adicionar o media="print"atributo à styletag que faz referência aos estilos para imprimir a página, esses estilos não interferirão no caminho crítico de renderização quando a mídia não estiver print(ou seja, ao exibir a página em um navegador).
Para melhorar ainda mais o processo, você também pode fazer alguns dos estilos embutidos. Isso nos poupa pelo menos uma viagem de ida e volta ao servidor que, de outra forma, seria necessária para obter a folha de estilo.
Scripts
Como mencionado acima, os scripts bloqueiam o analisador porque podem alterar o DOM e o CSSOM. Portanto, os scripts que não os alteram não devem ser analisados em bloco, economizando tempo.
Para implementar isso, todas as tags de script devem ser marcadas com atributos – asyncou defer.
Scripts marcados com asyncnão bloqueiam a construção do DOM ou CSSOM, pois podem ser executados antes da construção do CSSOM. Tenha em mente, porém, que os scripts inline bloquearão o CSSOM de qualquer maneira, a menos que você os coloque acima do CSS.
Por outro lado, os scripts marcados com deferserão avaliados no final do carregamento da página. Portanto, eles não devem afetar o documento (caso contrário, acionará uma nova renderização).
Em outras palavras, com defer, o script não é executado até que o evento de carregamento da página seja acionado, enquanto asyncpermite que o script seja executado em segundo plano enquanto o documento está sendo analisado.
3. Reduza o comprimento do caminho de renderização crítico
Finalmente, o comprimento do CRP deve ser reduzido ao mínimo possível. Em parte, as abordagens descritas acima farão isso.
As consultas de mídia como atributos para as tags de estilo reduzirão a contagem total de recursos que precisam ser baixados. A tag de script atribui defere asyncimpedirá que os scripts correspondentes bloqueiem a análise.
Recursos de minificação, compactação e arquivamento com GZIP reduzirão o tamanho dos dados transferidos (reduzindo também o tempo de transferência de dados).
A inclusão de alguns estilos e scripts pode reduzir o número de viagens de ida e volta entre o navegador e o servidor.
O que ainda não discutimos é a opção de reorganizar o código entre os arquivos. De acordo com a ideia mais recente de melhor desempenho, a primeira coisa que um site deve fazer mais rápido é exibir o conteúdo ATF. ATF significa acima da dobra. Esta é a área visível imediatamente, sem rolagem. Portanto, é melhor reorganizar tudo relacionado à renderização de forma que os estilos e scripts necessários sejam carregados primeiro, com todo o resto parando – nem análise nem renderização. E lembre-se sempre de medir antes e depois de fazer a mudança.
Conclusão: a otimização abrange toda a sua pilha
Em resumo, a otimização de desempenho do site incorpora todos os aspectos da resposta do seu site, como armazenamento em cache, configuração de um CDN, refatoração, otimização de recursos e outros, porém tudo isso pode ser feito gradualmente. Como desenvolvedor da Web, você deve usar este artigo como referência e lembre-se sempre de medir o desempenho antes e depois de seus experimentos.
Os desenvolvedores de navegadores fazem o possível para otimizar o desempenho do site para cada página que você visita, e é por isso que os navegadores geralmente implementam o chamado “pré-carregador”. Esta parte dos programas verifica antes de um recurso que você solicitou em HTML para fazer várias solicitações ao mesmo tempo e executá-las em paralelo. É por isso que é melhor manter as tags de estilo próximas umas das outras em HTML (em linha), assim como as tags de script.
Além disso, tente agrupar as atualizações em HTML para evitar vários eventos de layout, que são acionados não apenas por uma alteração no DOM ou CSSOM, mas também por uma alteração na orientação do dispositivo e um redimensionamento da janela.
