De vez em quando, encontramos novas técnicas para melhorar o desempenho do site pensando em melhorar nossa pontuação no Core Web Vitals.
Algumas das técnicas são construídas nativamente no navegador, como Lazy Loading ou Priority Hints, enquanto temos que abrir caminho através de outras, como atrasar o Javascript até a interação do usuário.
À medida que o desempenho da Web continua a se tornar um aspecto crucial da experiência do usuário, das taxas de conversão e das classificações dos mecanismos de pesquisa, torna-se importante acompanhar os últimos desenvolvimentos nas melhorias de performance do site.
Hoje, veremos vários erros de desempenho da Web que você precisa evitar para obter a pontuação perfeita.
Não habilitando HTTP/2 e HTTP/3
Se o seu site ainda não suporta padrões HTTP modernos, é hora de fazer um upgrade.
A maioria dos sites modernos já suporta HTTP/2 e você pode facilmente verificar o mesmo usando a versão de resposta de uma solicitação no gráfico Waterfall no SpeedVitals ou neste verificador online.
O HTTP/2 tem várias vantagens de desempenho e uma das principais é a capacidade de enviar várias solicitações em paralelo em uma única conexão TCP.
Esse recurso elimina a necessidade de combinar arquivos CSS e JavaScript como fizemos anteriormente em HTTP/1.
Você pode aprender todas as vantagens do HTTP/2 no Wikipedia.
O HTTP/3 ainda está em um estágio inicial, mas oferece vários benefícios de desempenho que você não deve perder.
Aqui está um artigo detalhado da Cloudflare sobre vários benefícios de desempenho do HTTP/3.
Se você usa a Cloudflare, pode habilitar HTTP/2 e HTTP/3 com um único clique na guia Rede no Painel do site.
Não mencionar explicitamente o tamanho da imagem na tag de imagem HTML
Por que mencionar o tamanho da imagem dentro da tag de imagem quando podemos simplesmente fazer isso via CSS?
Bem, se mencionarmos explicitamente a largura e a altura da imagem dentro da Tag HTML, o navegador reserva espaço para ela durante a renderização da página e isso evita mudanças de layout.
<img src="random-image.png" alt="Random Image" width="1920px" height="1080px"/>
A melhor prática é mencionar a largura e a altura da imagem em HTML, bem como a proporção em CSS.
img {
aspect-ratio: attribute(width) / attribute(height);
}
Se você é um usuário do WordPress, existem vários plug-ins de otimização de desempenho, como WP-Rocket e Flying Press, que podem adicionar automaticamente as dimensões de imagem ausentes.
Assumindo que um servidor/hospedagem rápido compensará o baixo desempenho do lado do cliente
Embora um Fast Server ou Hosting (ou um Fast Backend com cache adequado) resulte em um aumento de desempenho, não ajudará se o código do lado do cliente for uma bagunça.
Mesmo sites estáticos hospedados em plataformas como Netlify ou Cloudflare Pages podem ter um desempenho ruim se não forem bem otimizados.
O desempenho do lado do servidor e do lado do cliente andam de mãos dadas.
Qualquer um pode arrastar para baixo o desempenho geral.
Eu vi inúmeros proprietários de sites pulando de uma hospedagem ou provedor de nuvem para outro a cada poucas semanas na esperança de que, de alguma forma, esse novo serviço magicamente torne seu site rápido.
Mudar para um host melhor só ajudará se os recursos de hardware estiverem causando um gargalo, resultando em um tempo de resposta do servidor alto ou se ele não conseguir lidar com um grande número de usuários simultâneos.
Isso é ainda mais aplicável a CMS, como o WordPress, onde a maioria dos problemas de desempenho é resultado de um grande número de plugins não otimizados que enfileiram muitos códigos, folhas de estilo e arquivos de fonte desnecessários no front-end.
Na verdade, alguns desses plugins injetam seu código em páginas onde o plugin nem é necessário.
Portanto, é crucial prestar atenção ao desempenho do lado do cliente e do lado do servidor.
Combinando arquivos CSS/JS com HTTP/2
Com o HTTP/1.1, combinar os arquivos CSS e JavaScript ajudou significativamente no desempenho, pois reduziu o número de solicitações que um navegador precisava fazer ao servidor.
No entanto, com HTTP/2, é possível enviar várias solicitações em paralelo em uma única conexão TCP.
Portanto, a combinação de arquivos CSS e JavaScript não é mais necessária.
Na verdade, em alguns casos, combinar arquivos com HTTP/2 pode até mesmo degradar o desempenho.
Embora eu ainda recomende reduzir o número geral de solicitações e combinar alguns dos arquivos menores em um, não recomendo combinar todas as folhas de estilo, scripts e ícones em um único arquivo para cada categoria.
Ao ter alguns arquivos muito grandes, você também corre o risco de problemas de bloqueio de renderização que podem prejudicar o desempenho.
Você pode saber mais sobre as melhores práticas de desempenho da Web para HTTP/2 nesta postagem de blog da Cloudflare.
Não usar formatos de imagem modernos e técnicas de compactação
Imagens grandes e não otimizadas são outro grande culpado pelo baixo desempenho do lado do cliente.
Formatos de imagem modernos e carregamento adiado quase tornaram esse problema inexistente.
Recomendamos mudar para os formatos WebP ou AVIF.
No entanto, esses dois formatos ainda não são tão amplamente suportados e você precisará adicionar um substituto para navegadores mais antigos.
Para compactar suas imagens, você pode usar várias ferramentas online, como TinyPNG, toolur ou Squoosh.
Mas eu uso e recomendo o Compressor.io
Se você é um usuário do WordPress que usa algum Plugin para compactar imagens, ainda recomendo o upload de imagens que foram otimizadas previamente.
Não hospedar o Google Fonts localmente
Embora alguns artigos e especialistas possam argumentar que, como a maioria dos sites na Internet usa o Google Fonts, provavelmente seria armazenado em cache no navegador do usuário, e o fato de que o CDN do Google é a maneira mais rápida de entregar o Google Fonts.
No entanto, este argumento já foi provado que é errado uma e outra vez.
As comparações de desempenho mostram claramente que hospedar o Google Fonts localmente resulta em um desempenho significativamente melhor.
Você pode aprender sobre o mesmo neste artigo do WP Speed Matters.
Resumindo, os navegadores têm um conceito chamado Cache Partitioning.
Um recurso que foi armazenado em cache para um site não estará disponível para outro site, mesmo que esteja no mesmo URL.
Além disso, o Self-Hosting Google Fonts não requer o estabelecimento de uma nova conexão com o Google CDN e os arquivos podem simplesmente ser baixados da conexão existente (para seu servidor de origem ou para seu CDN).
A mesma regra também se aplica a outras bibliotecas de fontes e ícones.
Você também deve auto-hospedar todas as outras fontes de terceiros e bibliotecas de ícones, como Font Awesome.
Eu uso o plugin OMFG para hospedar as web fontes do Google no WordPress.
Carregando CSS e JS Frameworks/Bibliotecas por meio de seus CDNs
Um dos maiores erros de desempenho do lado do cliente que você pode cometer é carregar as principais estruturas/bibliotecas, como Bootstrap ou JQuery, por meio de seus respectivos CDNs.
Conforme discutido na seção anterior, o conceito chamado Cache Partitioning entra em jogo aqui.
Além disso, estabelecer conexões com várias origens durante o estágio inicial de carregamento da página é um grande fator de perda de desempenho.
Se você comparar os gráficos em cascata de recursos de terceiros carregados externamente com os auto-hospedados, observará um tempo de bloqueio significativo nos carregados externamente.
Em vez disso, você deve entregar os arquivos críticos por meio de seu servidor de origem ou de seu provedor de CDN.
Quanto menor o número de origens/CDNs que você precisa conectar para entregar um único site, melhor.
Não usar imagens responsivas
Imagens responsivas permitem que você forneça um tamanho de imagem diferente com base no tamanho da janela de visualização.
Usando o atributo scrset, você pode adicionar várias imagens dentro de uma única tag de imagem e, com base na largura da janela de visualização do dispositivo, o navegador determina o tamanho apropriado que precisa fornecer.
Portanto, em vez de ultracompactar uma imagem que pareceria inferior em um monitor 4K, você pode adicionar imagens separadas para dispositivos móveis, tablets, HD e monitores 4K.
Isso economiza largura de banda significativamente e melhora o desempenho em dispositivos menores.
Aqui está um exemplo do uso de Imagens Responsivas.
<img src="small-image.png" sizes="(max-width: 1600px) 100vw, 1600px" srcset="small-image.png 600w, medium-image.png 1200w, large-image.png 1600w" width="1600" height="900" />
Sobre o uso do pré-carregamento
Embora o pré-carregamento de recursos críticos, como os necessários para a primeira pintura, bem como o elemento LCP, possa ter uma melhoria significativa no desempenho, pré-carregar o recurso errado pode torná-lo contra-intuitivo.
Pré-carregar o recurso errado pode acabar despriorizando outros recursos críticos e aumentar o tempo de bloqueio da página.
Aqui está um exemplo de pré-carregamento.
A tag de pré-carregamento geralmente é colocada dentro da tag de HEAD.
<link rel="preload" as="image" href="image.png" />
O Google recomenda usar o pré-carregamento com moderação e eles têm um guia adequado em web.dev para utilizar o pré-carregamento de forma eficaz.
Bloqueio de renderização de recursos
Para evitar que CSS e JavaScript bloqueiem a renderização da página até que sejam carregados e executados, precisamos fazê-los carregar de forma assíncrona ou adiá-lo para ser executado somente após o carregamento da página terminar.
Um arquivo JavaScript pode se tornar não bloqueante adicionando o atributo async ou defer (ou ambos).
<script async src="script.js"></script> <script defer src="script.js"></script>
Da mesma forma, um arquivo CSS pode se tornar não bloqueante substituindo sua tag de link pelo exemplo abaixo.
<link rel="preload" href="style.css" as="style" onload="this.rel='stylesheet'">
Não remover ícones não usados de arquivos de fonte
Este é um dos maiores erros que os desenvolvedores da Web cometem e é um grande assassino de desempenho.
Para usar apenas alguns ícones de uma biblioteca de fontes como Font Awesome, você não precisa incluir a biblioteca inteira.
A maioria dos sites carrega bibliotecas de ícones no valor de 100 KBs enquanto usam apenas ícones que mal exigem 5-10 KBs.
Esse problema fica ainda pior no caso do WordPress, onde diferentes desenvolvedores de plugins incluem diferentes tipos de bibliotecas de fontes (incluindo uma versão diferente da mesma biblioteca).
Então, qual é a solução?
Uma solução é remover manualmente ou programaticamente os ícones não utilizados dos arquivos de fonte.
Alternativamente, você pode usar bibliotecas de ícones que permitem selecionar ícones específicos e construir o arquivo de fonte de acordo.
Fontello é a solução perfeita que permite criar arquivos de fonte personalizados de várias bibliotecas de ícones diferentes em um único.
Não reservando espaço para conteúdo dinâmico
O conteúdo dinâmico que é injetado após a renderização inicial da página é propenso a causar mudanças de layout.
Os anúncios são alguns dos maiores culpados.
Para evitar a mudança de layout, você precisa reservar um espaço vazio onde o elemento será renderizado.
Veja um exemplo de reserva de espaço para um anúncio de tamanho 300 x 200 px:
<div id="ad-container" style="min-width: 300px; min-height: 250px;"></div>
Para saber mais sobre como reservar espaço para o Google Adsense, confira este guia do Google.
Não atrasando arquivos JavaScript de baixa prioridade até a interação do usuário
Atrasar o carregamento e a execução de JavaScript de baixa prioridade é meu hack número 1 de desempenho da Web que pode tornar quase todas as páginas da Web pesadas em JavaScript extremamente rápidas.
Se o seu site estiver no WordPress, você pode usar o plugin Flying Scripts para implementar o mesmo.
Recomendamos adiar os seguintes scripts até a interação do usuário:
- Anúncios (Google Adsense)
- Scripts de rastreamento/análise (Google Analytics, Facebook Pixel, Hotjar)
- Avisos de cookies
- Captchas
- Google Maps
- Comentários (Disqus, Comentários do Facebook)
- Suporte ao cliente e plug-ins de bate-papo ao vivo
- Todos os outros arquivos JavaScript que não são necessários até a interação do usuário
Não utilizar o carregamento lento de forma eficaz
O Lazy Loading é uma maneira supereficaz de melhorar o desempenho da Web que pode ser usado não apenas para imagens, mas também para vídeos, incorporações (Youtube/Vimeo) e iFrames.
Para implementar o Lazy Loading, você não precisa mais usar nenhum plug-in do Lazy Loading e é suportado nativamente na maioria dos navegadores modernos.
Você pode habilitar o carregamento lento simplesmente adicionando o atributo loading=”lazy”
à sua tag Image ou iFrame.
Para um uso eficaz do Lazy Loading, você deve incluí-lo em todas as imagens e iFrame que não estiverem presentes acima da dobra.
Para carregar lentamente um vídeo, adicione o atributo preload=”none”
na tag do vídeo.
Carregamento lento da imagem do LCP
Embora o carregamento lento dê um grande aumento de desempenho, ele pode realmente fazer com que suas pontuações do Web Vitals diminuam se você carregar lentamente o Maior Elemento de Conteúdo da janela de visualização (que geralmente é uma imagem para a maioria dos sites).
Para garantir que sua pontuação LCP permaneça alta, você precisa verificar novamente e certificar-se de que não está com lazy loading a imagem LCP (ou um vídeo/iFrame).
Da mesma forma, não use lazy loading em nenhuma outra imagem acima da dobra, pois isso pode diminuir suas pontuações de desempenho tanto no ambiente de homologação quanto no de produção.
Não descarregar código de terceiros do thread principal para Web workers
Se por algum motivo não for possível atrasar o código de terceiros até a interação do usuário, a próxima melhor coisa que você pode fazer é transferi-lo para um Web Worker.
Você pode até combinar as duas técnicas!
Isso, por sua vez, ajuda a executar o código do seu site no thread principal enquanto todo o código de terceiros é executado por meio de um Web Worker.
Aqui está uma imagem que ilustra o mesmo.
Partytown by Builder.io e Cloudflare Zaraz são duas ferramentas/serviços que você deve conferir para começar a usar o mesmo.
Não utilizar as dicas iniciais
As dicas iniciais ou o código de status HTTP 103, como o nome sugere, dão uma dica muito inicial ao navegador sobre quais recursos ele deve pré-carregar.
O código de status 103 é enviado antes mesmo do código de resposta 200!
Isso, por sua vez, ajuda a carregar os recursos críticos muito mais cedo e aumenta significativamente o tempo de carregamento da página.
Aqui está um guia que você deve conferir para entender melhor as dicas iniciais.
Aqui está uma ilustração da Cloudflare sobre como as dicas iniciais funcionam:
Se você é um usuário da Cloudflare, pode ativar as dicas iniciais com um único clique na seção Velocidade -> Otimização do painel do seu site.
Não remover código CSS e JavaScript não utilizado
Muitos sites carregam todo o código CSS e JavaScript em cada página, em vez de carregá-los seletivamente por página.
À medida que o tamanho do site aumenta, a maioria de suas páginas mal usa o código CSS e JavaScript.
As páginas da Web acabam carregando o valor de MB de dados quando apenas algumas centenas de KB são realmente necessárias.
Carregar qualquer código extra que não seja necessário só prejudicará o desempenho.
Para resolver esse problema, é importante rastrear a Cobertura de código e remover os segmentos de código não utilizados.
A remoção de código não utilizado não apenas melhorará o desempenho e reduzirá o uso da largura de banda, mas também ajudará diretamente a reduzir a pegada de carbono do seu site.
O SpeedVitals tem uma seção de Cobertura de código que pode ajudá-lo a identificar arquivos que mal estão sendo usados na página.
Não enviando site para pré-carregamento HSTS
HSTS significa Strict-Transport-Security e é um cabeçalho de resposta que indica que um site só pode ser acessado com HTTPS habilitado.
Isso ajuda a evitar o ataque man-in-the-middle.
Mas o HSTS também pode ajudar a melhorar o desempenho do site enviando seu site para a lista de pré-carregamento HSTS do Google Chrome.
A maioria dos outros navegadores principais, incluindo Firefox, Safari, Opera e Microsoft Edge, também usa a lista de pré-carregamento do Chrome, então você só precisa enviar seu site em um local.
Assim que um site entrar na lista de pré-carregamento HSTS, os navegadores se conectarão automaticamente à versão HTTPS do site.
Quando um usuário abre seu site sem HTTPS, em vez de primeiro fazer uma solicitação HTTP, ele redirecionará automaticamente para a versão HTTPS.
Aqui está um exemplo do cabeçalho de resposta que você precisa antes de enviar o site na lista de pré-carregamento HSTS:
Strict-Transport-Security: max-age=31536000; includeSubDomínios; pré-carregar
Se você é um usuário da Cloudflare, pode definir facilmente esse cabeçalho usando este guia.
Certifique-se de ativar a opção de pré-carregamento.
Ignorando os tempos de resposta do servidor
Sempre enfatizei que o tempo de resposta do servidor ou TTFB é uma das métricas mais importantes no Web Performance.
Um alto tempo de resposta do servidor adicionará tempo extra ao restante das métricas de desempenho, incluindo Web Vitals, como FCP e LCP.
Por exemplo, se um site tiver um TTFB de 1 segundo e LCP de 3,5 segundos, reduzir o TTFB para 200 ms trará o LCP para 2,7 segundos sem fazer nenhuma alteração no lado do cliente!
Um tempo de resposta lento é devido a um back-end lento ou alta latência de rede (ou uma combinação de ambos).
Usando JavaScript para recursos suportados nativamente em HTML e CSS
Um dos segredos para um ótimo desempenho do lado do cliente é o uso mínimo de JavaScript.
Você ficará surpreso ao saber o número de coisas que você pode fazer apenas com HTML e CSS!
Alguns dos recursos que você pode implementar sem JavaScript incluem, mas não estão limitados a:
- Modo escuro
- Envio de formulário
- Popovers
- Avisos de cookies
- Filtros
- Controles deslizantes de comparação
- Carrosséis
- Barras laterais
- Efeito de paralaxe
- Animações de gradiente
- Caixa de luz
Sempre que você estiver adicionando um novo recurso no site, primeiro verifique se ele pode ser implementado sem JavaScript.
Se o JavaScript for obrigatório para um determinado recurso, tente codificar sua própria solução e procure exemplos on-line e faça o possível para evitar soluções que exijam a adição de uma biblioteca de terceiros para uma tarefa simples.
Não utilizando cache de página inteira (cache HTML)
Full Page Caching ou HTML Caching pode dar um aumento significativo de desempenho quando o desempenho do lado do servidor é o culpado.
Uma CDN pode entregar a versão totalmente em cache do seu site em todo o mundo com tempos de resposta abaixo de 200 ms.
Isso é especialmente útil quando um site tem usuários de diferentes regiões do mundo.
Nosso artigo sobre como reduzir o tempo de resposta do servidor também fala sobre o cache de página inteira em detalhes. Você pode ler o artigo para entender se seu site é elegível para HTML Caching.
Serviços como Netlify e Cloudflare Pages podem hospedar seu Site Estático gratuitamente e distribuí-lo em todo o mundo em velocidades ultrarrápidas com a ajuda de suas Edge Networks.
Não monitorar o desempenho regularmente
A otimização do desempenho da Web não é um processo único (a menos que você pare de fazer alterações no site).
Cada pequena mudança que você faz pode ter um impacto positivo ou negativo no desempenho e monitorar o mesmo é crucial para garantir que seu site permaneça rápido.
O monitoramento fica ainda mais importante com a atualização do Core Web Vitals do Google, pois depende de dados do mundo real que são atualizados continuamente.
O que dizem os profissionais de SEO
As CWV por vezes são hiperestimadas como estratégia de SEO. Ela é mais importante como ganho de UX. Você mede os CWV nos ganhos de visualizações de página, tempo, etc, não na SERP. Em geral eu tento buscar ações que tenham um efeito com mais escala: melhorar o servidor, diminuir a quantidade de webfonts e ícones, diminuir a quantidade de scripts
Gustavo Rodrigues
O que eu recomendo (minha pequena contribuição): tomar cuidado com as otimizações de imagens, o Google lança muito “falsos positivos”, onde a página renderizada não é compatível com os dados de origem dos arquivos que as ferramentas sinalizam. Ex: na renderização VTEX uma imagem de 1MB é comprimida e chega a 63kb pro usuário e no pagespeed ou lighthouse temos uma sinalização pra otimizar essas imagens, pois a ferramenta de análise puxa o arquivo de origem e não o arquivo renderizado pela compressão das plataformas. Lembrando que o Google considera os dados de campo dos usuários pra fins de coleta de dados de CWV, logo, se o usuário renderiza 63kb é esse que deve ser considerado. E fazer otimizações a ponto de reduzir significativamente a qualidade das imagens pode causar efeito reverso e ao invés de melhorar, pode piorar as classificações nos resultados de busca
Tiago da Silva Candido
Core Web Vitals: conclusão
É isso!
Fazer o SEO técnico não é fácil e exige muita experiência, mas é essencial para o sucesso do seu site.
Consultor SEO e especialista em Otimização de Sites com foco em aumentar o tráfego orgânico. Professor e Especialista de SEO a mais de 20 anos com vasta experiência em SEO para pequenas, médias e grandes empresas.