Render Blocking – Novo indicador de bloqueio de renderização no Chrome e WebPageTest

Graças a um novo indicador fornecido pelo Chrome em seus rastros (começando na versão 91 do navegador, com uma notável correção de bug enviada com a versão 92 hoje), o WebPageTest começou a destacar todas as solicitações de bloqueio de renderização em suas cascatas, tornando mais fácil se concentrar rapidamente nas solicitações de bloqueio que podem estar causando gargalos significativos no desempenho da sua página.

Um dos gargalos de desempenho mais comuns que os sites enfrentam são atrasos causados ​​por recursos de bloqueio de renderização: recursos na página que impedem a exibição da página até que sejam baixados, analisados ​​e (no caso do JavaScript) executados.

Aqui está a essência: certos tipos de recursos – CSS e JavaScript – são bloqueados por padrão.

No caso do CSS, o navegador não pode exibir a página até que o CSS tenha sido baixado e analisado no CSSOM.

No caso do JavaScript, o navegador não consegue nem continuar analisando HTML, deixando de exibir a página, até que o JavaScript tenha sido baixado, analisado e executado.

Em ambos os casos, os recursos de bloqueio tendem a aumentar os tempos de Iniciar renderização e Primeira pintura com conteúdo em particular (e Maior pintura com conteúdo por associação). Se o seu site tiver recursos de bloqueio de renderização, carregá-los lentamente ou fazê-los carregar de forma assíncrona resultará em uma melhoria de desempenho considerável.

Pode ser um pouco complicado identificar recursos de bloqueio de renderização rapidamente, mas é aí que o novo indicador de status de Bloqueio de renderização do Chrome entra em ação.

A sinalização renderBlocking

A partir da versão 91 do Chrome, o Chrome agora marca todas as solicitações relevantes com um sinalizador renderBlocking, indicando se esse recurso está bloqueando ou não. Ter essas informações fornecidas pelo navegador é um grande passo. Houve algumas tentativas de ferramentas para identificar recursos de bloqueio de renderização usando as próprias heurísticas, mas obter essas informações diretamente do navegador fornece um nível mais alto de precisão, bem como mais granularidade.

A bandeira tem cinco valores potenciais diferentes:

• blocking
• non_blocking
• dynamically_injected_non_blocking
• in_body_parser_blocking
• potentially_blocking

O status blocking

Este é bem direto – se a solicitação bloquear a exibição da página, o status de bloqueio será relatado como “blocking”. Este rótulo é aplicado a coisas como folhas de estilo e elementos de script que não têm um defer, async ou atributo de módulo.

O status de non_blocking

Este também é bastante direto. Se a solicitação não impedir que o navegador exiba a página, o status de bloqueio é relatado como “non_blocking”. Este rótulo se aplica a coisas como folhas de estilo com um atributo desativado ou folhas de estilo com consultas de mídia que não correspondem ao ambiente atual (como impressão). Também se aplica a scripts que possuem um atributo defer ou módulo.

O status dynamically_injected_non_blocking

Isso pode ser mais ou menos considerado o mesmo que non_blocking, pelo menos do ponto de vista do impacto no desempenho. Esse status é aplicado a um recurso que é injetado dinamicamente na página e não bloqueia a exibição da página.

Este status atualmente não é aplicado a scripts injetados dinamicamente, mas esse é um bug relativamente menor – “dynamically_injected_non_blocking” é apenas uma versão mais específica de “non_blocking”, então, embora seja bom limpar isso no futuro, é um problema na maioria das vezes insignificante.

O status in_body_parser_blocking

O status “in_body_parser_blocking” é definido sempre que o recurso é solicitado em algum lugar dentro do corpo de uma forma que bloqueia o analisador de analisar o documento abaixo do elemento.

Então, por exemplo, digamos que você tenha um elemento de script dentro do corpo da página em vez do cabeçalho. Isso impede que o navegador analise qualquer coisa abaixo desse elemento até que o recurso seja solicitado e baixado, para que esse status seja aplicado.

O status potencially_blocking

Este é muito interessante. Se o Chrome não puder dizer com certeza se a solicitação bloqueará ou não a exibição da página, o status “potencially_blocking” será aplicado.

Um bom exemplo aqui é um script async. Se um script for carregado com um atributo async, o navegador executará o script assim que chegar. Isso significa que se o script chega rapidamente, antes da renderização inicial da página, o script bloqueia a renderização até que toda a execução seja concluída. Se o script chegar após a renderização inicial da página, ele não bloqueia. Como a natureza do bloqueio depende de quando o script chega, o Chrome não pode dizer no momento da solicitação se ele estará bloqueando ou não, então ele o sinaliza como “potencially_blocking”.

Como encontrar o status de bloqueio de renderização no WebPageTest

Quando você clica em uma solicitação em uma cascata para visualizar os detalhes completos da solicitação, exibimos o status de bloqueio de renderização sempre que aplicável na caixa de diálogo que aparece.

Ele ficou escondido à vista de todos há um tempo, mas quando estávamos testando o indicador no Chrome v91, identificamos um bug em que scripts async injetados dinamicamente eram sinalizados incorretamente como bloqueadores. Yoav da equipe do Chrome começou a trabalhar nisso rapidamente, obtendo a correção para a versão 92.

Ainda há mais um bug que identificamos que não será corrigido até a versão 93 (as solicitações de pré carregamento são sinalizadas como não bloqueadoras, mesmo se forem para um recurso de bloqueio), mas a sinalização é estável o suficiente para que possamos torná-la uma um pouco mais proeminente agora.

Com o indicador se tornando um pouco mais estável, também o tornamos um pouco mais proeminente. A partir de hoje, os recursos com status de “blocking” serão chamados com um ícone, facilitando a identificação de qualquer recurso de bloqueio de renderização.

No momento, não estamos mostrando nada se um recurso for sinalizado com “potencially_blocking” ou “in_body_parser_blocking”, mas se isso for algo que você consideraria útil, somos todos ouvidos. Por exemplo, uma coisa que estamos considerando é sinalizar todos os recursos “potencially_blocking” que chegam antes de ocorrer o início da renderização. Eles não são exatamente o mesmo que recursos “render_blocking”, pois nem sempre podem bloquear a renderização em todos os testes, mas o fato de que eles às vezes aparecem para desacelerar as coisas pode ser uma informação útil.

Referencia: https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/