Uma coleção de práticas recomendadas que a equipe do Chrome DevRel acredita serem as maneiras mais eficazes de melhorar o desempenho das Core Web Vitals em 2023.
Ao longo dos anos, o Google fez muitas recomendações aos desenvolvedores da Web sobre como melhorar o desempenho.
Cada uma dessas recomendações, individualmente, pode melhorar o desempenho de muitos sites, mas o conjunto completo de recomendações é bem difícil e, na realidade, não é possível que uma única pessoa ou site possa seguir todas elas.
A menos que o desempenho na Web seja seu trabalho diário, provavelmente não é óbvio quais recomendações terão o maior impacto positivo em seu site. Por exemplo, talvez você já tenha lido que a implementação de CSS essencial pode melhorar o desempenho de carregamento e que é importante otimizar suas imagens. Mas, se você não tem tempo para trabalhar nas duas coisas, como decidir qual escolher?
A equipe do Chrome passou o ano passado tentando responder a esta pergunta: quais são as recomendações mais importantes que podemos dar aos desenvolvedores para ajudar a melhorar o desempenho para os usuários?
Para responder adequadamente a essa pergunta, precisamos considerar não apenas os méritos técnicos de qualquer recomendação, mas também fatores humanos e organizacionais que influenciam a probabilidade de os desenvolvedores realmente adotarem essas recomendações. Em outras palavras, algumas recomendações podem ter um grande impacto na teoria, mas, na realidade, poucos sites terão o tempo ou os recursos para implementá-las. Da mesma forma, algumas recomendações são essenciais, mas a maioria dos sites já segue essas práticas.
Em resumo, queríamos que nossa lista de principais recomendações de desempenho na Web se concentrasse em:
- Recomendações que acreditamos ter o maior impacto no mundo real
- Recomendações relevantes e aplicáveis à maioria dos sites
- recomendações realistas para a maioria dos desenvolvedores implementar;
Ao longo do último ano, passamos muito tempo auditando o conjunto completo de recomendações de desempenho que fazemos e avaliando cada uma delas (qualitativa e quantitativamente) em relação aos três critérios acima.
Esta postagem descreve nossas principais recomendações para melhorar o desempenho de cada uma das Core Web Vitals. Se você ainda não conhece muito bem o desempenho na Web ou está tentando decidir qual é o melhor investimento para seu investimento, acreditamos que essas recomendações são o melhor ponto de partida.
Maior exibição de conteúdo (LCP)
Nosso primeiro conjunto de recomendações é para a Maior exibição de conteúdo (LCP), que é uma medida do desempenho do carregamento. Das três métricas Core Web Vitals, a LCP é a que o maior número de sites enfrenta. Atualmente, apenas cerca da metade de todos os sites na Web atendem ao limite recomendado. Então, vamos começar.
Verifique se o recurso de LCP pode ser encontrado na origem HTML
De acordo com o Web Almanac de 2022 da HTTP Archive, 72% das páginas de dispositivos móveis têm uma imagem como elemento da LCP. Isso significa que, para que a maioria dos sites otimize a LCP, é necessário garantir que essas imagens carreguem rapidamente.
O que pode não ser óbvio para muitos desenvolvedores é que o tempo que leva para carregar uma imagem é apenas uma parte do desafio. Outra parte importante é o tempo antes de uma imagem começar a carregar, e os dados do HTTP Archive sugerem que é realmente onde muitos sites se atrapalham.
Na verdade, das páginas em que o elemento LCP era uma imagem, 39% dessas imagens tinham URLs de origem que não eram detectáveis da origem do documento HTML. Em outras palavras, esses URLs não foram encontrados em atributos HTML padrão (como <img src="..."> ou <link rel="preload" href="...">), o que permitiria ao navegador descobri-los rapidamente e começar a carregá-los imediatamente.
Se uma página precisar esperar até que o download, a análise e o processamento dos arquivos CSS ou JavaScript sejam concluídos antes que a imagem comece a carregar, talvez já seja tarde demais.
Como regra geral, se o elemento da LCP é uma imagem, o URL dela precisa ser sempre detectável pelo código-fonte HTML. Confira algumas dicas para tornar isso possível:
Carregue a imagem usando um elemento
<img>com o atributosrcousrcset. Não use atributos não padrão, comodata-src, que exigem JavaScript para a renderização, já que isso sempre é mais lento. 9% das páginas ocultam a imagem da LCP atrás dodata-src.Dê preferência à renderização do lado do servidor (SSR, na sigla em inglês) em vez da renderização do lado do cliente (CSR, na sigla em inglês), já que a SSR implica que a marcação de página completa (incluindo a imagem) está presente no código-fonte HTML. As soluções de CSR exigem que o JavaScript seja executado antes que a imagem possa ser descoberta.
Caso sua imagem precise ser referenciada de um arquivo CSS ou JS externo, ainda é possível incluí-la na fonte HTML usando uma tag
<link rel="preload">. As imagens referenciadas por estilos in-line não são detectáveis pelo verificador de pré-carregamento do navegador. Portanto, mesmo que estejam no código-fonte HTML, a descoberta delas ainda pode ficar bloqueada no carregamento de outros recursos. Portanto, o pré-carregamento pode ajudar nesses casos.
Para ajudar você a entender se a sua imagem LCP tem problemas de detecção, o Lighthouse vai lançar uma nova auditoria na versão 10.0 (prevista para janeiro de 2023).
Garantir que o recurso da LCP possa ser descoberto no código-fonte HTML pode levar a melhorias mensuráveis, além de proporcionar novas oportunidades para priorizar o recurso, que é nossa próxima recomendação.
Garanta que o recurso de LCP seja priorizado
Garantir que o recurso de LCP possa ser descoberto no código-fonte HTML é uma primeira etapa crítica para garantir que o recurso da LCP comece a ser carregado antecipadamente, mas outro passo importante é garantir que o carregamento desse recurso seja priorizado e não fique na fila com vários outros recursos menos importantes.
Por exemplo, mesmo que a imagem LCP esteja presente no código-fonte HTML usando uma tag <img> padrão, se a página incluir uma dúzia de tags <script> no <head> do documento antes dessa tag <img>, poderá levar um tempo até que o recurso de imagem comece a carregar.
A maneira mais fácil de resolver esse problema é dar uma dica ao navegador sobre quais recursos têm maior prioridade, definindo o novo atributo fetchpriority="high" na tag <img> ou <link> que carrega sua imagem LCP. Isso instrui o navegador a carregá-lo mais cedo, em vez de aguardar a conclusão dos scripts.
De acordo com a Web Almanac, apenas 0, 03% das páginas qualificadas estão aproveitando essa nova API.Isso significa que a maioria dos sites na Web tem muitas oportunidades para melhorar a LCP com muito pouco trabalho. No momento, o atributo fetchpriority é compatível apenas com navegadores baseados no Chromium, mas essa API é um aprimoramento progressivo que outros navegadores simplesmente ignoram. Por isso, recomendamos que os desenvolvedores a usem agora.
Para navegadores que não sejam o Chromium, a única maneira de garantir que o recurso da LCP tenha prioridade é consultando-o anteriormente no documento. Usando novamente o exemplo de um site com muitas tags <script> no <head> do documento, se você quiser garantir que seu recurso de LCP seja priorizado antes desses recursos de script, adicione uma tag <link rel="preload"> antes de qualquer um desses scripts ou mova esses scripts para abaixo de <img> mais tarde no <body>. Embora funcione, ele é menos ergonômico do que usar o fetchpriority. Esperamos que outros navegadores ofereçam suporte em breve.
Outro aspecto importante da priorização do recurso de LCP é garantir que você não faça nada que cause a redução da prioridade, como adicionar o atributo loading="lazy". Atualmente, 10% das páginas definem loading="lazy" na imagem da LCP. Cuidado com as soluções de otimização de imagens que aplicam indiscriminadamente o comportamento de carregamento lento a todas as imagens. Se houver uma maneira de modificar esse comportamento, use-o para a imagem LCP. Se você não tiver certeza de qual imagem será a LCP, tente usar a heurística para escolher uma candidata razoável.
O adiamento de recursos não críticos é outra maneira de aumentar com eficiência a prioridade relativa do recurso da LCP. Por exemplo, os scripts que não estão alimentando a interface do usuário (como scripts de análise ou widgets sociais) podem ser adiados com segurança até o evento load ser disparado. Isso garante que eles não concorram com outros recursos essenciais (como o recurso de LCP) pela largura de banda da rede.
Para resumir, siga estas práticas recomendadas para garantir que o recurso de LCP seja carregado antecipadamente e com alta prioridade:
- Adicione
fetchpriority="high"à tag<img>da imagem LCP. Se o recurso de LCP for carregado por uma tag<link rel="preload">, não se preocupe, porque você também pode definirfetchpriority="high"nela. - Nunca defina
loading="lazy"na tag<img>da sua imagem LCP. Isso vai diminuir a prioridade da imagem e atrasar o carregamento dela. - Adie recursos não críticos quando possível. Mova-os para o final do documento, use o carregamento lento nativo para imagens ou iframes ou carregue-os de forma assíncrona via JavaScript.
Usar um CDN para otimizar o TTFB de documento e recurso
As duas recomendações anteriores eram voltadas para garantir que o recurso de LCP fosse descoberto cedo e priorizado para que fosse possível começar a carregar imediatamente. A peça final deste quebra-cabeça é garantir que a resposta inicial ao documento chegue o mais rápido possível.
O navegador não pode começar a carregar sub-recursos até receber o primeiro byte da resposta inicial do documento HTML. Quanto mais cedo isso acontecer, mais cedo o restante poderá começar a acontecer.
Esse tempo é conhecido como Tempo para primeiro byte (TTFB, na sigla em inglês), e a melhor maneira de reduzir o TTFB é:
- Disponibilize seu conteúdo o mais próximo possível dos usuários
- Armazene em cache esse conteúdo para que o conteúdo solicitado recentemente possa ser reexibido com rapidez.
A melhor maneira de fazer as duas coisas é usar uma CDN. As CDNs distribuem seus recursos para servidores de borda, que estão espalhados por todo o mundo, limitando a distância que esses recursos precisam percorrer para chegar aos usuários. As CDNs geralmente também têm controles de armazenamento em cache refinados que podem ser personalizados e otimizados de acordo com as necessidades do seu site.
Muitos desenvolvedores estão familiarizados com o uso de uma CDN para hospedar ativos estáticos, mas as CDNs também podem veicular e armazenar em cache documentos HTML, mesmo aqueles gerados dinamicamente.
De acordo com o Web Almanac, apenas 29% das solicitações de documentos HTML foram veiculadas a partir de uma CDN, o que significa que há uma oportunidade significativa para os sites reivindicarem uma economia adicional.
Confira algumas dicas para configurar suas CDNs:
- Considere aumentar por quanto tempo o conteúdo é armazenado em cache (por exemplo, é realmente essencial que o conteúdo esteja sempre atualizado? Ou podem ficar alguns minutos desatualizados?).
- Considere até armazenar o conteúdo em cache indefinidamente e depois limpe-o se/quando fizer uma atualização.
- Confira se é possível mover a lógica dinâmica em execução no servidor de origem para a borda, um recurso da maioria das CDNs modernas.
Em geral, sempre que você puder veicular conteúdo diretamente da borda (evitando uma viagem ao servidor de origem), isso resultará em um ganho de desempenho. E mesmo nos casos em que você precisa percorrer o caminho de volta ao servidor de origem, as CDNs geralmente são otimizadas para fazer isso de maneira muito mais rápida, o que é uma vitória de qualquer maneira.
Cumulative Layout Shift (CLS)
O próximo conjunto de recomendações é para a Mudança de layout cumulativa (CLS), que é uma medida da estabilidade visual em páginas da Web. Embora a CLS tenha melhorado muito na Web desde 2020, cerca de um quarto dos sites ainda não atinge o limite recomendado. Portanto, ainda há uma grande oportunidade para muitos sites melhorarem a experiência do usuário.
Definir tamanhos explícitos em qualquer conteúdo carregado da página
As mudanças de layout geralmente acontecem quando o conteúdo atual é movido depois que outro termina de ser carregado. Portanto, a principal maneira de minimizar isso é reservar o espaço necessário com antecedência.
A maneira mais direta de corrigir mudanças de layout causadas por imagens não dimensionadas é definir explicitamente os atributos width e height (ou propriedades CSS equivalentes). No entanto, de acordo com o HTTP Archive, 72% das páginas têm pelo menos uma imagem sem tamanho definido. Sem um tamanho explícito, os navegadores definirão inicialmente uma altura padrão de 0px e poderão causar uma mudança perceptível no layout quando a imagem for finalmente carregada e as dimensões forem descobertas. Isso representa uma grande oportunidade para a Web coletiva, e essa oportunidade requer muito menos esforço do que algumas das outras recomendações sugeridas neste artigo.
Também é importante lembrar que as imagens não são as únicas que contribuem para a CLS. As mudanças de layout podem ser causadas por outro conteúdo que normalmente é carregado depois que a página é renderizada, incluindo anúncios de terceiros ou vídeos incorporados. A propriedade aspect-ratio pode ajudar a combater isso. É um recurso CSS relativamente novo que permite aos desenvolvedores fornecer explicitamente uma proporção para imagens, bem como elementos que não são de imagem. Isso permitirá que você defina uma width dinâmica (por exemplo, com base no tamanho da tela) e que o navegador calcule automaticamente a altura adequada, da mesma forma que faz para imagens com dimensões.
Às vezes, não é possível saber o tamanho exato do conteúdo dinâmico, pois ele é, por sua natureza, dinâmico. No entanto, mesmo que você não saiba o tamanho exato, ainda é possível tomar medidas para reduzir a gravidade das mudanças de layout. Definir um min-height sensível é quase sempre melhor do que permitir que o navegador use a altura padrão de 0px para um elemento vazio. O uso de um min-height também costuma ser uma solução fácil, já que ele ainda permite que o contêiner cresça até a altura final do conteúdo, se necessário. Ele apenas reduziu esse crescimento do valor total para um nível mais tolerável.
Verifique se as páginas estão qualificadas para o bfcache
Os navegadores usam um mecanismo de navegação chamado cache de avanço e retorno, ou bfcache, para carregar instantaneamente uma página anterior ou posterior no histórico de navegação diretamente de um snapshot da memória.
O bfcache é uma otimização significativa do desempenho no navegador e elimina completamente as mudanças de layout durante o carregamento da página, que é onde ocorre a maior parte da CLS. A introdução do bfcache causou a maior melhoria na CLS que observamos em 2022.
Apesar disso, um número significativo de sites não está qualificado para o bfcache e, por isso, está perdendo essa vantagem sem custo financeiro de desempenho da Web por um número significativo de navegações. A menos que sua página esteja carregando informações sensíveis que você não quer que sejam restauradas da memória, verifique se as páginas estão qualificadas.
Os proprietários dos sites precisam verificar se as páginas estão qualificadas para o bfcache e encontrar o motivo. O Chrome já tem um testador de bfcache no DevTools e, este ano, planejamos aprimorar as ferramentas com uma nova auditoria do Lighthouse realizando um teste semelhante e uma API para medir isso em campo.
Embora tenhamos incluído o bfcache na seção de CLS, já que vimos os maiores ganhos até agora, o bfcache geralmente também melhora outras Core Web Vitals. Ele é uma das diversas navegações instantâneas disponíveis para melhorar significativamente as navegações nas páginas.
Evitar animações/transições que usam propriedades CSS de indução de layout
Outra fonte comum de mudanças de layout é quando os elementos são animados. Por exemplo, banners de cookies ou outros banners de notificação que deslizam de cima ou de baixo geralmente contribuem para a CLS. Isso é particularmente problemático quando esses banners empurram outros conteúdos para fora do caminho, mas mesmo quando não fazem isso, a animação deles ainda pode afetar a CLS.
Embora os dados do HTTP Archive não possam conectar de forma conclusiva as animações a mudanças de layout, os dados mostram que as páginas que animam qualquer propriedade CSS que poderia afetar o layout têm 15% menos chances de ter uma CLS "boa" do que as páginas em geral. Algumas propriedades estão associadas a uma CLS pior do que outras. Por exemplo, páginas com larguras de margin ou border animadas têm uma CLS "baixa" a uma taxa de quase duas vezes maior em que as páginas em geral são avaliadas como ruins.
Isso pode não ser uma surpresa, porque toda vez que você fizer a transição ou animação de qualquer propriedade CSS de indução de layout, isso resultará em mudanças de layout. Se essas mudanças não estiverem dentro dos 500 milissegundos de uma interação do usuário, elas afetarão a CLS.
O que pode surpreender alguns desenvolvedores é que isso é verdade mesmo nos casos em que o elemento é levado para fora do fluxo normal do documento. Por exemplo, elementos posicionados de forma absoluta que animam top ou left causam mudanças de layout, mesmo que não estejam movendo outros conteúdos. No entanto, se, em vez de animar top ou left, você animar transform:translateX() ou transform:translateY(), o navegador não vai atualizar o layout da página e, portanto, não produzirá nenhuma mudança de layout.
Há muito tempo, priorizar a animação de propriedades CSS que podem ser atualizadas na linha de execução do compositor do navegador é uma prática recomendada de desempenho porque move esse trabalho para a GPU e para fora da linha de execução principal. Além de ser uma prática recomendada geral de desempenho, ela também pode ajudar a melhorar a CLS.
Como regra geral, nunca anime ou faça a transição de qualquer propriedade CSS que exija que o navegador atualize o layout da página, a menos que você esteja fazendo isso em resposta a um toque do usuário ou ao pressionamento de uma tecla (não a hover). Sempre que possível, prefira transições e animações usando a propriedade CSS transform.
A auditoria do Lighthouse Evitar animações não compostas avisará quando uma página animar propriedades CSS possivelmente lentas.
First Input Delay (FID)
Nosso último conjunto de recomendações é sobre a latência na primeira entrada (FID, na sigla em inglês), que é uma medida da capacidade de resposta de uma página em relação às interações do usuário. Embora a maioria dos sites na Web atualmente tenha uma boa pontuação de FID, documentamos falhas da métrica de FID no passado, e acreditamos que ainda haja muitas oportunidades para os sites melhorarem a capacidade geral de resposta às interações do usuário.
Nossa nova métrica Interação com a próxima exibição (INP) é um possível sucessor da FID, e todas as recomendações abaixo se aplicam igualmente bem a FID e INP. Como os sites têm um desempenho pior em INP do que FID, especialmente em dispositivos móveis, recomendamos que os desenvolvedores considerem seriamente essas recomendações de capacidade de resposta, apesar de terem uma FID "boa".
Evitar ou dividir tarefas longas
As tarefas são qualquer parte do trabalho discreto realizado pelo navegador. As tarefas incluem renderização, layout, análise, compilação e execução de scripts. Quando as tarefas se tornam tarefas longas, ou seja, 50 milissegundos ou mais, elas impedem que a linha de execução principal responda rapidamente às entradas do usuário.
De acordo com o Web Almanac, há muitas evidências que sugerem que os desenvolvedores podem estar fazendo mais para evitar ou dividir tarefas longas. Embora dividir tarefas longas possa não ser tão difícil quanto outras recomendações deste artigo, é menos esforço do que as outras técnicas não oferecidas neste artigo.
Embora você deva sempre se esforçar para fazer o mínimo de trabalho possível em JavaScript, é possível ajudar bastante a linha de execução principal dividindo tarefas longas em menores. Você pode fazer isso renderizando na linha de execução principal com frequência para que as atualizações de renderização e outras interações do usuário ocorram mais rapidamente.
Outra opção é usar APIs como a isInputPending e a API Scheduler. isInputPending é uma função que retorna um valor booleano que indica se uma entrada do usuário está pendente. Se ele retornar true, você poderá ceder à linha de execução principal para que ela possa processar a entrada pendente do usuário.
A API do Scheduler é uma abordagem mais avançada, que permite programar o trabalho com base em um sistema de prioridades que levam em consideração se o trabalho que está sendo feito é visível para o usuário ou em segundo plano.
Ao dividir tarefas longas, você dá ao navegador mais oportunidades de se adequar a trabalhos essenciais visíveis ao usuário, como lidar com interações e quaisquer atualizações de renderização resultantes.
Evitar JavaScript desnecessário
Sem dúvida: os sites estão incluindo mais JavaScript do que nunca, e a tendência não parece que vai mudar tão cedo. Quando você envia muito JavaScript, está criando um ambiente em que as tarefas competem pela atenção da linha de execução principal. Isso pode definitivamente afetar a capacidade de resposta do seu site, especialmente durante esse período crucial de inicialização.
No entanto, esse não é um problema sem solução. Você tem algumas opções:
- Use a ferramenta de cobertura no Chrome DevTools para encontrar códigos não utilizados nos recursos do seu site. Ao reduzir o tamanho dos recursos necessários durante a inicialização, você garante que o site gaste menos tempo analisando e compilando códigos, o que resulta em uma experiência inicial mais tranquila para o usuário.
- Às vezes, o código não utilizado que usa a ferramenta de cobertura é marcado como "unused" (não utilizado) porque não foi executado durante a inicialização, mas ainda é necessário para algumas funcionalidades no futuro. Eles podem ser movidos para um pacote separado por meio da divisão de código.
- Se você estiver usando um gerenciador de tags, verifique periodicamente suas tags para garantir que elas estejam otimizadas ou mesmo se ainda estiverem sendo usadas. Tags mais antigas com código não utilizado podem ser removidas para tornar o JavaScript do Gerenciador de tags menor e mais eficiente.
Evitar grandes atualizações de renderização
O JavaScript não é o único que pode afetar a capacidade de resposta do seu site. A renderização pode ser um tipo de trabalho caro por si só e, quando grandes atualizações de renderização acontecem, elas podem interferir na capacidade do site de responder às entradas do usuário.
Otimizar o trabalho de renderização não é um processo simples e, muitas vezes, depende do que você está tentando alcançar. Mesmo assim, há algumas coisas que você pode fazer para garantir que as atualizações de renderização sejam razoáveis e não se estendam em tarefas longas:
- Evite usar
requestAnimationFrame()para fazer qualquer trabalho não visual. As chamadasrequestAnimationFrame()são processadas durante a fase de renderização do loop de eventos e, quando muito trabalho é feito durante essa etapa, as atualizações de renderização podem ser adiadas. É essencial que qualquer trabalho feito comrequestAnimationFrame()seja reservado estritamente para tarefas que envolvem atualizações de renderização. - Mantenha o DOM pequeno. O tamanho do DOM e a intensidade do trabalho do layout estão correlacionados. Quando o renderizador precisa atualizar o layout de um DOM muito grande, o trabalho necessário para recalcular o layout pode aumentar significativamente.
- Use a contenção de CSS. A contenção de CSS depende da propriedade
containdo CSS, que fornece instruções ao navegador sobre como fazer o layout do contêiner em que a propriedadecontainé definida, inclusive isolar o escopo do layout e a renderização para uma raiz específica no DOM. Nem sempre é um processo fácil, mas isolando áreas que contêm layouts complexos, você pode evitar trabalhos desnecessários de layout e renderização.
Conclusão
Melhorar o desempenho da página pode parecer uma tarefa assustadora, especialmente porque há uma montanha de orientações a serem consideradas na Web. No entanto, ao focar nessas recomendações, você pode abordar o problema com foco e propósito e melhorar as Core Web Vitals do seu site.
Embora as recomendações listadas aqui não sejam completas, acreditamos, com base em uma análise cuidadosa do estado da Web, que elas são as maneiras mais eficazes para os sites melhorarem o desempenho das Core Web Vitals em 2023.
Se quiser ir além das recomendações listadas aqui, confira esses guias de otimização para mais informações:
Desejamos um Ano Novo e uma Web mais rápida para todos! Que seus sites sejam rápidos para os usuários em todas as maneiras mais relevantes.
Foto de Devin Avery