As métricas de desempenho evoluem. Os Core Web Vitals foram introduzidos em 2020. Substituíram métricas mais antigas (FCP, FID). Daqui a cinco anos, novas métricas vão substituir os Core Web Vitals.
As métricas futuras vão medir: o carregamento da IA (quanto tempo até as funcionalidades de IA responderem), a capacidade de resposta em tempo real (quanto tempo até as respostas em streaming aparecerem), o desempenho percebido pelo utilizador (como a página se sente, não só as métricas técnicas).
A pergunta para já: como nos preparamos para métricas futuras sem sabermos quais são. Resposta: mede o que importa para o teu negócio. Os Core Web Vitals medem a experiência geral do utilizador. As métricas personalizadas medem resultados específicos do negócio. Prepara o futuro construindo flexibilidade nos sistemas de medição.
Acompanhar a evolução das métricas
Os Core Web Vitals são o padrão atual. Mas não são permanentes.
Cronologia:
- 2020: introdução dos Core Web Vitals (LCP, CLS, FID)
- 2022: o FID é substituído pelo INP (métrica de capacidade de resposta refinada)
- 2024: discussão sobre as métricas seguintes (tempo de espera de interação, tempo de resposta em streaming)
- Futuro: surgem novas métricas
Padrão: quando a tecnologia muda, as métricas mudam. Quando as páginas se tornaram interativas, as métricas de interação (INP) passaram a ser importantes. À medida que a integração de IA se torna comum, o tempo de resposta da IA pode tornar-se uma métrica importante.
Lição: foca-te nos princípios (o utilizador percebe uma página rápida, reativa e estável), não nas métricas em si. Os princípios são estáveis, mesmo quando as métricas mudam.
IA e desempenho em tempo real
As funcionalidades de IA estão a tornar-se comuns. Um chatbot num website demora dois segundos a responder. O utilizador espera mais rapidez.
Métrica emergente: tempo de resposta da IA (tempo desde a pergunta do utilizador até ao primeiro token da resposta da IA).
Exemplo: chatbot de apoio ao cliente numa página de suporte. O utilizador faz uma pergunta. O chatbot demora dois segundos a devolver o primeiro token da resposta. Perceção do utilizador: o chatbot é lento, não responde.
Otimização: resposta em streaming. Devolver o primeiro token em quinhentos milissegundos, enviar o resto da resposta em streaming. O utilizador percebe a resposta como instantânea, mesmo que a resposta completa demore dois segundos.
Métrica futura: medir o tempo até ao primeiro token (TTF), não o tempo total de resposta. Um TTF abaixo de quinhentos milissegundos é bom.
Exemplo real: um SaaS com assistente de IA integrado.
Experiência atual do utilizador:
- O utilizador clica no ícone do assistente
- O assistente demora um vírgula cinco segundos a aparecer
- O utilizador espera, sente lentidão
- A experiência de chat parece lenta
Otimização futura:
- O utilizador clica no ícone do assistente
- O ícone anima de imediato (feedback instantâneo, cem milissegundos)
- A janela de chat abre (duzentos milissegundos)
- Aparece a primeira resposta da IA (quinhentos milissegundos)
- O resto da resposta da IA chega em streaming (um a dois segundos)
Perceção do utilizador: resposta instantânea (a animação e a abertura da janela são visíveis de imediato).
Edge computing e desempenho distribuído
O edge computing aproxima o processamento dos utilizadores. O servidor passou de Nova Iorque para um ponto de presença em Los Angeles. O TTFB melhora de forma drástica.
Futuro: o processamento acontece na periferia da rede. A geração do HTML acontece na periferia. A execução do JavaScript acontece na periferia. As consultas à base de dados são distribuídas pela periferia.
Impacto nas métricas: o TTFB torna-se desprezável (a latência de rede aproxima-se de zero). O LCP depende do desenho da página, não da resposta do servidor.
Foco futuro de otimização: desempenho de desenho, não desempenho de resposta do servidor.
Exemplo: uma futura página inicial alimentada pela periferia da rede.
Estado atual:
- TTFB: duzentos milissegundos (servidor em Nova Iorque, utilizador em Los Angeles)
- LCP: dois segundos (LCP = TTFB + tempo de desenho)
Estado futuro (edge computing):
- TTFB: vinte milissegundos (servidor no ponto de presença de Los Angeles)
- LCP: um vírgula cinco segundos (o tempo de desenho é o ponto de estrangulamento, não a resposta do servidor)
Otimização: melhorar o desempenho de desenho (CSS, JavaScript) passa a ser mais importante do que melhorar a resposta do servidor.
Desempenho percebido pelo utilizador e métricas subjetivas
Métricas objetivas: o LCP é de dois segundos (mensurável, objetivo).
Métricas subjetivas: a página parece reativa (subjetivo, percebido).
A investigação mostra: uma página que parece reativa pode ter as mesmas métricas técnicas de uma página que parece lenta. A diferença está na animação, no feedback visual e no carregamento percebido.
Métrica futura: reatividade percebida. Medir a perceção do utilizador, não só a métrica técnica.
Exemplo: duas páginas com o mesmo LCP (dois segundos).
Página um: carrega de imediato uma página em branco e o conteúdo aparece aos dois segundos. O utilizador sente lentidão.
Página dois: mostra de imediato um ecrã esqueleto (duzentos milissegundos) e preenche o conteúdo aos poucos até aos dois segundos. O utilizador sente-a mais rápida (o ecrã esqueleto cria a ilusão de um carregamento mais rápido).
Métricas técnicas (LCP): iguais nas duas (dois segundos).
Perceção do utilizador: a página dois parece mais rápida.
Métrica futura: pontuação de perceção do utilizador (medir a experiência subjetiva a par das métricas técnicas).
Streaming e desenho progressivo
Abordagem atual: desenhar a página inteira e enviá-la ao cliente. O cliente desenha a página. A página fica interativa.
Abordagem com streaming: enviar partes da página à medida que são desenhadas. O cliente recebe e desenha as partes progressivamente. A página fica parcialmente interativa antes de estar totalmente carregada.
Impacto: uma página que demora dois segundos a carregar por completo pode ficar interativa em zero vírgula cinco segundos com streaming.
Métrica futura: tempo até à interatividade (TTI). Quanto tempo até o utilizador poder interagir com a página.
Exemplo: página de produto com recomendações.
Abordagem atual:
- O HTML carrega (zero vírgula cinco segundos)
- O CSS carrega (zero vírgula três segundos)
- O JavaScript carrega (zero vírgula cinco segundos)
- Chamada à API das recomendações (um segundo)
- A página fica interativa aos dois vírgula três segundos
Abordagem com streaming:
- O HTML chega em streaming (zero vírgula um segundos) - a estrutura da página fica visível
- O CSS chega em streaming (zero vírgula dois segundos) - a página fica com estilo
- O JavaScript chega em streaming (zero vírgula três segundos) - a página fica interativa
- A chamada à API das recomendações continua em segundo plano
- A página fica interativa aos zero vírgula cinco segundos
- As recomendações aparecem a partir de um segundo
O utilizador pode interagir (adicionar ao carrinho, clicar em botões) aos zero vírgula cinco segundos. O conteúdo completo aparece a partir de um segundo.
Métrica futura (TTI): zero vírgula cinco segundos (contra dois vírgula três segundos). Uma enorme melhoria na perceção do utilizador.
Perguntas frequentes
Devemos começar já a medir o tempo de resposta da IA?
Sim, se o teu site tem funcionalidades de IA. Mede o tempo até ao primeiro token. Acompanha todos os dias. Define objetivos (abaixo de quinhentos milissegundos é bom). Prepara-te para um futuro em que esta passa a ser uma métrica padrão. Mesmo que ainda não seja uma métrica oficial, medir o que importa aos teus utilizadores prepara-te para o futuro. Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
Como nos preparamos para métricas de desempenho futuras que ainda não conhecemos?
Constrói um sistema de medição flexível. Mede os Core Web Vitals (o padrão atual). Mede também métricas personalizadas (o que importa para o teu negócio). Quando surgirem métricas futuras, podes juntá-las às existentes. A flexibilidade é a chave.
Devemos investir em edge computing para o desempenho?
Sim, se tens utilizadores em todo o mundo. O edge computing reduz o TTFB de forma drástica (a latência de rede desaparece). Vale o investimento. Se os teus utilizadores estão concentrados numa só zona geográfica, uma CDN chega. O público global beneficia do edge computing.
Como medimos o desempenho percebido pelo utilizador?
Inquire os utilizadores. Pergunta: a página parece rápida, reativa, estável. Compara os resultados do inquérito com as métricas técnicas. Podes descobrir que os utilizadores sentem a página mais rápida, mesmo com as mesmas métricas técnicas. Usa o feedback para orientar o design (acrescenta ecrãs esqueleto, animações, feedback visual).
O tempo até à interatividade (TTI) está a tornar-se a nova métrica padrão?
Possivelmente. O TTI é mais significativo do que o LCP em páginas interativas (o utilizador pode agir antes de a página carregar por completo). Mas, por agora, os Core Web Vitals (LCP, CLS, INP) são o padrão. O TTI está a surgir, mas ainda não é oficial. Acompanha os dois.
Como nos mantemos atualizados sobre novas métricas e padrões de desempenho?
Segue as fontes oficiais: as novidades de desempenho do Google, o blogue Web.dev, os grupos de normalização do W3C. Segue o setor: revistas especializadas em web, blogues de ferramentas de teste de desempenho, palestras de conferências de engenharia. As novas métricas surgem por estes canais. Mantém-te informado. Adota cedo quando um novo padrão se tornar relevante para o teu site.