Todos já ouviram falar sobre a importância da performance. Mas, quando falamos sobre performance e sobre tornar os sites "rápidos", o que queremos dizer especificamente?
A verdade é que a performance é relativa:
- Um site pode ser rápido para um usuário (em uma rede rápida com um dispositivo potente), mas lento para outro usuário (em uma rede lenta com um dispositivo de baixo custo).
- Dois sites podem terminar de carregar no mesmo tempo, mas um pode parecer carregar mais rápido (se carregar o conteúdo progressivamente em vez de esperar até o fim para mostrar algo).
- Um site pode parecer carregar rapidamente, mas depois responder lentamente (ou nem mesmo responder) à interação do usuário.
Ao falar sobre performance, é importante ser preciso e se referir à performance em termos de métricas. Critérios objetivos que podem ser medidos quantitativamente, mas também é importante garantir que as métricas que você está medindo sejam úteis.
Como definir métricas
Historicamente, a performance da Web era medida 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 que seja importante para o usuário.
Por exemplo, um servidor pode responder com uma página mínima que "carrega" imediatamente, mas adia a busca de conteúdo ou a exibição de qualquer coisa na página até vários segundos após o evento load ser acionado. Tecnicamente, essa página tem um tempo de carregamento rápido, mas esse tempo não corresponde à experiência do usuário ao carregar a página.
Nos últimos anos, 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 medem 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, elas são estruturadas em torno de algumas perguntas importantes:
| 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? |
| É possível usá-lo? | 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? |
Como as métricas são medidas
As métricas de performance geralmente são medidas de duas maneiras:
- No laboratório:usando ferramentas para simular o carregamento de página em um ambiente consistente e controlado
- No campo: usuários reais carregam e interagem com a página.
Nenhuma dessas opções é necessariamente melhor ou pior do que a outra. Na verdade, é melhor usar as duas para garantir um bom desempenho.
No laboratório
Testar a performance no laboratório é essencial ao desenvolver novos recursos. Antes que os recursos sejam lançados na 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 do recurso é a melhor maneira de evitar regressões de desempenho.
No campo
Por outro lado, embora os testes no laboratório sejam um indicador razoável de desempenho, eles não refletem necessariamente a experiência real dos usuários no seu site.
A performance de um site pode variar bastante com base nos recursos do dispositivo e nas condições de rede do usuário. Ela também pode variar com base na forma como o usuário interage com a página.
Os carregamentos de página também não são sempre determinísticos. Por exemplo, os sites que carregam conteúdo ou anúncios personalizados podem ter características de desempenho muito diferentes de um usuário para outro. Um teste de laboratório não captura essas diferenças.
A única maneira de saber como seu site funciona para os usuários é medir o desempenho dele enquanto os usuários carregam e interagem com ele. Esse tipo de medição é comumente chamado de Monitoramento de usuários reais (RUM).
Tipos de métricas
Há vários outros tipos de métricas relevantes para a percepção dos usuários sobre a performance.
- Velocidade de carregamento percebida:quão rápido uma página pode carregar e renderizar todos os elementos visuais na tela.
- Resposta ao carregamento:quão rápido uma página pode carregar e executar qualquer código JavaScript necessário para que os componentes respondam rapidamente à interação do usuário.
- Resposta no tempo de execução:após o carregamento da página, a rapidez com que ela responde à interação do usuário.
- Estabilidade visual:os elementos na página mudam de forma inesperada para os usuários e podem interferir nas interações?
- Suavidade:as transições e animações são renderizadas com uma taxa de frames consistente e fluem de um estado para o outro?
Considerando todos esses tipos de métricas de performance, fica claro que nenhuma métrica é suficiente para capturar todas as características de performance de uma página.
Métricas importantes
- First Contentful Paint (FCP):mede o tempo entre o início do carregamento da página e o momento em que qualquer parte do conteúdo dela é renderizada na tela. (laboratório, campo)
- Maior exibição de conteúdo (LCP, na sigla em inglês):mede o tempo entre o início do carregamento da página e o momento em que o maior bloco de texto ou elemento de imagem é renderizado na tela. (laboratório, campo)
- Interaction to Next Paint (INP): mede a latência de cada toque, clique ou interação de 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 próxima da mais alta) como um único valor representativo para descrever a capacidade de resposta geral de uma página. (laboratório, campo)
- Tempo total de bloqueio (TBT):mede o tempo total entre a FCP e o TTI em que a linha de execução principal foi bloqueada por tempo suficiente para evitar a capacidade de resposta da entrada. (laboratório)
- Cumulative Layout Shift (CLS):mede a pontuação cumulativa de todas as mudanças de layout inesperadas que ocorrem entre o início do carregamento da página e a mudança do estado do ciclo de vida para "oculto". (laboratório, campo)
- Tempo até o primeiro byte (TTFB): mede 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)
Em alguns casos, novas métricas serão introduzidas para cobrir áreas ausentes, mas em outros casos, as melhores métricas são personalizadas especificamente para seu site.
Métricas personalizadas
As métricas de performance mencionadas anteriormente são boas para entender as características de desempenho da maioria dos sites na Web. Elas também são úteis para ter um conjunto comum de métricas para comparar a performance dos sites com a dos concorrentes.
No entanto, pode haver momentos em que um site específico é único de alguma forma e exige outras métricas para capturar a imagem completa do desempenho. Por exemplo, a métrica LCP tem como objetivo medir 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. Nesse caso, a LCP pode não ser relevante.
Para resolver esses casos, o Grupo de Trabalho de Performance 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 Long Animation Frames
- 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 as características de desempenho específicas do seu site.