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 fim para exibir algo).
- Um site pode parecer carregar rapidamente, mas depois responder lentamente (ou não responder) à interação do usuário.
Portanto, ao falar sobre performance, é importante ser preciso e se referir a ela em termos de critérios objetivos que possam ser medidos de forma quantitativa. Esses critérios são conhecidos como metrics.
Mas só porque uma métrica é baseada em critérios objetivos e pode ser medida quantitativamente, não significa necessariamente que elas sejam úteis.
Como definir métricas
Antes, 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 adia a busca de conteúdo e exibe tudo na página até
alguns segundos após o disparo do evento load. Tecnicamente, essa página pode ter um tempo de carregamento rápido, mas esse tempo não corresponde à experiência real do usuário com o carregamento da página.
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 do que a outra. Na verdade, convém usar ambas 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 uma representação razoável do desempenho, eles não necessariamente refletem a experiência de todos os usuários no seu site.
O desempenho de um site pode variar drasticamente com base nos recursos do dispositivo do usuário e nas condições da rede. Ele também pode variar de acordo com a interação (ou como) do usuário com a página.
Além disso, os carregamentos de página podem não ser 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 os usuários carregam e interagem com ele. Esse tipo de medição é comumente chamado de monitoramento real do usuário (ou RUM).
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 em tempo de execução:após o carregamento da página, a velocidade com que a página pode responder à interação do usuário.
- Estabilidade visual:os elementos da página mudam de maneira que os usuários não esperam e podem interferir 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 os tipos de métricas de desempenho acima, é 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):mede o tempo entre o início do carregamento da página e a renderização de qualquer parte do conteúdo na tela. (laboratório, campo)
- Maior exibição de conteúdo (LCP, na sigla em inglês):mede o tempo entre o carregamento da página e o momento em que o maior bloco de texto ou elemento de imagem é renderizado na tela. (laboratório, campo)
- Latência na primeira entrada (FID, na sigla em inglês):mede o tempo entre o momento em que um usuário interage com o site pela primeira vez (clica em um link, toca em um botão ou usa um controle personalizado com tecnologia JavaScript) até o momento em que o navegador consegue responder a essa interação. (campo)
- Interaction to Next Paint (INP): mede a latência de cada toque, clique ou interação do teclado feita com a página e, com base no número de interações, seleciona a pior latência de interação da página (ou quase a mais alta) como um valor único e representativo para descrever a capacidade geral de resposta de uma página. (laboratório, campo)
- Tempo total de bloqueio (TBT, na sigla em inglês):mede o tempo total entre a FCP e o TTI em que a linha de execução principal ficou bloqueada por tempo suficiente para impedir a capacidade de resposta da entrada. (laboratório)
- Mudança de layout cumulativa (CLS, na sigla em inglês):mede a pontuação cumulativa de todas as mudanças inesperadas de layout que ocorrem 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, na sigla em inglês): mede o tempo que leva para a rede 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 do 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 cobertas no momento.
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 acima são úteis para entender melhor 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 que os sites comparem a performance com a concorrência.
No entanto, às vezes um site específico é único e exige mais métricas para que você entenda o cenário 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 e, portanto, a LCP pode não ser relevante.
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 sobre Métricas personalizadas para saber como usar essas APIs para medir características de desempenho específicas do seu site.