Velocidade de site em 2026: por que trato performance como decisão de design, não de programação

Velocidade de site em 2026 é decisão de design, não um ajuste técnico que aparece no fim do projeto. Os três números que o Google usa continuam sendo LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1, e o que mais reprova hoje é o INP, a demora entre o clique e a tela responder. Na minha experiência, isso quase sempre se resolve escolhendo menos coisa no layout, não contratando um servidor maior.

O que mudou na conta de velocidade em 2026

Passei os últimos anos ouvindo cliente dizer que site rápido é assunto de programador. Não é mais, e acho ótimo. O que decide a nota hoje é o que eu coloco na tela: quantas fontes, quantos scripts de animação, quantos widgets de terceiro, se o herói é vídeo em autoplay ou uma imagem bem tratada. Tudo isso é escolha de design, e eu assumo essa escolha.

O INP virou o vilão do ano

O INP mede quanto tempo a interface leva para responder a uma interação. Ele é a métrica mais reprovada de 2026: cerca de 43% dos sites ainda estouram o limite de 200 milissegundos. Faz sentido. Um site que carrega rápido e trava no primeiro clique passa uma sensação pior do que um site que demora um pouco e responde na hora. Aqui no Studio Seu eu costumo testar o menu, o filtro e o botão de compra em um celular médio antes de aprovar qualquer camada extra de animação.

TTFB é teto, não detalhe

O TTFB, o tempo até o primeiro byte, é tratado como bom abaixo de 200 milissegundos e ruim acima de 500. Eu gosto de explicar isso para o cliente com uma frase simples: o TTFB é o piso do LCP. Se o servidor demora meio segundo para dar sinal de vida, não existe otimização de imagem que salve a primeira impressão. É por isso que hospedagem e CMS entram na conversa junto com paleta e tipografia, não depois.

Medir deixou de ser coisa só do Chrome

Essa é a novidade que mais mudou o meu discurso comercial. Desde dezembro de 2025, LCP e INP também existem no Safari e no Firefox, e o Interop 2026 segue empurrando a padronização, com proposta de incluir o CLS. Antes eu ouvia que aquele número era "coisa do Google". Agora é o comportamento medido em quase todo navegador que o cliente usa, e a conversa fica muito mais honesta.

Por que isso é decisão de design, e não de programação

Peso de página não nasce no código, nasce na reunião de aprovação. Nasce quando alguém pede um carrossel com sete banners, um vídeo de fundo em tela cheia, três fontes personalizadas e um chat que carrega antes de qualquer coisa. Eu já entreguei sites lindos que reprovavam em INP, e aprendi que o problema não estava no desenvolvedor: estava no meu layout.

Hoje eu desenho com um orçamento de performance na mão, do mesmo jeito que desenho com uma grade. Se entra um efeito novo, sai outra coisa. Isso deixou meus projetos mais secos e, curiosamente, mais bonitos, porque força hierarquia de verdade em vez de acumular camadas.

O CSS nativo tirou muito peso do meu trabalho

A boa notícia de 2026 é que dá para ser expressivo sem carregar meio megabyte de JavaScript. As animações guiadas por rolagem já rodam em CSS puro e substituem bibliotecas como GSAP ScrollTrigger e AOS na maioria dos casos. As container queries chegaram no estágio de "pode usar sem medo". O seletor :has() resolve em uma linha o que antes exigia script. O posicionamento por âncora e o masonry nativo com grid completam a lista. Some a isso a virada server-first, com renderização no servidor por padrão em frameworks modernos, e você tira trabalho do celular do visitante sem tirar personalidade do projeto.

Minha opinião sincera: boa parte dos sites que vejo em 2026 ainda carrega biblioteca de animação para fazer três elementos aparecerem na rolagem. Isso é peso que o cliente paga em conversão, não em fatura.

O checklist que eu uso antes de entregar

• Um herói, uma ideia: imagem tratada em vez de vídeo em autoplay, com dimensão reservada para não gerar salto de layout.
• Fonte com orçamento: uma família variável costuma resolver o projeto inteiro.
• Animação em CSS primeiro: só entra JavaScript quando o efeito realmente não existe de forma nativa.
• Terceiros com hora marcada: chat, mapa e pixel carregam depois da interação, nunca antes.
• Teste no celular real: aparelho intermediário, rede fraca, dedo no botão principal.
• Número anotado no relatório: LCP, INP e CLS entram na entrega como entram as cores da marca.

Perguntas frequentes

Quais são as métricas de velocidade que importam em 2026?

LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1. O INP é o que mais reprova hoje, porque mede a resposta ao clique, não o carregamento.

Site rápido melhora posição no Google?

Ajuda, mas eu não vendo velocidade como truque de ranqueamento. Vendo como taxa de conversão: quem espera desiste, e quem clica e não vê resposta desconfia da marca.

Preciso trocar de hospedagem para ter um site rápido?

Nem sempre, mas vale medir o TTFB antes de qualquer outra coisa. Acima de 500 milissegundos, o problema está na origem, e otimizar imagem só vai maquiar o sintoma.

Dá para ter um site rápido e com personalidade visual?

Dá, e ficou mais fácil neste ano. Com animação por rolagem em CSS, container queries e fontes variáveis, eu consigo movimento e caráter gastando uma fração do peso que gastava em 2023.

O que eu levo desse assunto

Parei de tratar performance como uma etapa de checklist e passei a tratar como restrição criativa, do mesmo jeito que trato formato de papel ou duração de um vídeo. Restrição não empobrece o projeto, ela obriga a escolher. E projeto com escolha clara é o que mais vende.

Se você desconfia que o seu site está bonito e lento, me chame para olhar. Costumo começar medindo os três números e mostrando, na tela, onde o layout está cobrando caro do visitante.