Lento por Erro vs Lento por Design: Um Framework de Performance Web

Lento por erro vs lento por design.

Quando você me contrata para corrigir ou falar sobre o Core Web Vitals, em algum momento, você me ouvirá falar sobre lento por erro vs lento por design. Acredito que esta seja uma distinção crítica a ser feita e, neste artigo, explicarei como isso ajudará você a melhorar o Core Web Vitals.

Última revisão por Arjen Karel em março de 2026

Quando alguém me pede consultoria e para corrigir o Core Web Vitals, sempre há algo errado. A lentidão sempre vem de antipadrões. Por exemplo, uma 'imagem de Largest Contentful Paint com lazy loading', 'Imagens grandes e não otimizadas', 'Sliders', 'JavaScript bloqueador' e assim por diante.

Não é preciso muito para introduzir um antipadrão. Às vezes, tudo o que você precisa fazer para criar um antipadrão é instalar um plugin ou esquecer as melhores práticas por um curto período de tempo.

Agora, gosto de categorizar esses antipadrões em 'lento por erro' e 'lento por design', porque a maneira como lido com a correção deles é completamente oposta.

Apenas 48% das origens mobile passam nos três Core Web Vitals de acordo com o Web Almanac 2025. Na minha experiência, a maioria dessas falhas vem de problemas 'lentos por erro' que podem ser corrigidos em horas.

Lento por erro

Eu adoro antipadrões 'lentos por erro'. Você fez algo que tornou a página lenta. Você cometeu um erro. Você não sabia que havia uma maneira muito mais rápida de fazer isso. Sem problemas, eu consigo corrigir erros.

Portanto, categorizar esses 'erros' faz sentido. Isso me dará uma lista de melhorias de alto impacto e fáceis de corrigir que posso enviar para sua equipe de desenvolvimento (ou corrigir eu mesmo). Geralmente, é necessária muito pouca discussão. Melhorar esses antipadrões simplesmente faz sentido em todas as direções. Uma vez corrigidos, o Core Web Vitals irá melhorar.

Aqui estão alguns exemplos de antipadrões que encontro diariamente. Quando explico o quê e o porquê, geralmente ouço 'ah, eu não sabia que isso deixaria a página lenta'.

1. Imagens sem lazy loading

O antipadrão mais comum são as imagens sem lazy loading. Imagens que não usam lazy loading serão enfileiradas para download durante os estágios iniciais do carregamento da página. Isso utilizará recursos de rede e CPU. Não faz sentido atribuir recursos preciosos a imagens que sequer estão visíveis, certo? Saiba mais sobre como adiar imagens fora da tela.

O erro oposto é igualmente comum: usar lazy loading na imagem do LCP. Cerca de 15% dos sites fazem isso, e isso faz com que a imagem mais importante da página carregue mais lentamente em vez de mais rapidamente.

2. Fontes de terceiros

Web-fonts são ótimas. Elas personalizam e melhoram a aparência da página. Infelizmente, usar um provedor de terceiros como o Google Fonts não otimizará as fontes para sua situação específica.

Fontes de terceiros exigirão uma folha de estilo extra com bloqueio de renderização, uma nova conexão com um servidor web (enquanto você já tem essa conexão muito rápida com seu servidor de origem) e provavelmente adicionarão mais fontes ao navegador do que você realmente usa.

Faria muito mais sentido hospedar suas próprias fontes, pré-carregá-las e atribuir uma estratégia de carregamento de fontes personalizada a cada arquivo de fonte. Essa é mais uma vitória rápida!

3. Scripts de terceiros

Embora não haja nada de errado com scripts de terceiros, eles causam muitos problemas devido à maneira como são adicionados às páginas. Eu me deparo com scripts de terceiros sem importância (como pixels de rastreamento do Facebook, botões de redes sociais, widgets de avaliação, etc.) que, na verdade, bloqueiam a página inteira.

É relativamente fácil e faz sentido adiar e agendar esses scripts até que o navegador tenha concluído o trabalho mais importante. No final, eu não mudei nada crítico no site, ele continua com a mesma aparência e carrega muito mais rápido. Apenas mudei a ordem em que as coisas são feitas.

4. Imagens de fundo

De uma perspectiva do Core Web Vitals, imagens de fundo fazem pouco sentido. Imagens de fundo não têm suporte nativo a lazy loading, não são responsivas e você tem pouco controle sobre seu tempo e prioridade.

Com algumas correções simples, podemos transformar essas imagens de fundo em imagens normais nas quais podemos aplicar lazy loading, torná-las responsivas e ajustar sua prioridade. Isso certamente melhorará o Largest Contentful Paint.

5. Folhas de estilo grandes

Folhas de estilo são bloqueadoras de renderização. Isso significa que, enquanto o navegador estiver carregando as folhas de estilo, a página permanecerá em branco. Há muitas coisas que você pode fazer para corrigir isso. Por exemplo, remover estilos não utilizados, dividir a folha de estilo, melhorar o cache do navegador ou adicionar Critical CSS.

Assim que tivermos melhorado as folhas de estilo, seu Largest Contentful Paint e First Contentful Paint vão melhorar dramaticamente!

Lento por design

Lento por design é a parte com a qual você deve se preocupar. Você fez escolhas estruturais que tornaram a página lenta. Elas geralmente envolvem escolhas de design de UX ou código JavaScript que modifica a parte visível da página a tal ponto que não há boas soluções alternativas.

O problema com 'lento por design' é que ele não é imediatamente corrigível fazendo pequenas alterações. Requer mais planejamento e a reescrita de alguns recursos centrais do site.

A primeira coisa que preciso fazer é descobrir a intenção: Por que você fez isso? Quais foram as considerações e o que exatamente você pretendia alcançar? E então, dentro desses parâmetros, encontrar uma alternativa melhor!

Aqui estão alguns exemplos dos erros 'lentos por design' mais comuns.

1. Sliders

Sliders geralmente funcionam assim: Quando a página é renderizada, um JavaScript injeta o slider na página. Sem esse JavaScript, a página terá uma aparência completamente diferente. Isso causará um Largest Contentful Paint mais longo, provavelmente um Layout Shift e muito provavelmente problemas com a Interaction to Next Paint (INP).

Não há solução rápida. Adiar o JavaScript melhorará as métricas de paint, mas atrasará o slider e causará um layout shift. Tornar o script do slider crítico corrigirá o Layout Shift, mas diminuirá a velocidade das métricas de paint.

A solução é aprimorar a página progressivamente. Primeiro, certifique-se de que o slider seja renderizado sem JavaScript e, em seguida, aprimore a página e transforme a imagem do slider já presente em um slider completo.

O curioso é: apenas cerca de 1% dos visitantes realmente clicam em um slider. 9 em cada 10 vezes em que explico isso, o proprietário do site sugere imediatamente a remoção do slider. É por isso que é importante perguntar sobre as intenções e considerações desses sliders. Geralmente, eles 'simplesmente estavam lá'.

2. Zoom de produto

O zoom de produto funciona assim: em uma loja virtual comum, passe o mouse sobre a imagem de um produto e você poderá aumentar o zoom em uma parte do produto. 'Zooms de produto' geralmente apresentam o mesmo problema que os sliders. Um pedaço de código JavaScript pegará suas imagens, as ocultará e depois as reescreverá na página como imagens com zoom. Isso causará um Largest Contentful Paint mais longo, provavelmente um Layout Shift e muito provavelmente problemas com a Interaction to Next Paint (INP).

A diferença em relação ao slider é que nenhum dono de produto dirá: "ah, apenas remova essa funcionalidade". É importante e aumenta a conversão.

A solução é a mesma da correção do slider. O script de zoom não deve ocultar as imagens originais, mas estender a funcionalidade da imagem do produto. Infelizmente, a funcionalidade de zoom geralmente não é corrigida facilmente e exigirá algum trabalho para ficar perfeita.

3. jQuery inline / dependências de JavaScript inline

O jQuery inline é um problema que começou como 'lento por erro', mas piorou com o tempo. Cerca de 50% dos sites que analiso sofrem com esse problema. O jQuery ainda roda em aproximadamente 70% de todos os sites de acordo com a W3Techs, então isso não vai desaparecer tão cedo. Como scripts inline dependem de um script anterior (geralmente o jQuery), você não pode mais adiar o jQuery. Isso atrasará todas as métricas de paint.

A correção é simples: basta mover esses scripts para um script externo. Agora você pode adiar tanto o jQuery quanto o script personalizado.

Então, por que coloquei isso na categoria 'lento por design'? Quando pergunto sobre intenção e consideração, geralmente recebo um 'ah, eu não sei'. E esse é o verdadeiro problema. Há uma falta de conhecimento sobre como o JavaScript funciona. Posso ter certeza de que esse erro será repetido no futuro. Isso significa que a solução não é a mesma que a correção. Precisarei educar a equipe de desenvolvimento sobre dependências e tempos do JavaScript.

4. Imagens (hero) grandes

Outro problema lento por design são as imagens grandes. Alguns sites apenas precisam 'impressionar o público' com muitas imagens em tamanho real. Imagine que você está vendendo pôsteres. Você provavelmente gostaria de exibir imagens grandes e de alta qualidade para seus visitantes. Essas imagens, não importa o quanto você as otimize, sempre levarão mais tempo para serem baixadas do que imagens menores.

Neste ponto (assumindo que todas as imagens estão otimizadas), a única coisa que posso fazer é ver se há alguma margem de manobra. Nós realmente precisamos de imagens em 4k ou full-hd também seria suficiente? Veja como corrigir imagens hero lentas para técnicas práticas.

5. Mapas interativos

Outro problema que encontro frequentemente são os mapas interativos. Quando uma página tem um mapa interativo, toda a intenção desta página é fazer com que o visitante interaja com o mapa. Obviamente, vai levar algum tempo para esse mapa carregar.

Não há como contornar isso. Teremos que aceitar alguma lentidão. Mas há coisas que podemos fazer. Podemos garantir que os mapas sejam carregados com a maior prioridade. Geralmente, essas páginas não são otimizadas para execução antecipada de JavaScript. Neste caso, essa foi a escolha errada. Precisamos que o script seja baixado e executado o mais cedo possível! Eu escrevi um guia completo sobre como incorporar o Google Maps sem perder o PageSpeed.

6. APIs lentas

Problemas de lento por design decorrentes de APIs lentas geralmente podem ser encontrados em sites SPA como React, Next.js ou Angular. APIs lentas geralmente causam grandes Layout Shifts porque os componentes são renderizados muito tarde após a interação do usuário. Problemas como este geralmente requerem uma abordagem multiequipe.

Pode ser útil distinguir entre lento por erro e lento por design quando se trata do Core Web Vitals. O lento por erro é geralmente corrigido com facilidade, enquanto o lento por design requer uma abordagem multidimensional mais minuciosa. Assim que você tiver categorizado e corrigido os problemas 'lentos por erro', configure o Real User Monitoring para rastrear o impacto. Os dados de campo dirão se as suas correções realmente melhoraram a experiência dos visitantes reais. Os problemas 'lentos por design' se destacarão claramente em seus dados porque eles são o que restou.