O desempenho piora. Uma página que carregava em dois segundos carrega agora em quatro. Alguma coisa mudou.
A resolução de problemas responde: o que mudou. Porque piorou o desempenho.
Causas de raiz: uma nova funcionalidade acrescentou um pacote grande de JavaScript. Uma consulta à base de dados ficou lenta. Foi acrescentado um script de terceiros. O tamanho das imagens aumentou. O servidor ficou sobrecarregado.
Uma resolução sistemática encontra a causa de raiz. Uma correção sistemática remove a causa de raiz.
Método de resolução de problemas
Passo um: identificar o sintoma. O LCP passou de dois para quatro segundos. O CLS passou de zero vírgula zero cinco para zero vírgula dois. O INP passou de cem para quatrocentos milissegundos.
Passo dois: cronologia. Quando começou a piora. Na semana passada. No último dia. Na última hora. A cronologia reduz a busca.
Passo três: ligar às alterações. Que código mudou. Que funcionalidades foram publicadas. Que infraestrutura mudou. A correlação identifica a causa.
Passo quatro: isolar a causa. O desempenho piorou. Hipótese: o novo pacote de JavaScript. Teste: medir o LCP com o novo pacote desativado. O LCP volta a dois segundos. Hipótese confirmada.
Passo cinco: corrigir ou reverter. Corrigir a causa (otimizar o pacote) ou reverter (anular a alteração). A decisão depende da gravidade.
Exemplo real: quebra de desempenho numa loja online
Sintoma: o LCP aumentou de dois segundos para três vírgula cinco segundos. Detetado por um alerta de monitorização.
Cronologia: a piora aconteceu na terça-feira de manhã. A equipa publicou um novo motor de recomendações na segunda-feira à noite.
Correlação: a coincidência sugere que o motor de recomendações causou a piora.
Teste de isolamento: desativar o motor de recomendações. O LCP volta a dois segundos. Motor de recomendações confirmado como causa.
Investigação: o motor de recomendações carrega imagens de produtos para as recomendações. As imagens não estão otimizadas (tamanho original, sem compressão). Carregar cinquenta imagens de produtos acrescenta dois megabytes à página.
Correção: otimizar as imagens do motor de recomendações. Comprimir as imagens, usar lazy loading nas imagens abaixo da dobra. O tamanho das imagens desce para quinhentos quilobytes. O LCP melhora para dois vírgula dois segundos.
Implementação: reverter o motor de recomendações, publicar a versão otimizada. O LCP volta a dois vírgula dois segundos.
Problemas de desempenho comuns e soluções
Problema um: pacote de JavaScript grande
- Sintoma: LCP lento, INP lento
- Causa: uma nova funcionalidade acrescenta código, o pacote cresce
- Solução: dividir o código da funcionalidade, carregá-la com lazy loading
- Melhoria esperada: o LCP melhora em zero vírgula cinco segundos
Problema dois: consultas lentas à base de dados
- Sintoma: TTFB lento
- Causa: uma consulta à base de dados ficou lenta (índice em falta, consulta que junta muitas tabelas)
- Solução: acrescentar um índice à base de dados, otimizar a consulta, guardar os resultados em cache
- Melhoria esperada: o TTFB melhora em duzentos milissegundos
Problema três: imagens não otimizadas
- Sintoma: LCP lento, largura de banda elevada
- Causa: as imagens são grandes (sem compressão, formato errado)
- Solução: comprimir as imagens, converter para WebP, usar imagens adaptáveis
- Melhoria esperada: o LCP melhora em um segundo
Problema quatro: scripts de terceiros
- Sintoma: LCP lento, a página deixa de responder
- Causa: análise, rastreamento e anúncios de terceiros abrandam a página
- Solução: carregar os scripts de terceiros com lazy loading, usar um web worker, carregar de forma assíncrona
- Melhoria esperada: o LCP melhora em zero vírgula cinco segundos, o INP melhora em cem milissegundos
Problema cinco: CLS causado por anúncios ou conteúdos incorporados
- Sintoma: o layout muda enquanto se lê
- Causa: os anúncios carregam e ocupam espaço, o conteúdo desloca-se
- Solução: reservar espaço para os anúncios, carregar anúncios abaixo da dobra com lazy loading
- Melhoria esperada: o CLS melhora de zero vírgula dois para zero vírgula zero cinco
Monitorização para deteção precoce
Alerta de piora: se o LCP passar de dois vírgula cinco segundos, avisa a equipa.
Alerta de regressão: se o LCP aumentar mais de zero vírgula cinco segundos face ao ponto de partida, avisa a equipa.
Alerta de impacto no negócio: se a conclusão de registos descer um por cento, avisa a equipa (pode indicar um problema de desempenho).
Exemplo real: alertas numa empresa de SaaS
- Alerta um: se o LCP passar de dois vírgula cinco segundos
- Alerta dois: se for detetada uma regressão de desempenho (o LCP aumenta cinquenta por cento num dia)
- Alerta três: se os Core Web Vitals passarem de bons a precisa de melhorias para mais de cinco por cento dos utilizadores
- Alerta quatro: se a conclusão de registos descer abaixo do objetivo (pode indicar um problema de desempenho na página de pagamento)
Quando um alerta dispara: a equipa de engenharia investiga numa hora. A causa de raiz é identificada. A correção é publicada no mesmo dia.
Exemplo real: problema de desempenho no processamento de pagamentos
Sintoma: a taxa de abandono do pagamento subiu de quinze por cento para vinte e cinco por cento. Começou na quinta-feira.
Investigação: o desempenho da página de pagamento piorou. O tempo de interação do botão de pagamento aumentou de duzentos milissegundos para um segundo.
Cronologia: o processador de pagamentos fez uma alteração de infraestrutura na quinta-feira de manhã.
Causa de raiz: o processador de pagamentos mudou da Califórnia para a Europa. A latência de rede entre o utilizador e o processador de pagamentos aumentou duzentos milissegundos. O tempo total de processamento do pagamento subiu para um segundo.
Solução: usar um ponto de presença da CDN perto do utilizador. Encaminhar o pedido de pagamento por um ponto de presença local da CDN. O ponto de presença reencaminha para o processador de pagamentos europeu. A latência de rede diminui. O tempo de processamento do pagamento volta a duzentos milissegundos.
Resultado: a taxa de abandono do pagamento volta a quinze por cento.
Impacto no negócio: cinco mil pagamentos mensais com quinze por cento de abandono são setecentas e cinquenta conversões falhadas. Com um valor de encomenda de cem dólares, são setenta e cinco mil dólares perdidos por mês. Corrigir o problema de latência poupou à empresa setenta e cinco mil dólares por mês.
Perguntas frequentes
Como diagnosticamos se um problema de desempenho é causado pelo código ou pela infraestrutura?
Testa os dois. Desativa o código novo (reverte). Se o desempenho voltar ao normal, a causa é o código. Se o desempenho continuar lento, a causa é a infraestrutura. Isola de forma sistemática. Não culpes a infraestrutura se a causa for o código (nem o contrário). Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
Devemos reverter ou corrigir quando o desempenho piora?
A gravidade decide. Se a piora for grave (o LCP sobe de dois para cinco segundos), reverte de imediato. A experiência do utilizador está afetada. Corrige depois. Se a piora for ligeira (o LCP sobe de dois para dois vírgula três segundos), corrige no local. O risco de reverter é menor do que o risco de publicar uma correção incompleta.
Como evitamos que problemas de desempenho cheguem à produção?
Testes de desempenho no pipeline de CI/CD. Antes de cada publicação, mede o desempenho. Se o orçamento de desempenho for excedido, bloqueia a publicação. Previne regressões antes de acontecerem.
E se o problema de desempenho for intermitente?
Os problemas intermitentes são mais difíceis de diagnosticar. Recolhe mais dados. Monitoriza durante mais tempo. Um problema intermitente pode indicar: problema de rede (acontece em redes lentas), problema de tráfego (acontece em horas de ponta), problema de navegador (acontece em navegadores específicos). Reduz o âmbito. Testa a hipótese numa rede, hora ou navegador específicos.
Como comunicamos os problemas de desempenho aos utilizadores?
A transparência gera confiança. Se o problema de desempenho é conhecido e está a ser corrigido, diz aos utilizadores. Exemplo: piora de desempenho na página de pagamento devido à migração do processador de pagamentos. Correção prevista para amanhã. Estamos a investigar. A transparência reduz a frustração.
Devemos ter um engenheiro de desempenho de prevenção?
Em sites críticos para o negócio (loja online, SaaS), sim. O engenheiro de prevenção responde a alertas de desempenho em trinta minutos. Investiga. Publica a correção ou reverte. Evita que o problema de desempenho afete os utilizadores a longo prazo.