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

Lento por engano vs lento por design.

Quando você me contrata para consertar ou falar sobre os Core Web Vitals, em algum momento, você vai me ouvir falar sobre lento por engano vs lento por design. Eu acho que é uma distinção crítica a se fazer e neste artigo vou explicar como isso vai te ajudar a melhorar os Core Web Vitals.

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

Quando alguém me pede para consultar e consertar os Core Web Vitals, sempre há algo errado. A lentidão sempre vem de anti-patterns. 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 anti-pattern. Às vezes, tudo o que você precisa fazer para criar um anti-pattern é instalar um plugin ou esquecer as melhores práticas por um curto período.

Agora, eu gosto de categorizar esses anti-patterns em 'lento por engano' e 'lento por design' porque a maneira como abordo a correção deles é completamente oposta.

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

Lento por engano

Eu adoro anti-patterns 'lentos por engano'. Você fez algo que deixou a página mais lenta. Você cometeu um erro. Você não sabia que existe uma maneira muito mais rápida de fazer isso. Não se preocupe, eu posso consertar erros.

Portanto, categorizar esses 'erros' faz sentido. Isso me dará uma lista de melhorias fáceis de consertar e de alto impacto que posso enviar para a sua equipe de desenvolvimento (ou consertar eu mesmo). Geralmente, há muito pouca discussão necessária. Melhorar esses anti-patterns simplesmente faz sentido por todos os lados. Assim que forem consertados, os Core Web Vitals vão melhorar.

Aqui estão alguns exemplos de anti-patterns que eu encontro diariamente. Quando eu explico o que e por que, geralmente recebo um 'ahh, eu não sabia que isso deixaria a página mais lenta'.

1. Imagens sem lazy loading

O anti-pattern mais comum são imagens sem lazy loading. Imagens que não têm lazy loading serão colocadas na fila para download durante os estágios iniciais do carregamento da página. Isso usará recursos de rede e CPU. Não faz sentido alocar recursos preciosos para imagens que nem estão visíveis, certo? Saiba mais sobre adiar imagens fora da tela.

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

2. Fontes de terceiros

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

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

Faria mais sentido hospedar suas próprias fontes, fazer o preload delas e atribuir uma estratégia de carregamento de fontes personalizada a cada arquivo de fonte. Essa é mais uma vitória rápida bem aí!

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 mídia social, 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 feito 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. Eu apenas mudei a ordem em que as coisas são feitas.

4. Imagens de fundo

Da perspectiva dos 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 o tempo e a prioridade delas.

Com algumas correções fáceis, podemos transformar essas imagens de fundo em imagens normais que podemos aplicar lazy load, tornar responsivas e ajustar sua prioridade. Isso certamente melhorará o Largest Contentful Paint.

5. Folhas de estilo grandes

Folhas de estilo bloqueiam a renderização (render blocking). 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 consertar 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 drasticamente!

Lento por design

Lento por design é a parte com a qual você deve se preocupar. Você fez escolhas estruturais que deixaram a página mais 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 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 renderiza, um JavaScript injeta o slider na página. Sem esse JavaScript, a página parecerá completamente diferente. Isso causará um Largest Contentful Paint mais longo, provavelmente um Cumulative Layout Shift e muito provavelmente problemas com a Interaction to Next Paint (INP).

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

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

O engraçado é que: apenas cerca de 1% dos visitantes realmente clica em um slider. Em 9 de cada 10 vezes em que explico isso, o proprietário do site sugere imediatamente remover o slider. É por isso que é importante perguntar sobre as intenções e considerações desses sliders. Normalmente, eles 'estavam lá apenas por estar'.

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ê pode ampliar uma parte do produto. 'Zooms de produto' geralmente têm o mesmo problema que os sliders. Um pedaço de código JavaScript pegará suas imagens, as ocultará e as reescreverá na página como imagens que podem ser ampliadas. Isso causará um Largest Contentful Paint mais longo, provavelmente um Cumulative Layout Shift e muito provavelmente problemas com a Interaction to Next Paint (INP).

A diferença com o slider é que nenhum proprietário de produto jamais dirá: "ah, é só remover essa funcionalidade". Ela é 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 sim estender a funcionalidade da imagem do produto. Infelizmente, a funcionalidade de zoom geralmente não é facilmente consertada e exigirá algum trabalho para ficar perfeita.

3. Dependências de jQuery inline / JavaScript inline

jQuery inline é um problema que começou como um 'lento por engano', mas piorou com o tempo. Cerca de 50% dos sites que eu analiso sofrem com esse problema. O jQuery ainda roda em cerca de 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 jQuery), você não pode mais adiar o jQuery. Isso atrasará todas as métricas de renderização.

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 eu coloquei isso na categoria 'lento por design'? Quando pergunto sobre a intenção e a 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 quase 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 timing do JavaScript.

4. Imagens grandes (hero)

Outro problema lento por design são 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 servir imagens grandes e de alta qualidade aos 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 (supondo que as imagens estejam todas otimizadas), a única coisa que posso fazer é ver se há alguma margem de manobra. Nós realmente precisamos de imagens 4K ou o full-hd também seria suficiente? Veja como consertar imagens hero lentas para técnicas práticas.

5. Mapas interativos

Outro problema que encontro com frequência são mapas interativos. Quando uma página tem um mapa interativo, a intenção de toda essa 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 prioridade mais alta. Geralmente, essas páginas não são otimizadas para execução inicial do JavaScript. Neste caso, essa foi a escolha errada. Precisamos que o script seja baixado e executado o mais cedo possível! Escrevi um guia completo sobre como incorporar o Google Maps sem perder o PageSpeed.

6. APIs lentas

Problemas lentos por design que surgem de APIs lentas geralmente podem ser encontrados em sites SPA como React, Next.js ou Angular. APIs lentas geralmente causarão grandes Cumulative Layout Shifts porque os componentes renderizam tarde demais após a interação do usuário. Problemas como este geralmente requerem uma abordagem multiequipe.

Pode ser útil distinguir entre lento por engano e lento por design quando se trata dos Core Web Vitals. Lento por engano geralmente é consertado com facilidade, enquanto o lento por design requer uma abordagem multidimensional mais completa. Uma vez que você categorizou e consertou os problemas 'lentos por engano', configure o Real User Monitoring (RUM) para rastrear o impacto. Dados de campo dizem se suas correções realmente melhoraram a experiência para visitantes reais. Os problemas 'lentos por design' então se destacarão claramente nos seus dados porque eles são o que restou.