Otimizando Web Vitals usando o Lighthouse
Encontrando oportunidades para melhorar a experiência do usuário com as ferramentas da web do Chrome.
Hoje, abordaremos novos recursos de ferramentas no Lighthouse, PageSpeed e DevTools para ajudar a identificar como seu site pode melhorar no Web Vitals .
Para relembrar as ferramentas, o Lighthouse é uma ferramenta automatizada de código aberto para melhorar a qualidade das páginas da web. Você pode encontrá-lo no pacote Chrome DevTools de ferramentas de depuração e executá-lo em qualquer página da web, pública ou que exija autenticação. Você também pode encontrar o Lighthouse em PageSpeed Insights , CI e WebPageTest .
O Lighthouse 7.x inclui novos recursos, como capturas de tela do elemento, para facilitar a inspeção visual de partes de sua IU que afetam as métricas de experiência do usuário (por exemplo, quais nós estão contribuindo para a mudança de layout).
Também fornecemos suporte para capturas de tela de elemento no PageSpeed Insights, permitindo uma maneira de identificar problemas com mais facilidade para execuções únicas de desempenho de páginas.
Medição das Core Web Vitals #
O Lighthouse pode medir sinteticamente as métricas do Core Web Vitals, incluindo Largest Contentful Paint (LCP), ou Maior Renderização de Conteúdo, Cumulative Layout Shift (CLS), ou Mudança Cumulativa de Layout e Total Blocking Time (TBT), ou Tempo Total de Bloqueio (um proxy de laboratório para o First Input Delay (FID), ou Atraso da Primeira Entrada ). Essas métricas refletem o carregamento, a estabilidade do layout e a prontidão da interação. Outras métricas, como o First Contentful Paint (FCP), ou Primeira Renderização de Conteúdo destacado no futuro do Core Web Vitals (CWV), também estão lá.
A seção "Métricas" do relatório Lighthouse inclui versões de laboratório dessas métricas. Você pode usar isso como uma visão resumida de quais aspectos da experiência do usuário requerem sua atenção.
As métricas de campo , como as encontradas no Chrome UX Report ou RUM , não têm essa limitação e são um complemento valioso para os dados de laboratório, pois refletem a experiência dos usuários reais. Os dados de campo não podem oferecer os tipos de informações de diagnóstico que você obtém no laboratório, então os dois andam de mãos dadas.
Identifique onde você pode melhorar no Web Vitals #
Identifique o elemento Largest Contentful Paint #
LCP é uma medida da experiência de carregamento percebida. Ele marca o ponto durante o carregamento da página quando o conteúdo principal - ou "maior" - foi carregado e está visível para o usuário.
O Lighthouse tem uma auditoria de "elemento Largest Contentful Paint" que identifica qual elemento tinha a maior renderização de conteúdo. Passe o mouse sobre o elemento para destacá-lo na janela principal do navegador.
Se este elemento for uma imagem, esta informação é uma dica útil de que você pode querer otimizar o carregamento desta imagem. O Lighthouse inclui várias auditorias de otimização de imagem para ajudá-lo a entender se suas imagens poderiam ser melhor compactadas, redimensionadas ou entregues em um formato de imagem moderno mais ideal.
Você também pode achar LCP Bookmarklet de Annie Sullivan útil para identificar rapidamente o elemento LCP com um retângulo vermelho com apenas um clique.
Pré-carregar imagens descobertas recentemente para melhorar o LCP #
Para melhorar o LCP, pré-carregue suas imagens críticas de herói se elas estão sendo descobertas tardiamente pelo navegador. Uma descoberta tardia pode acontecer se um pacote JavaScript precisar ser carregado antes que a imagem seja detectável.
O Lighthouse 6.5 e superior agora sugere oportunidades para aplicar essa otimização.
Existem algumas perguntas comuns que nos fazem sobre o pré-carregamento de imagens LCP que também podem valer a pena abordar brevemente.
Você pode pré-carregar imagens responsivas? Sim. Digamos que temos uma imagem de herói responsiva conforme especificado usando srcset e sizes abaixo:
<img src="lighthouse.jpg"
srcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">Graças aos atributos imagesrcset e imagesizes adicionados ao atributo link, podemos pré-carregar uma imagem responsiva usando a mesma lógica de seleção de imagem usada por srcset e sizes:
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">A auditoria também destacará as oportunidades de pré-carregamento se a imagem LCP for definida por meio de um plano de fundo CSS? Sim.
Qualquer imagem sinalizada como a imagem LCP, seja por meio de CSS de fundo ou <img> é uma candidata se for descoberta na fase três ou superior no modelo de cascata.
Identifique as contribuições do CLS #
Cumulative Layout Shift (CLS) é uma medida de estabilidade visual. Ela quantifica quanto o conteúdo de uma página muda visualmente. O Lighthouse tem uma auditoria para depurar CLS chamada "Evite grandes mudanças de layout".
Esta auditoria destaca os elementos DOM que mais contribuem para as mudanças da página. Na coluna Elemento à esquerda, você verá a lista desses elementos DOM e, à direita, sua contribuição geral para o CLS.
Graças ao novo recurso de Capturas de tela de Elementos do Lighthouse, podemos ter uma pré-visualização dos principais elementos observados na auditoria, bem como clicar para ampliar para uma visão mais clara:
Para o CLS pós-carregamento, pode haver valor em visualizar persistentemente, com retângulos, quais elementos contribuíram mais para o CLS. Este é um recurso que você encontrará em ferramentas de terceiros, como o Core Web Vitals dashboard da SpeedCurve e o que eu adoro usar: Defaced's Layout Shift GIF Generator
Para uma visão de todos os problemas de mudança de layout do site, aproveito bastante o Search Console's Core Web Vitals report. Isso me permite ver os tipos de páginas em meu site com um alto CLS (neste caso, ajudando-me a identificar em quais modelos parciais preciso gastar meu tempo):
Identificar CLS a partir de imagens sem dimensões #
Para limitar o Cumulative Layout Shift causado por imagens sem dimensões, inclua os atributos de largura e altura em suas imagens e elementos de vídeo. Essa abordagem garante que o navegador possa alocar a quantidade correta de espaço no documento enquanto a imagem está sendo carregada.
Consulte Definir a altura e a largura nas imagens é importante novamente para um bom artigo sobre a importância de se pensar nas dimensões e proporção da imagem.
Identificar CLS de anúncios #
O Publisher Ads for Lighthouse permite que você encontre oportunidades para melhorar a experiência de carregamento de anúncios em sua página, incluindo contribuições para mudança de layout e tarefas longas que podem atrasar o uso de sua página pelos usuários. No Lighthouse, você pode habilitar isso por meio dos Plug-ins da Comunidade.
Lembre-se de que os anúncios são um dos maiores contribuintes para as mudanças de layout na web. É importante:
- Tomar cuidado ao posicionar anúncios não fixos próximos à parte superior da janela de visualização
- Eliminar as mudanças reservando o maior tamanho possível para o local do anúncio
Evite animações não compostas #
As animações que não são compostas podem se apresentar com baixa qualidade em dispositivos de baixo custo se tarefas pesadas de JavaScript estão mantendo o thread principal ocupado. Essas animações podem introduzir mudanças de layout.
Se o Chrome descobrir que uma animação não pode ser composta, ele a reporta a uma leitura do Lighthouse DevTools, permitindo listar quais elementos com animações não foram compostos e por qual motivo. Você pode encontrá-los na auditoria Evitar animações não compostas.
Depurar First Input Delay / Total Blocking Time / Tarefas longas #
A Primeira entrada mede o tempo desde quando um usuário interage pela primeira vez com uma página (por exemplo, quando ele clica em um link, toca em um botão ou usa um controle personalizado baseado em JavaScript) até o momento em que o navegador é realmente capaz de começar a processar os manipuladores de evento em resposta a essa interação. Tarefas JavaScript longas podem impactar esta métrica e o proxy para esta métrica, Total Blocking Time.
O Lighthouse inclui uma auditoria para Evitar tarefas longas do thread principal, que lista as tarefas mais longas do thread principal. Isso pode ser útil para identificar os piores contribuintes para o atraso de entrada. Na coluna da esquerda, podemos ver a URL dos scripts responsáveis por longas tarefas do thread principal.
À direita podemos ver a duração dessas tarefas. Como um lembrete, Tarefas Longas são tarefas executadas por mais de 50 milissegundos. Isso é considerado para bloquear o thread principal por tempo suficiente para impactar a taxa de quadros ou latência de entrada.
Se estiver considerando serviços de terceiros para monitoramento, também gosto bastante do visual da linha do tempo de execução do thread principal que o Caliber tem para visualizar esses custos, que destaca as tarefas pai e filho contribuindo para tarefas longas que afetam a interatividade.
Bloqueie solicitações de rede para ver o impacto antes/depois no Lighthouse #
O Chrome DevTools suporta o bloqueio de solicitações de rede para ver o impacto de recursos individuais sendo removidos ou indisponíveis. Isso pode ser útil para entender o custo de scripts individuais (por exemplo, como incorporadores ou rastreadores de terceiros) em métricas como Total Blocking Time (TBT) e Time to Interactive.
O bloqueio de solicitação de rede também funciona com o Lighthouse! Vamos dar uma olhada rápida no relatório do Lighthouse para um site. A pontuação de desempenho é de 63/100 com um TBT de 400 ms. Explorando o código, descobrimos que este site carrega um Intersection Observer polyfill no Chrome que não é necessário. Vamos bloquear!
Podemos clicar com o botão direito em um script no painel DevTools Network e clicar em Block Request URL para bloqueá-lo. Aqui, faremos isso para o Intersection Observer polyfill.
Em seguida, podemos executar o Lighthouse novamente. Desta vez, podemos ver que nossa pontuação de desempenho melhorou (70/100), assim como o Total Blocking Time (400ms => 300ms).
Substitua as dispendiosas incorporações de terceiros por uma fachada #
É comum usar recursos de terceiros para incorporar vídeos, postagens de mídia social ou widgets em páginas. Por padrão, a maioria das incorporações carrega rapidamente e pode vir com cargas caras que impactam negativamente a experiência do usuário. Isso é um desperdício se o terceiro não for crítico (por exemplo, se o usuário precisar rolar antes de vê-lo).
Um padrão para melhorar o desempenho de tais widgets é carregá-los lentamente na interação do usuário. Isso pode ser feito renderizando uma visualização leve do widget (uma fachada) e apenas carregar a versão completa se um usuário interagir com ela. O Lighthouse tem uma auditoria que recomendará recursos de terceiros que podem ser carregados lentamente com uma fachada, como incorporações de vídeo do YouTube.
Como um lembrete, o Lighthouse destacará o código de terceiros que bloqueia o thread principal por mais de 250ms. Isso pode revelar todos os tipos de scripts de terceiros (incluindo aqueles criados pelo Google) que podem valer a pena adiar ou carregar lentamente se o que eles renderizam exigir rolagem para visualizá-lo.
Além do Core Web Vitals #
Além de destacar o Core Web Vitals, as versões recentes do Lighthouse e do PageSpeed Insights também tentam fornecer uma orientação concreta que você pode seguir para melhorar a rapidez com que os aplicativos da web pesados, em JavaScript, podem ser carregados se os mapas de origem estiverem ativados.
Isso inclui uma coleção crescente de auditorias para reduzir o custo de JavaScript em sua página, bem como reduzir a dependência de polyfills e duplicatas que podem não ser necessários para a experiência do usuário.
Para obter mais informações sobre as ferramentas Core Web Vitals, fique de olho na conta do Twitter da equipe do Lighthouse e No que há de novo no DevTools .
Imagem de herói por Mercedes Mehling no Unsplash .