Todos nós já ouvimos falar da importância do desempenho. Mas quando falamos sobre desempenho e sobre como tornar os 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 potente) mas lento para outro (em uma rede lenta com um dispositivo simples).
- Dois sites podem terminar de carregar exatamente no mesmo período, mas um parece carregar mais rápido (quando o conteúdo é carregado progressivamente em vez de esperar até o fim para exibir nada).
- Um site pode parecer carregar rapidamente, mas responder lentamente (ou não responder) à interação do usuário.
Quando se trata de desempenho, é importante ter precisão e mencionar o desempenho em termos de metrics. 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
No passado, 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 depois adiar a busca de conteúdo ou a exibição de qualquer item na página até vários segundos após o evento load ser disparado. 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, membros da equipe do Chrome, em colaboração com o Grupo de trabalho de desempenho na Web do W3C, 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, elaboramos algumas perguntas importantes:
| Está acontecendo? | A navegação foi iniciada corretamente? O servidor respondeu? |
| Ela é útil? | Há conteúdo renderizado suficiente para que os usuários possam interagir com ele? |
| É utilizável? | Os usuários conseguem interagir com a página ou ela está ocupada? |
| É agradável? | As interações são suaves e naturais, sem atraso? |
Como as métricas são medidas
Em geral, as métricas de desempenho são avaliadas de duas maneiras:
- No laboratório: Como usar ferramentas para simular o carregamento de uma página em um ambiente consistente e controlado
- Em campo: 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, o ideal é usar ambas para garantir um bom desempenho.
No laboratório
Testar o desempenho no laboratório é essencial ao desenvolver novos recursos. Antes do lançamento dos recursos 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.
Em campo
Por outro lado, embora os testes no laboratório sejam uma representação razoável do desempenho, eles não refletem necessariamente a experiência dos usuários reais com o site.
O desempenho de um site pode variar drasticamente com base nos recursos do dispositivo do usuário e nas condições de rede. Ela também pode variar dependendo de se (ou como) o usuário está interagindo com a página.
Os carregamentos de página nem sempre são 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 captará essas diferenças.
A única maneira de realmente saber o desempenho do seu site para os usuários é medir o desempenho dele à medida que os usuários carregam e interagem com ele. Esse tipo de medição é chamado de monitoramento real do usuário (RUM, na sigla em inglês).
Tipos de métricas
Há vários outros tipos de métricas que são relevantes para a forma como os usuários percebem o desempenho.
- Velocidade de carregamento percebida:a rapidez com que uma página carrega e renderiza 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 com rapidez à interação do usuário.
- Responsividade em tempo de execução:após o carregamento da página, com que rapidez a página pode responder à interação do usuário.
- Estabilidade visual:os elementos na página mudam de maneiras inesperadas e podem interferir nas interações deles?
- Suavidade:as transições e animações são renderizadas em um frame rate consistente e fluem de forma fluida de um estado para o outro?
Considerando todos esses tipos de métricas de desempenho, esperamos que esteja claro que nenhuma métrica única é suficiente para capturar todas as características de desempenho de uma página.
Métricas importantes a serem avaliadas
- 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 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 próxima do valor mais alto) como um valor único e representativo para descrever a capacidade de resposta geral 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 à entrada. (laboratório)
- Cumulative Layout Shift (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 estado do ciclo de vida para oculto. (laboratório, campo)
- Tempo até o primeiro byte (TTFB, na sigla em inglês): 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 são introduzidas para cobrir áreas que faltam. Em outros, as melhores métricas são aquelas personalizadas especificamente para seu site.
Métricas personalizadas
As métricas de desempenho abordadas anteriormente são boas para obter uma compreensão geral das características de desempenho da maioria dos sites da Web. Eles também são bons para ter um conjunto comum de métricas para sites com o objetivo de comparar seu desempenho com o dos concorrentes.
No entanto, às vezes, um site específico é único e precisa de métricas adicionais para abranger todo o desempenho. Por exemplo, o objetivo da métrica de LCP é medir quando o conteúdo principal de uma página terminou de carregar. No entanto, em casos em que o maior elemento não faz parte do conteúdo principal, a LCP pode não ser relevante.
Para lidar com esses casos, o Web Performance Working Group 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 as características de desempenho específicas do seu site.