Vários estudos mostram que a performance final para o usuário, que ele percebe ao abrir o navegador desktop ou no 3G do mobile depende mais do frontend do que do backend.
Um site rápido leva no máximo 1s para carregar, um site mediano leva entre 1 e 2.5s para carregar e um site lento leva mais de 2.5s para carregar.
Em coverage conseguimos ver todo o css e javascript que não estão sendo utilizados em vermelho.
A performance é calculada a partir de 6 métricas. Cada métrica captura algum aspecto relacionado a velocidade de carregamento. O ideal é foquemos em uma metrica especifica por vez.
É uma métrica do Core Web Vitals (disponíbilidado pelo Google) que menssura o tempo necessário para que o maior elemento seja mostrado em tela.
O tempo ideal para essa métrica é de 1.2s. Para melhorar essa métrica, temos que trabalhar para carregar menos css, javascript e arquivos estáticos como imagens, icones e videos, permitir que o backend retorne apenas os dados necessários/backend lento.
Dispositivos mobile possuem um limite de CPU e memória. 60% da conexão desses dispositivos ao redor do mundo é 2G.
Para olhar essa métrica, é necessário acessar a aba Performance do DevTools do Chrome. Perceba que o elemento que leva mais tempo para renderizar é a imagem do sapato rosa.
CLS (Cumulative Layout Shift) mede a estabilidade visual da página, quantificando mudanças inesperadas de layout que ocorrem durante o carregamento. Ele é importante porque essas mudanças podem prejudicar a experiência do usuário, especialmente quando levam a interações incorretas.
Para observar essa métrica em prática, acessamos a aba Performance do DevTools. Perceba que existe layout shift nela a ponto de deixar a experiencia ruim, pois a métrica está em vermelho. Também é listado quais elementos se moveram durante o carregamento. O ideal é que existam espaços reservados para os elementos renderizaram em tela.
INP (Interaction to Next Paint) é uma métrica dos Core Web Vitals que mede o tempo entre uma interação do usuário e a próxima atualização visual da interface. Ele considera múltiplas interações ao longo da sessão e reporta um valor representativo das piores latências, desconsiderando outliers extremos, sendo um indicador da responsividade percebida da aplicação.
Para observar essa métrica em prática, acessamos a aba Performance do DevTools. Nela, toda vez que realizamos um dos 3 tipos de ação: clique, digitação e toque (mobile) é registrado o tempo de resposta visual em tela na listagem. No exemplo da nossa aplicação, a ação que leva mais tempo para dar um feedback visual é a digitaçao da busca.
Enquanto o LCP mede, de forma geral, o carregamento, o tempo para que o usuário veja as coisas em tela, o INP mede o tempo de interação, isto é, beleza, meu site carregou, mas será que consigo interagir de forma rápida também?
Uma das métricas de performance é o time to interactive, que representa quando os usuários podem de fato interagir com a página e obter uma resposta. Uma long task pode contribuir para um tempo maior a partir do momento que ela "congela" a UI, impedindo com que os usuários possam interagir com ela. Esse processo não deve levar mais que 50ms pois consomem muita CPU. O que podemos fazer é trabalhar para carregar os recursos nos momentos necessários.
-
Diminua a quantidade de cookies e requests da página.
-
Faça o cache de arquivos estáticos.
-
Adie o carregamento do não for necessário para o primeiro carregamento da página e faça de forma assincrona.
-
Diminua o trafego de dados diminuindo o payload do servidor.
-
Habilite o GZIP no servidor para comprimir arquivos html, css e js.
Para observar o valor de cada uma dessas métricas no painel do datadog, basta acessar o módulo RUM (Real User Monitoring) via Digital Experience > Summary OU Digital Experience > Optimization como na imagem abaixo.
