Lento por engano vs lento por design

Lento por engano vs lento por design.

Quando você me contrata para corrigir 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 fazer e neste artigo vou explicar como isso vai ajudá-lo a melhorar os Core Web Vitals.

Lento por engano

Eu adoro anti-padrões de 'lento por engano'. Você fez algo que deixou a página lenta. Você cometeu um erro. Você não sabia que existe uma maneira muito mais rápida de fazer isso. Sem problemas, eu posso corrigir erros. 

Então, categorizar esses 'erros' faz sentido. Isso me dará uma lista de melhorias fáceis de implementar e de alto impacto que posso enviar para sua equipe de desenvolvimento (ou corrigir eu mesmo). Geralmente há muito pouca discussão necessária. Melhorar esses anti-padrões simplesmente faz sentido de todos os ângulos. Uma vez corrigidos, os Core Web Vitals vão melhorar.

Aqui estão alguns exemplos de anti-padrões que encontro diariamente. Quando eu explico o quê e por quê, geralmente recebo 'ahh, eu não sabia que isso ia deixar a página lenta'.

1. Imagens sem lazy load

O anti-padrão mais comum são imagens sem lazy load. Imagens que não têm lazy load serão enfileiradas para download durante os estágios iniciais do carregamento da página. Isso usará recursos de rede e CPU. Não faz sentido atribuir recursos preciosos a imagens que nem estão visíveis, certo? 

2. Fontes de terceiros

3. Scripts de terceiros

4. Imagens de fundo

5. Folhas de estilo grandes

Lento por design

Lento por design é a parte com a qual você deveria se preocupar. Você fez escolhas estruturais que deixaram a página lenta.  Elas geralmente envolvem escolhas de design 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 mudanças. Requer mais planejamento e reescrita de algumas funcionalidades principais 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 mais comuns de 'lento por design'.

1. Sliders

Sliders geralmente funcionam assim: Quando a página renderiza, um JavaScript vai injetar o slider na página. Sem esse JavaScript, a página vai parecer completamente diferente.  Isso causará um Largest Contentful Paint mais longo, provavelmente um Layout Shift e muito provavelmente problemas com o First Input Delay.

Não há correção rápida. Adiar o JavaScript vai melhorar as métricas de pintura, mas vai atrasar o slider e causar um layout shift. Tornar o script do slider crítico vai corrigir o Layout Shift, mas vai deixar as métricas de pintura mais lentas.

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

O mais divertido é: 9 em cada 10 vezes, quando eu explico isso, o dono do site imediatamente sugere remover o 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: na sua loja virtual comum, passe o mouse sobre a imagem de um produto e você pode ampliar uma parte do produto.  O 'zoom de produto' geralmente tem o mesmo problema que os sliders.  Um trecho de código JavaScript vai pegar suas imagens, ocultá-las e reescrevê-las na página como imagens com zoom. Isso causará um Largest Contentful Paint mais longo, provavelmente um Layout Shift e muito provavelmente problemas com o First Input Delay.

A diferença em relação ao slider é que nenhum dono de produto jamais dirá: "ah, é só remover 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 é facilmente corrigida e vai exigir  algum trabalho para ficar perfeita.

3. jQuery inline / dependências de JavaScript inline

jQuery inline é um problema que começou como 'lento por engano', mas piorou com o tempo. Cerca de 50% dos sites que eu analiso sofrem desse problema. Como scripts inline dependem de um script anterior (geralmente jQuery), você não pode mais adiar o jQuery. Isso vai atrasar todas as métricas de pintura.

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 eu pergunto sobre a intenção e consideração, geralmente recebo 'ah, eu não sei'. E esse é o verdadeiro problema. Há uma falta de conhecimento sobre como o JavaScript funciona.  Posso ter bastante certeza de que esse erro será repetido no futuro. Isso significa que a solução não é a mesma que a correção. Vou precisar educar a equipe de desenvolvimento sobre dependências e timing de JavaScript.

4. Imagens grandes (hero)

Outro problema de lento por design são imagens grandes. Alguns sites simplesmente 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 baixar do que imagens menores. 

Neste ponto (assumindo que as imagens estão todas otimizadas), a única coisa que posso fazer é ver se há alguma margem de manobra. Realmente precisamos de imagens 4K ou full-HD também seria suficiente?

5. Mapas interativos

Outro problema que encontro frequentemente são mapas interativos. Quando uma página tem um mapa interativo, toda a intenção dessa página é fazer o visitante interagir 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 baixe e execute o mais cedo possível!

6. API's lentas

Conclusão

Pode ser útil distinguir entre lento por engano e lento por design quando se trata dos Core Web Vitals. Lento por engano geralmente é facilmente corrigido, enquanto lento por design requer uma abordagem mais profunda e multidimensional.