Módulo 3 · 5 de 7

Performance: a responsabilidade que ninguém te contou

Leitura: ~5 min

Quando o assunto é performance, a maioria dos designers pensa "isso é coisa de dev". E em parte é. Mas pense comigo: quem escolhe se a hero image vai ser uma foto de 5MB ou uma ilustração vetorial de 30KB? Quem decide se a animação de entrada vai ser um GIF pesado ou uma transição CSS leve? Quem desenha uma página com 15 imagens acima da dobra? O designer.

Performance não é só sobre código otimizado. É sobre decisões de design que impactam diretamente quanto tempo o usuário espera para ver o conteúdo. E ninguém gosta de esperar.

Imagens: o vilão silencioso

Imagens são, de longe, o maior fator de peso em uma página. E o formato que você escolhe faz toda a diferença. Vamos aos principais:

  • JPG: bom para fotos. Comprime bem, mas perde qualidade. Ideal para hero images, fotos de produto, backgrounds fotográficos.
  • PNG: bom para imagens com transparência (ícones com fundo transparente, por exemplo). Mas é pesado. Um PNG de uma foto pode ter 5MB facilmente.
  • WebP: o formato moderno. Faz tudo que JPG e PNG fazem, mas com arquivos muito menores. Um JPG de 800KB vira um WebP de uns 550KB com a mesma qualidade visual (o estudo de compressão do Google mede WebP entre 25% e 34% menor que um JPEG equivalente); se o JPG original estiver mal otimizado, como uma foto exportada direto da câmera, a economia pode passar de 50%. Hoje todos os navegadores modernos suportam.
  • SVG: perfeito para ícones, logos e ilustrações simples. É código, não pixel. Escala infinitamente sem perder qualidade e pesa quase nada.

Você não precisa otimizar imagens manualmente. Mas precisa saber que quando você coloca um PNG de 5MB em um banner, esse banner vai travar o celular do seu usuário. E quando o dev pedir para trocar por WebP, você precisa entender por quê.

Lazy loading: o que aparece primeiro?

Imagine uma página com 30 imagens. Se o navegador tentar carregar todas ao mesmo tempo, a página vai demorar para aparecer. Lazy loading (o "carregamento preguiçoso" que apareceu lá no Módulo 1) resolve isso: as imagens que estão fora da tela (abaixo da dobra) só começam a carregar quando o usuário rola até elas.

O conceito importante aqui é above the fold, que significa "acima da dobra", ou seja, o que o usuário vê sem rolar. Esse conteúdo precisa carregar rápido porque é a primeira impressão. Todo o resto pode esperar.

Para o designer, isso significa pensar em prioridade: o que é essencial que apareça imediatamente? E o que pode esperar? Quando você organiza a hierarquia visual da página, está indiretamente dizendo para o navegador o que carregar primeiro.

Animações: leves ou pesadas?

Nem toda animação custa o mesmo para o navegador. Aqui vai uma escala rápida, da mais leve para a mais pesada:

  • CSS transitions: mudar cor, opacidade, tamanho com transition. Leve. O navegador otimiza nativamente. Use sem medo para hovers, reveals e micro-interações.
  • CSS animations: animações com @keyframes. Ainda leves, especialmente se animam transform e opacity (que o navegador acelera via GPU).
  • Lottie: animações exportadas do After Effects como JSON. São vetoriais e geralmente mais leves que GIFs, mas o player JavaScript adiciona peso. Bom para onboarding e ilustrações animadas.
  • JS animations pesadas: animar propriedades como width, height ou top via JavaScript. Pesado. Causa reflow (o navegador precisa recalcular o layout inteiro). Evite.
  • GIFs animados: pesados, sem controle de qualidade, sem transparência decente. Em quase todos os casos, Lottie ou vídeo MP4 são melhores opções.

Você não precisa saber implementar nada disso. Mas quando você especifica "quero uma animação de entrada neste card", faz diferença saber que uma transição CSS é praticamente gratuita enquanto um GIF de 2MB é um problema de performance.

Lighthouse: seu novo melhor amigo

Lighthouse é uma ferramenta do Google que audita a performance de qualquer página web. Ela vem embutida no DevTools do Chrome, e rodar uma auditoria leva menos de um minuto. Se preferir não abrir o DevTools, dá para rodar a mesma auditoria pelo navegador em PageSpeed Insights, colando a URL da página.

Como rodar: abra o DevTools (F12 ou Ctrl+Shift+I), vá na aba Lighthouse, selecione "Performance" e clique em "Analyze page load". Em poucos segundos, você recebe uma nota de 0 a 100 e uma lista de problemas.

Das métricas que o Lighthouse mostra, várias são diretamente influenciadas pelo design:

  • LCP (Largest Contentful Paint): quanto tempo até o maior elemento visível carregar. Se sua hero image é um PNG de 5MB, o LCP vai ser terrível.
  • CLS (Cumulative Layout Shift): quanto a página "pula" durante o carregamento. Se imagens carregam sem dimensões definidas, o texto pula para baixo. Isso é problema de design.
  • TBT (Total Blocking Time): quanto tempo a página fica "travada", sem responder a cliques, durante o carregamento. Animações e JavaScript pesado aumentam esse tempo.

Esses indicadores fazem parte dos Core Web Vitals, as três métricas que o Google usa para avaliar a experiência de uma página: LCP, CLS e INP. Se as siglas embolarem, guarde assim: LCP é velocidade de carregamento, CLS é estabilidade visual e INP é resposta ao toque. (E o TBT da lista acima? É a aproximação que o Lighthouse usa para o INP, porque ele mede em condições controladas, na sua própria máquina, e não com usuários reais navegando pelo site.) Você não vai otimizar o código, mas vai saber projetar de um jeito que não cria problemas de performance.

Checagem rápida

Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.

Você vai entregar uma tela com uma foto de capa e um conjunto de ícones. Qual formato pede para cada um?

Para a foto, WebP: faz o que JPG e PNG fazem, com arquivos bem menores e a mesma qualidade visual. Para os ícones, SVG: como é código e não pixel, escala sem perder nitidez e pesa quase nada. A troca comum de "PNG de 5MB por WebP" é sobre a foto; ícone quase nunca deveria ser imagem pesada.

O dev diz que o LCP da landing está ruim e olha para você. Por que isso é conversa de design, e não só de código?

LCP (Largest Contentful Paint) mede quanto tempo leva até o maior elemento visível carregar, e esse elemento costuma ser a hero image que você escolheu. Se ela é um PNG de 5MB, o LCP vai ser terrível. Trocar por um WebP otimizado, ou repensar se aquela imagem gigante precisa mesmo estar ali, é uma decisão de design que mexe direto na métrica.