Se pensarmos num site como um restaurante, a sala é o frontend: as mesas, a luz, a forma como o prato é apresentado; a cozinha é o backend: os servidores, a base de dados, o código que corre nos bastidores. A sala trata da impressão, a cozinha decide se a comida chega, e a que horas, e por mais cuidada que seja a sala, uma cozinha lenta faz o cliente esperar, e é este quem avalia.

Métricas do Google

Os Core Web Vitals são três métricas, em que cada uma corresponde a uma parte da experiência do utilizador:

• O LCP (Largest Contentful Paint) mede o tempo até o conteúdo principal aparecer (o momento em que o prato chega à mesa).
• O INP (Interaction to Next Paint) mede a rapidez com que a página responde às interações do utilizador, como um clique ou um toque.
• O CLS (Cumulative Layout Shift) mede a estabilidade visual, se os elementos saltam enquanto a página carrega.

Há, porém, um ponto que condiciona toda a estratégia: o Google avalia a partir de utilizadores reais do Google Chrome ao longo de uma janela de 28 dias. Fixa-se no percentil 75 ou seja, na experiência dos utilizadores mais lentos, e não numa média. É por isso que as decisões de backend pesam tanto, afetam todos os pedidos, e não apenas o ambiente de teste.

Tudo começa no servidor

Antes de qualquer conteúdo ser disponibilizado há um intervalo de tempo entre quando o pedido é realizado e o browser que espera pela primeira resposta. A este intervalo de tempo se chama TTFB (Time to First Byte), e a recomendação é mantê-lo abaixo dos 800 milissegundos. Este processo é decisivo porque o TTFB é a primeira fatia do LCP.

Um TTFB alto é quase sempre uma de duas coisas: a primeira é a base de dados, quando a aplicação faz dezenas de consultas pequenas em vez de uma (como pedir ao cozinheiro para ir à despensa uma vez por cada ingrediente que precisar); a segunda é a falta de caching, ou seja, guardar respostas já preparadas em vez de as recalcular a cada pedido.

Temos ainda a renderização que consiste em entregar uma página quase pronta a mostrar, pelo servidor (bom para o LCP, mas exige caching). Fazê-la no cliente alivia o servidor, mas obriga a mais tempo de espera no browser, contudo, não há opção melhor em concreto. Existe a certa para cada página.

Interações, estabilidade e SEO

O INP e o CLS estão sobretudo do frontend, uma interação, uma pesquisa, um filtro, um artigo atirado para o carrinho, depende quase sempre de uma resposta do servidor. Se essa resposta demora, a página torna-se lenta por muito ágil que o frontend seja, e uma resposta demasiado grande tem o mesmo efeito, ao obrigar o browser a processar mais do que precisa.

No SEO técnico, o backend é decisivo, antes de posicionar seja o que for, pois o Google tem de conseguir ler a página, e quem manda nessa leitura é o servidor. Um servidor lento, ou cheio de erros, faz o bot desistir mais cedo e visitar menos páginas: é o chamado crawl budget.

O que muda com o AI

Existe uma métrica nova para levar tudo isto ainda mais a sério: as respostas geradas por IA leem a estrutura da página para decidir se a citam. Um backend que entrega HTML limpo e rápido deixou de ser só desempenho, é agora visibilidade.

A sala continua a ser muito importante, mas é a cozinha quem ordena e que determina o que se consegue servir, e a que velocidade.