Velocidade e Core Web Vitals
Eu corrijo a causa de um site lento. Não o sintoma.
A maior parte do trabalho de velocidade é um plugin de cache, um minificador e um novo teste cheio de esperança. Isso mexe na nota de laboratório e deixa o problema real onde estava. Eu meço para onde o tempo realmente está indo, corrijo isso e entrego um antes e depois que você pode reproduzir no seu próprio computador.
01DemonstraçãoAo vivo no seu navegador
Esta página, medida enquanto você lê.
Qualquer um que venda otimização pode mostrar a captura de um bom teste. Estes são os números que o seu próprio navegador registrou ao carregar esta página, comparados com os limites que o Google usa. Abra a aba de rede e confira.
Marcação, estilos, script e três fontes: tudo o que é preciso para mostrar o que você está lendo.
O peso mediano de uma página web segundo o HTTP Archive.
02DiagnósticoPara onde o tempo realmente vai
Lentidão é um sintoma. Estas são as causas.
Quase todo site lento que me mandam é lento por dois ou três dos motivos abaixo. O objetivo do diagnóstico é descobrir quais, porque a correção de cada um é completamente diferente, e comprar a correção errada é como as pessoas acabam pagando duas vezes por otimização de velocidade.
O servidor pensa demais
Um Time to First Byte alto significa que o trabalho acontece antes de um único byte chegar ao navegador. No WordPress, costumam ser consultas sem cache dentro do loop de um template, uma tabela de opções com autoload que cresceu até vários megabytes ou um plugin chamando uma API externa durante a renderização da página. Nenhuma otimização de front-end resolve isso.
O maior elemento da tela é enorme
Uma imagem de destaque exportada com 4000 pixels de largura e servida como PNG reprova o Largest Contentful Paint sozinha. A correção não tem glamour: dimensões corretas, formatos modernos, um srcset para que os celulares não baixem a versão de desktop, largura e altura explícitas e fetchpriority na única imagem que importa.
Scripts estão bloqueando a renderização
Cada script síncrono no head é uma placa de pare antes que o navegador consiga desenhar. Gerenciadores de tags, widgets de chat, ferramentas de teste A/B e carregadores de fontes são os suspeitos de sempre, e muitas vezes são carregados em todas as páginas para um recurso usado em uma só.
A página se mexe enquanto carrega
O Cumulative Layout Shift é causado por elementos que chegam atrasados sem espaço reservado: imagens sem dimensões, fontes web que trocam para outro tamanho, banners de cookies e anúncios inseridos acima do conteúdo existente. Costuma ser o mais barato dos três de corrigir e o mais irritante de vivenciar.
As interações parecem pesadas
O Interaction to Next Paint substituiu o First Input Delay em março de 2024 e é uma métrica bem mais exigente. Ele mede quanto tempo uma interação leva para produzir uma resposta visível, ao longo de toda a visita, e não só na primeira. Os sites reprovam porque há JavaScript demais disputando a thread principal.
03ProcessoDe fato uma sequência
Como o trabalho acontece.
- 01
Diagnóstico, antes de qualquer orçamento
- Analiso o site e envio por escrito um detalhamento de para onde o tempo vai, ordenado por quanto isso custa para você e pela dificuldade de corrigir. Esse documento fica com você, me contratando ou não.
- 02
Uma linha de base com dados de campo
- As notas de laboratório variam de um teste para outro. Primeiro registro os dados de campo do Chrome UX Report, para que no final a gente compare o que os visitantes reais viveram, e não dois testes de laboratório em tardes diferentes.
- 03
Corrigir as causas, das maiores para as menores
- O trabalho acontece em homologação, uma mudança por vez, cada uma medida separadamente. Juntar dez mudanças não diz nada sobre qual funcionou, e deixa você sem conseguir desfazer a que atrapalhou.
- 04
Verificar e depois entregar o método
- Você recebe o antes e o depois, os passos para reproduzir os dois e uma nota sobre o que vai desfazer o trabalho aos poucos: normalmente, o próximo plugin que alguém instalar.
04PerguntasFrequentes, respondidas sem rodeios
O que as pessoas perguntam antes de me contratar.
Um plugin de cache vai resolver os meus Core Web Vitals?
Em parte, na melhor das hipóteses. O cache melhora o tempo de resposta do servidor, o que ajuda o Time to First Byte. Faz muito pouco por um Largest Contentful Paint causado por uma imagem de destaque grande demais, nada por deslocamentos de layout causados por elementos sem dimensões e nada por um Interaction to Next Paint causado por JavaScript pesado. A maioria dos sites chega até mim com um plugin de cache já instalado e mesmo assim reprovando.
Por que a minha nota no PageSpeed Insights muda o tempo todo?
O número grande no topo é um teste de laboratório em um aparelho lento simulado, e ele varia de um teste para outro. A seção de baixo, os dados de campo do Chrome UX Report, é o que o Google realmente usa, e é uma média móvel de 28 dias de visitantes reais. Acompanhe os dados de campo e ignore pequenas oscilações na nota de laboratório.
Quanto tempo até a melhora aparecer no Google?
Como os dados de campo são uma janela móvel de 28 dias, conte com cerca de quatro semanas até a mudança aparecer por completo, e mais em sites com pouco tráfego, que demoram para reunir amostras suficientes. Quem promete uma mudança imediata no ranking está falando da nota de laboratório, não da que conta.
Que melhora você pode prometer?
Nenhuma antes de eu olhar, e é por isso que o diagnóstico vem primeiro e o orçamento depois. Um site cheio de plugins com uma imagem de destaque sem otimização tem muita margem fácil. Um site que já é leve no front-end, mas lento no banco de dados, é outro trabalho, com outro preço. Prefiro dar um número real depois de uma hora de análise do que um número impressionante agora.
Preciso reconstruir o site?
Normalmente, não. A maioria dos problemas de velocidade é um punhado de causas específicas, e não um defeito de base, e corrigi-las sai muito mais barato do que reconstruir. Se eu achar que você chegou ao teto do que o projeto atual consegue entregar, eu digo, mas isso é a exceção, e não é do seu interesse que eu comece por aí.
O que é INP, e ele substituiu o FID?
O Interaction to Next Paint substituiu o First Input Delay como Core Web Vital em março de 2024. O FID só media o atraso antes de o navegador começar a tratar a sua primeira interação. O INP mede quanto tempo a interação inteira levou para produzir uma resposta visível, ao longo de toda a visita. É bem mais difícil de passar, e quase sempre reprova por um motivo: JavaScript demais na thread principal.
Meu site era rápido e ficou lento. O que mudou?
Na minha experiência, quase sempre uma de três coisas: um plugin ou script de rastreamento adicionado depois, uma equipe de conteúdo enviando imagens em resolução total direto da câmera, ou um banco de dados que cresceu em silêncio (revisões de posts, transients expirados, uma tabela de opções com autoload). As três são baratas de corrigir depois de identificadas.
Próximo passo
Mande a URL. Eu digo o que está errado.
A primeira coisa que você recebe é um diagnóstico por escrito que fica com você de qualquer jeito. Se a resposta honesta for que o seu site já está bom, é isso que o documento vai dizer.