Todos nós sabemos da importância do desempenho. Mas quando falamos em desempenho e em tornar sites "rápidos", o que queremos dizer especificamente?
A verdade é que o desempenho é relativo:
- Um site pode ser rápido para um usuário (em uma rede rápida com um dispositivo avançado), mas lento para outro (em uma rede lenta com um dispositivo de baixo custo).
- Dois sites podem terminar o carregamento exatamente no mesmo período, mas um deles parece carregar mais rápido se o conteúdo for carregado progressivamente, em vez de esperar até o final para mostrar algo.
- O site pode parecer carregar rapidamente, mas depois responder lentamente ou não responder à interação do usuário.
Quando se trata de desempenho, é importante ter precisão e se referir ao desempenho em termos de metrics, critérios objetivos que podem ser medidos de maneira quantitativa. Mas também é importante garantir que as métricas medidas sejam úteis.
Métricas
Historicamente, o desempenho na Web era medido com o evento
load. No entanto, embora load seja um momento bem definido no
ciclo de vida de uma página, esse momento não corresponde necessariamente a algo importante
para o usuário.
Por exemplo, um servidor pode responder com uma página mínima que é "carregada" imediatamente, mas depois adia a busca de conteúdo ou a exibição de qualquer item na página até vários segundos após o disparo do evento load. Tecnicamente, essa página tem
um tempo de carregamento rápido, mas esse tempo não corresponde à experiência do usuário com o
carregamento.
Nos últimos anos, os membros da equipe do Chrome, em colaboração com o W3C Web Performance Working Group, trabalharam para padronizar um conjunto de novas APIs e métricas que avaliam com mais precisão a experiência dos usuários com o desempenho de uma página da Web.
Para garantir que as métricas sejam relevantes para os usuários, nós as enquadramos em algumas perguntas-chave:
| Isso está acontecendo? | A navegação foi iniciada? O servidor respondeu? |
| É útil? | O conteúdo renderizado é suficiente para que os usuários possam interagir com ele? |
| É utilizável? | Os usuários podem interagir com a página ou ela está ocupada? |
| É agradável? | As interações são suaves e naturais, sem atrasos e instabilidades? |
Como as métricas são medidas
As métricas de desempenho geralmente são medidas de duas maneiras:
- No laboratório:uso de ferramentas para simular o carregamento de página em um ambiente consistente e controlado
- Em campo: com usuários reais que carregam e interagem com a página
Nenhuma dessas opções é necessariamente melhor ou pior que a outra. Na verdade, geralmente, convém usar ambos para garantir um bom desempenho.
No laboratório
Testar o desempenho no laboratório é essencial para desenvolver novos recursos. Antes de lançar os recursos para produção, é impossível medir as características de desempenho deles em usuários reais. Portanto, testá-los no laboratório antes do lançamento é a melhor maneira de evitar regressões de desempenho.
Em campo
Por outro lado, embora os testes no laboratório sejam bons indicadores de desempenho, eles não necessariamente refletem a experiência de todos os usuários no seu site.
A performance de um site pode variar drasticamente com base nos recursos do dispositivo e nas condições da rede do usuário. Ele também pode variar de acordo com a interação (ou como) do usuário com a página.
Os carregamentos de página nem sempre são determinísticos. Por exemplo, sites que carregam anúncios ou conteúdos personalizados podem ter características de desempenho muito diferentes de um usuário para outro. Um teste de laboratório não capturará essas diferenças.
A única maneira de saber de verdade o desempenho do seu site para os usuários é medir a performance dele à medida que esses usuários carregam e interagem com ele. Esse tipo de medição é comumente chamado de Monitoramento de usuários reais (RUM, na sigla em inglês).
Tipos de métricas
Há vários outros tipos de métricas relevantes para a forma como os usuários percebem a performance:
- Velocidade de carregamento percebida:a velocidade com que uma página pode carregar e renderizar todos os elementos visuais na tela.
- Capacidade de resposta do carregamento:a rapidez com que uma página pode carregar e executar qualquer código JavaScript necessário para que os componentes respondam rapidamente à interação do usuário.
- Capacidade de resposta no tempo de execução:a rapidez com que uma página pode responder à interação do usuário após o carregamento.
- Estabilidade visual:os elementos da página mudam de maneiras que os usuários não esperam, possivelmente interferindo nas interações?
- Suavidade:as transições e animações são renderizadas a uma taxa de frames consistente e fluem de maneira fluida de um estado para o próximo?
Considerando todos esses tipos de métricas de desempenho, é esperado que nenhuma métrica seja suficiente para capturar todas as características de desempenho de uma página.
Métricas importantes a serem avaliadas
- Primeira exibição de conteúdo (FCP, na sigla em inglês)
- É o tempo entre o início do carregamento da página e a renderização de qualquer parte do conteúdo dela na tela. (laboratório, campo)
- Maior exibição de conteúdo (LCP)
- É o período entre o início do carregamento da página e a renderização do maior bloco de texto ou elemento de imagem na tela. (laboratório, campo)
- Interação com a próxima exibição (INP)
- A latência de cada toque, clique ou interação do teclado feita com a página. Com base no número de interações, essa métrica seleciona a pior (ou próxima) latência de interação da página como um valor único e representativo para descrever a capacidade de resposta geral dela. (laboratório, campo)
- Tempo total de bloqueio (TBT)
- O tempo total entre a FCP e o Time to Interactive (TTI) em que a linha de execução principal ficou bloqueada por tempo suficiente para evitar a capacidade de resposta da entrada. (laboratório)
- Mudança de layout cumulativa (CLS)
- A pontuação cumulativa de todas as mudanças inesperadas de layout que acontecem entre o início do carregamento da página e o momento em que o estado do ciclo de vida muda para oculto. (laboratório, campo)
- Tempo para primeiro byte (TTFB)
- O tempo que a rede leva para responder a uma solicitação do usuário com o primeiro byte de um recurso. (laboratório, campo)
Essa lista inclui métricas que medem muitos dos vários aspectos de desempenho relevantes para os usuários, mas não inclui tudo. Por exemplo, a capacidade de resposta e a suavidade no momento da execução não são abordadas.
Em alguns casos, novas métricas são introduzidas para cobrir áreas que estão faltando. Em outros, as melhores métricas são personalizadas especificamente para seu site.
Métricas personalizadas
As métricas de desempenho listadas aqui são úteis para compreender de maneira geral as características de desempenho da maioria dos sites na Web. Elas também são boas para ter um conjunto comum de métricas para os sites compararem a performance com a da concorrência.
No entanto, há momentos em que um site específico é único de alguma forma e isso exige mais métricas para capturar o quadro completo da performance. Por exemplo, a métrica da LCP mede quando o conteúdo principal de uma página termina de carregar, mas pode haver casos em que o maior elemento não faz parte do conteúdo principal da página, tornando a LCP irrelevante.
Para lidar com esses casos, o grupo de trabalho de desempenho da Web também padronizou APIs de nível inferior que podem ser úteis para implementar suas próprias métricas personalizadas:
- API User Timing
- API Long Tasks
- API Element Timing
- API Navigation Timing
- API Resource Timing
- Tempo do servidor
Consulte o guia Métricas personalizadas e saiba como usar essas APIs para medir características de desempenho específicas do seu site.