O Google Lighthouse tornou-se a ferramenta de facto para muitos sites medirem o seu desempenho com uma única pontuação: O Lighthouse Performance Score. Uma nova versão, o Lighthouse 6,0, está agora disponível no npm no Chrome Canary, no PageSpeed Insights e no GSC Console. Em meados de julho, o Lighthouse 6,0 será totalmente lançado para os utilizadores do Chrome 84. Agora é a hora de garantir que o seu site está pronto para a nova versão com uma auditoria de pontuação do Lighthouse 6,0.
O Lighthouse 6,0 vem com métricas novas e depreciadas, bem como uma nova fórmula de ponderação para calcular as pontuações de desempenho. Esta nova versão, juntamente com o anúncio de que o Core Web Metrics será adicionado ao algoritmo de classificação do Google na atualização da experiência do Google Page, são sinais claros que o gigante da pesquisa está a enfatizar a velocidade percebida – a velocidade a que um utilizador percebe uma página como carregada. Quanto mais rápido os utilizadores perceberem o seu site a carregar, maior a sua classificação e mais conversões irá receber.
As seis métricas do farol que você precisa para otimizar
O Google preocupa-se com a forma como os utilizadores experimentam a web. Dois sites podem terminar de carregar exatamente ao mesmo tempo, mas um pode parecer carregar mais rapidamente, com base na forma como o conteúdo é exibido na página. Enquanto ambos os sites terminavam o carregamento simultaneamente, o Google favorecerá o último, o site com um desempenho mais rápido.
As pontuações do Lighthouse 6,0 baseiam-se numa média ponderada de seis métricas de velocidade centradas no utilizador. A primeira pintura Contentful (FCP), o índice de velocidade (SI) e a maior pintura Contentful (LCP) medem a velocidade de carga percebida e detêm um peso combinado de 55% na pontuação de um site na versão 6 do Lighthouse. Outros 40% da pontuação são baseados em métricas que medem a capacidade de resposta, outro aspeto que impacta a perceção de velocidade de um utilizador. Estes incluem o Tempo Total de Bloqueio (TBT) e o Tempo para Interactivo (TTI). Os últimos 5% da pontuação são baseados numa métrica que mede a estabilidade visual, chamada de Mudança de Esquema Cumulativo (CLS).
A primeira pintura significativa (FMP) e a primeira ociosa da CPU (FCI) da pontuação do farol 5,7 foram substituídas por melhores métricas para medir a velocidade de uma perspetiva centrada no utilizador. Estes são os maiores Contentful Paint (LCP) e Total Blocking Time (TBT) no farol 6,0.
| Farol 5,7 | Peso | Farol 6,0 | Peso |
|---|---|---|---|
| Primeira pintura Contentful (FCP) | 20% | Primeira pintura Contentful (FCP) | 15% |
| Índice de velocidade (SI) | 27% | Índice de velocidade (SI) | 15% |
| Primeira pintura significativa (FMP) | 7% | Pintura com maior conteúdo (LCP) | 25% |
| Primeira CPU ociosa (FCI) | 13% | Tempo total de bloqueio (TBT) | 25% |
| Tempo para Interactivo (TTI) | 33% | Tempo para Interactivo (TTI) | 15% |
| - | - | Mudança de esquema cumulativa (CLS) | 5% |
Aqui estão as métricas de seis velocidades em que se concentrar enquanto auditam o seu website em preparação para o Lighthouse 6,0. As métricas são definidas na ordem em que são medidas à medida que a página é carregada.
Uma lista de verificação simplificada que cobre as velocidades que você deve ter como objetivo fornecer e técnicas de otimização por métrica são disponibilizadas na parte inferior deste artigo.
Primeira pintura Contentful
O FCP marca o primeiro ponto em que um utilizador pode ver qualquer conteúdo de página no ecrã. Este conteúdo inclui texto, imagens, gráficos ou ficheiros SVG. O FCP tinha um peso de 20% no farol 5,7 mas apenas tinha 15% de peso sobre a pontuação do farol 6,0.
Na tira de filme acima, o FCP para o carregamento da primeira página é medido em 0,6 segundos. É quando o conteúdo aparece pela primeira vez na página inicial do TheTieBar.com, mas você notará que não é quando todo o conteúdo está visível. Esta é uma distinção importante entre a primeira e a maior pintura contenciosa. O LCP é medido a 0,9 segundos quando o conteúdo acima da dobra é exibido.
À medida que você passar pela auditoria de pontuação do Lighthouse 6,0, verifique se as páginas têm uma média de FCPs de 2 segundos ou menos, pois esse é o limite da métrica para o percentil 75 e é considerado rápido pelo Google. As FCPs entre 2 e 4 segundos são consideradas velocidades moderadas, e as FCPs superiores a 4 segundos caem abaixo do percentil 50 e são classificadas como lentas.
Se você achar que os FCPs carregam muito devagar, pode ser devido a um ou mais dos seguintes:
- Demasiados recursos de bloqueio de renderização
- Grandes arquivos CSS
- Falta de conexões seguras com origens de terceiros
- Longos tempos de resposta do servidor
- Redirecionamentos de várias páginas
- Recursos estáticos não armazenados em cache
- Tamanho excessivo do DOM
Para otimizar o FCP, considere o seguinte:
- Recursos críticos inline, adie recursos não críticos e remova qualquer coisa não utilizada para reduzir o impactos de URLs de bloqueio de renderização.
- Remova todos os carateres desnecessários do CSS para diminuir o tamanho dos arquivos.
- Use o pré-conexão para estabelecer conexões precoces com origens importantes de terceiros.
- Reduza os tempos de resposta do servidor otimizando a lógica da aplicação do servidor ou atualizando o hardware do servidor para ter mais memória.
- Evite mais do que um redirecionamento de 1 páginas.
- Use o armazenamento em cache de HTTP para armazenar em cache recursos estáticos.
- Têm menos de 1 500 nós no total, uma profundidade de menos de 32 nós, e um nó pai com menos de 60 nós filhos para diminuir o tamanho do DOM.
Índice de velocidade
Si mede a progressão visual de um carregamento de página e calcula uma pontuação geral para a rapidez com que o conteúdo é pintado. No farol 5,7, o SI tinha 27% de peso sobre o índice de desempenho de um site. No farol 6,0, isto é semi-diminuído, influenciando 15% do índice de desempenho de uma página. O Google ainda vê isso como uma métrica percetiva chave, já que uma página com uma exibição lenta de imagem pode ser percebida como fajosa.
O Lighthouse mede o SI capturando uma tira de filme de uma página à medida que carrega no navegador e analisando a progressão visual quadro-a-quadro. O tempo médio em que partes visíveis da página são exibidas determina o SI. Esta métrica será diferente com base no tamanho do ecrã do dispositivo.
À medida que você passar pela sua auditoria de pontuação do Lighthouse 6,0, aponte para o SIS em 4.3s ou menos. Esta velocidade está no percentil 75 e é considerada rápida pelo Google. As páginas com Sis entre 4,3 e 5,8 segundos são moderadas, e o Sis mais lento que 5,8 segundos caem abaixo do percentil 50 e são consideradas lentas.
Os tempos de SI mais lentos tendem a ter origem nos seguintes:
- Os tempos de carga na linha principal excedem 4 segundos
- O tempo de execução do JavaScript excede os 3,5 segundos
- Grandes arquivos de fonte causam um flash de texto invisível (FOIT).
Para reduzir os tempos do SI, considere o seguinte:
- Implementar a divisão de código, remover código não utilizado e comprimir código para reduzir a carga no encadeamento principal e o tempo de execução do JavaScript.
- Certifique-se de que o texto permanece visível durante o carregamento do Webfont para evitar o FOIT.
A maior pintura Contentful
O LCP é uma nova métrica adicionada ao farol 6,0 e recebe 25% de peso na Pontuação de Desempenho de um local. O LCP substitui a primeira pintura significativa (FMP) do farol 5,7. Embora ambas as métricas meçam o tempo em que o maior elemento de conteúdo é exibido, o FMP é conhecido por produzir resultados inconsistentes e só pode ser padronizado em certos navegadores da web.
O LCP mede quando o maior elemento de conteúdo está totalmente visível no ecrã. Os elementos de conteúdo medidos incluem elementos de nível de bloco, imagens (incluindo imagens dentro de arquivos SVG) e vídeos. Esta é uma métrica extremamente importante para sites de comércio eletrônico, pois marca o ponto no tempo em que a maioria dos usuários percebe a página como totalmente carregada e é mais provável fazer uma compra.
No exemplo acima, o LCP é de 0,9 segundos, quando a imagem principal está totalmente pintada. Esta métrica capta um momento distinto quando um utilizador percebe uma página totalmente carregada, mas o conteúdo pode ainda estar a ser carregado abaixo da dobra.
Sites de alto desempenho, como os do Layer0 (agora Edgio), entregam LCPs em menos de 1 segundo. Os LCPs até 2,5 segundos são considerados rápidos e classificam-se no percentil 75 para esta métrica. Os LCPs entre 2,5 segundos e 4 segundos são considerados moderados, necessitando de melhorias, e os LCPs superiores a 4 segundos caem abaixo do percentil 50 e são considerados lentos pelo Google.
LCPs lentos geralmente resultam de um ou mais dos seguintes:
- Tempos de resposta lentos do servidor
- JavaScript e CSS bloqueadores de renderização
- Longos tempos de carregamento de recursos
- Problemas de renderização do lado do cliente
Se você encontrar mais lento do que os LCPs desejados durante a sua auditoria de pontuação do Lighthouse 6,0, considere o seguinte:
- Otimizar os tempos de resposta do servidor encaminhando o tráfego para a CDN mais próxima disponível, armazenando ativos em cache, servindo primeiro o cache de páginas HTML e estabelecendo conexões de terceiros.
- Reduza o CSS removendo CSS desnecessário, adiando CSS não crítico e CSS crítico em linha. Reduza o tempo de bloqueio de JavaScript comprimindo ficheiros JavaScript.
- Para reduzir os tempos de carregamento de recursos, otimizar e comprimir ficheiros de imagem e texto, e pré-carregar recursos importantes.
- Optimizar a renderização do lado do cliente usando a renderização do lado do servidor e a pré-renderização.
Tempo total de bloqueio
O TBT substitui o FCI do farol 5,7, que costumava suportar 13% de peso. No farol 6,0, o TBT mede a capacidade de resposta da página e representa 25% de uma Pontuação de Desempenho. O TBT mede a gravidade de como uma página não interativa é antes de se tornar interativa de forma confiável.
Vocês conhecem estes casos dolorosos: Vocês estão à espera que uma página seja carregada e, finalmente, ela parece pronta. Toca no produto que queres ver, mas nada acontece. Toca novamente? Este período de espera é conhecido por literalmente causar stress nos consumidores. Essencialmente, TBT é o período de tempo que um consumidor sente esse stress devido à não interatividade de uma página.
Fonte: web.dev
Esta métrica é medida calculando a soma total de tempo bloqueado (tarefas que demoram mais de 50 ms) entre o primeiro elemento de conteúdo exibido (FCP) e quando um usuário pode interagir totalmente com a página (TTI). Por exemplo, na imagem acima, há cinco tarefas a decorrer no tópico principal, mas apenas três delas excedem 50ms. O primeiro por 200ms, o segundo por 40ms, e o terceiro por 105 ms. O TBT é de (200 a 40 a 105) 345 ms.
Uma tarefa que demore mais de 50 ms será suficientemente longa para um utilizador notar e perceber a página como lenta, ou pior, inactiva, e levá-la a sair. Para evitar isso, procure que um TBT abaixo de 300 ms seja considerado rápido. Os TBT entre 300 ms e 600 ms são considerados velocidades moderadas e precisam de melhorias. Os TBT mais lentos do que 600 ms caem abaixo do percentil 50 e são considerados lentos.
Tarefas longas são normalmente causadas por um ou mais dos seguintes:
- Código de terceiros que bloqueia a linha principal durante 250 ms ou mais
- O tempo de execução do JavaScript leva mais de 3,5 segundos
- A linha principal está ocupada durante mais de 4 segundos durante a carga
- Um grande volume de pedidos de rede e grandes tamanhos de transferência
Para melhorar esta métrica, considere o seguinte:
- Carregar com eficiência JavaScript de terceiros usando atributos assíncronos ou adiadores em etiquetas de script, estabelecer conexões iniciais com origens importantes de terceiros e usar o lazy-loading.
- Para acelerar a execução do JavaScript e reduzir a carga no encadeamento principal, implementar a divisão de código, remover código não utilizado e comprimir código.
- Otimizar o CSS e o JavaScript para reduzir a contagem de recursos e o tamanho da transferência.
Tempo para Interactivo
O TTI é a terceira métrica transportada do farol 5,7, mas o Google diminuiu o seu peso de 33% para 15% no farol 6,0. O TTI é uma métrica complementar do TBT, medindo quanto tempo uma página leva para se tornar confiável ou totalmente interativa. O Lighthouse considera uma página interativa de forma confiável quando o primeiro elemento de conteúdo é exibido, seus scripts iniciais (se houver) foram carregados, e pode responder à entrada do usuário dentro de 50ms.
Para um utilizador, os TTIs lentos podem sentir que uma página está inactiva ou quebrada. Embora uma página pareça interativa, não é porque o tópico principal está bloqueado (medido pelo TBT). Ao auditar o seu site para o Lighthouse 6,0, procure TTIs em 5,2 segundos ou menos para ser considerado rápido. As TTI entre 5,2 e 7,3 segundos são consideradas velocidades moderadas, e as TTI mais lentas do que 7,3 segundos são consideradas lentas e terão impactos na vontade dos consumidores de se manterem no local.
Se a sua auditoria de pontuação do Lighthouse 6,0 mostrar velocidades de TTI fracas, pode ser devido a uma ou mais das seguintes:
- Grandes tamanhos de carga útil e tempo de análise de script longo
- Longos tempos de carregamento de recursos
- O código de terceiros bloqueia a linha principal durante 250 ms ou mais
- Cadeias críticas de pedidos
- Velocidade lenta do encadeamento principal e tempo de execução do JavaScript
- Altas contagens de recursos ou grandes tamanhos de transferência
Reduzir o tempo de TTI pode ser feito através da otimização do seu JavaScript. Isto inclui:
- Reduza e comprima arquivos JavaScript para reduzir o tamanho da carga útil e o tempo de análise do script.
- Pedidos de pré-carga e/ou adição de pré-ligação para tempos de carregamento mais rápidos.
- Carregar com eficiência o JavaScript de terceiros usando atributos assíncronos ou adiadores em etiquetas de script e usando o lazy-loading.
- Reduzir o efeito das cadeias críticas de pedidos no desempenho, reduzindo o número de recursos críticos e otimizando a ordem em que os recursos restantes são carregados.
- Implementar a divisão de código, remover código não utilizado e comprimir código para reduzir a carga no encadeamento principal e o tempo de execução do JavaScript.
- Otimizar o CSS e o JavaScript para reduzir a contagem de recursos e o tamanho da transferência.
Mudança de esquema cumulativa
CLS é a terceira nova métrica introduzida no farol 6,0, e é a única que não substitui nenhuma métrica do farol 5,7. O CLS representa os últimos 5% da pontuação do 6,0 no farol e mede a estabilidade visual.
Esta métrica mede a frequência com que os utilizadores experimentam mudanças inesperadas de esquema. Você já experimentou isso antes: Você está prestes a tocar em um produto, e bam, de repente, você toca em outra coisa na página porque os elementos mudaram. Estas experiências podem ser bastante irritantes e vistas como faias para um utilizador.
O CLS é medido pela soma total de todas as pontuações de deslocamento de layout individuais para cada turno inesperado que ocorre durante toda a vida útil da página. Um bom CLS é inferior a 0,1 e está no percentil 75 para o desempenho. Um CLS entre 0,1 e 0,25 é considerado moderado, e qualquer medida maior que 0,25 cai abaixo do percentil 50 e é considerado lento pelo Google.
Se você encontrar um CLS pobre durante a sua auditoria de pontuação do Lighthouse 6,0, provavelmente é devido a um dos seguintes:
- Uma imagem ou vídeo redimensionando-se
- Uma fonte que carrega tarde e é exibida maior ou menor do que o pretendido
Para melhorar esta métrica, considere o seguinte:
- Inclua dimensões exatas nas suas imagens e elementos de vídeo
- Evite anúncios pop-up ou banners
- Evite fontes que causam FOIT/FOUT
As pontuações do farol mostram o que o Google pensa do seu site
A Pontuação de Desempenho do Farol de uma página indica como o Google percebe a página em termos de velocidade. Cada métrica no Lighthouse 6,0 reflete a melhor tentativa do Google de medir como os utilizadores percebem a velocidade. Se uma pontuação ficar abaixo dos padrões, ela será percebida como lenta, não apenas pelos usuários, mas pelo próprio gigante da pesquisa, resultando em impactos negativos na receita e no SEO.
O Google classifica os sites cada vez mais rapidamente na página de resultados do motor de busca. Além do SEO, descobriu-se que a velocidade do site tem um impactos significativo nas conversões e nas receitas. A Amazon, por exemplo, descobriu que um atraso de 1 segundos no carregamento de páginas poderia custar à empresa uma perda de 1.6B por ano.
Na linha inferior
Esta última versão do Lighthouse demonstra a ênfase do gigante da pesquisa nas métricas de velocidade percetiva. As métricas de pontuação no Lighthouse 6,0 tentam medir a rapidez com que os visitantes percebem a sua página como totalmente carregada (mesmo que ainda esteja a executar processos em segundo plano).
Três métricas, o primeiro Contentful Paint, o índice de velocidade e o maior Contentful Paint, medem a velocidade de carga percebida e representaram 55% da sua Pontuação de desempenho. Aponte para FCPs de 2 segundos, LCPs de 2,5 e SIS de 4,3 segundos ou menos.
Outros 40% de uma Pontuação de Desempenho são baseados em métricas percetivas que medem a capacidade de resposta de uma página. Estes incluem o tempo total de bloqueio e o tempo para a Interactiva. Uma rápida auditoria de pontuação do Lighthouse 6,0 mostrará um TBT em menos de 300 ms e TTI em menos de 5,2 segundos, ou um usuário perceberá o seu site como um pouco instável.
Por fim, ninguém gosta de texto ou imagens a saltar para dentro e para fora do ecrã. A Mudança de Esquema Cumulativa é a sexta métrica a ser contabilizada na sua auditoria do Lighthouse 6,0. Aponte para as medições de CLS inferiores a 0,1, e você receberá os 5% do peso que contém na sua Pontuação de Desempenho.
Para receber uma lista de verificação simples que abranja as velocidades que deve ter como objetivo realizar na sua auditoria de Pontuação do Lighthouse 6,0, juntamente com técnicas de otimização por métrica, por favor preencha o formulário abaixo.
