Começando com Performance Web — Métricas
Hey, então você quer um website performático? Show, todos queremos. Mas como começamos?
Implementando melhorias em algoritmos? Tudo com complexidade O(1)?Melhorando o tempo de resposta do nosso backend? Utilizando cache? Nah, nada disso. Precisamos primeiro entender e mensurar as coisas, pra então saber o que melhorar.
Hoje o foco serão as métricas. Pra saber o que melhorar, primeiro precisamos entender o que procurar, e como mensurar pra perceber o impacto. Não queremos falsas otimizações e nem piorar nossa performance.
A idéia é dar uma visão geral, e todas as fontes vão estar no final do artigo. Vale a pena a lida lá eventualmente, é tudo bastante amigável.
Performance Objetiva VS Performance Percebida
Antes de tudo, precisamos entender que não estamos necessariamente falando de Performance Objetiva, até por que, não temos como melhorar a memória RAM, CPU ou conexão de um usuário, mas sim, podemos melhorar como o usuário percebe a performance do nosso website. Isso é a Performance Percebida.
Como as métricas são medidas?
É possível mensurar métricas de duas formas:
Em laboratório (há quem chame de monitoramento sintético), que é fazer as medições em ambiente controlado, usando ferramentas como Lighthouse, WebPageTest, Devtools e etc.
Em campo, que é como o nome sugere, na "natureza selvagem", monitorando usuários reais, utilizando ferramentas como o New Relic por exemplo.
Métricas
Web Vitals
É uma iniciativa do Google que serve como guia de qualidade pra manter nossos websites performáticos, garantindo que entregaremos uma experiencia excelente. São definidas várias métricas e passaremos por todas elas.
Core Web Vitals
São métricas que fazem parte dos Web Vitals, mas que representam facetas distintas da experiencia do usuário (Painting, Interactivity e Visual Stability), são mensuráveis em campo e refletem o mundo real: LCP (Painting), FID (Interactivity), CLS (Visual Stability).
E agora sim, vamos as métricas:
TTFB (Time To First Byte)
É o tempo que demora entre a request de um recurso (no caso a página), e sua resposta. Como sabemos, há diversos passos ocorrendo nesse momento, e quanto mais tempo demorar pra chegar uma resposta, mais tempo demorará para que tudo comece. Não é algo necessariamente crítico, mas pode ser um indicador interessante, como por exemplo que sua página esta levando mais tempo no server do que deveria.
Pode ser medida tanto em laboratório quanto no campo.
A recomendação atual é:
Menor que 800ms é bom
Entre 800ms e 1800ms precisa melhorar
Maior que 1800ms é ruim
FP (First Paint)
Mensura o tempo que o primeiro elemento levou para ser renderizado na tela.
Pode ser medida tanto em laboratório quanto no campo.
A recomendação atual é:
Menor que 1,8s é bom
Entre 1,8s e 3s precisa melhorar
Maior que 3s é ruim
LCP (Largest Contentful paint) [Core Web Vital]
Mensura o tempo que a maior imagem ou bloco de texto visível na tela levou para ser renderizado. É importante notar que o LCP pode mudar, conforme a tela carrega e mais elementos aparecem.
Pode ser medida tanto em laboratório quanto no campo.
A recomendação atual é:
Menor que 2,5s é bom
Entre 2,5s e 4s precisa melhorar
Maior que 4s é ruim
TBT (Total Blocking Time)
Mensura o total de tempo entre o FCP e o TTI (próxima métrica) que a main thread esteve bloqueada por tempo o suficiente pra impedir a capacidade de resposta pra entradas.
Uma task é considerada uma long task e por consequência "bloqueante", caso ela leve mais de 50ms. Somando o excesso de todas as long tasks, temos o TBT.
Dica: 3rd parties costumam atrapalhar essa métrica, justamente por que código terceiro nem sempre é otimizado.
É indicada a medição em laboratório.
A recomendação atual é:
Menor que 200ms é bom
Entre 200ms e 600ms precisa melhorar
Maior que 600ms é ruim
Pra ver um exemplo prático, clique aqui.
TTI (Time To Interactive)
Mensura o tempo que a página leva pra garantir que pode responder a todas as entradas rapidamente. Acabamos de ver o conceito de long tasks e TBT. O TTI buscar garantir que toda long task já passou, então se o usuário tentar interagir com a página, ele obterá rapidamente uma resposta. Quanto menos long tasks e menor o TBT, menor será o TTI.
Como a imagem mostra, após 5 segundos em uma "quiet window" (5 segundos sem long tasks e com não mais que 2 GET requests no network), vai ser obtido em qual tempo terminou a ultima long task. E o TTI é isso.
É indicada a medição em laboratório.
A recomendação atual é:
Menor que 3,8s é bom
Entre 3,9s e 7,3 precisa melhorar
Maior que 7,3 é ruim
FID (First Input Delay) [Core Web Vital]
Aqui temos a segunda Core Web Vital e uma métrica bastante interessante, até por que ele é medida exclusivamente no campo e depende do momento em que o usuário se sente confortável pra interagir com a página.
O FID mensura quanto tempo leva pra que a página possa responder a entrada de um usuário. Logo caso ele interaja no meio de uma long task, a main thread vai precisar terminar essa task pra daí responder a essa interação.
Agora caso o usuário interaja com a página após o TTI, garantidamente a resposta será rápida, já que main thread esta livre.
É indicada a medição em campo.
A recomendação atual é:
Menor que 100ms é bom
Entre 100ms e 300ms precisa melhorar
Maior que 300ms é ruim
Ah, e você vai notar que essa métrica não esta no Lighthouse, até por que como vimos, essa métrica é exclusiva pro campo. Mas ainda assim há algo lá, o Max Potential FID, que é simplesmente qual seria o pior cenário possível pro FID, que no caso é a duração da maior long task. Caso o usuário tentasse interagir justamente enquanto ela ocorre, o browser só responderia depois que a task terminasse.
CLS (Cumulative Layout Shift) [Core Web Vital]
Sabe quando você esta navegando em um website, vai interagir com algo e BOOM, a página inteira se mexeu por que apareceu algo no topo, como uma propaganda por exemplo? Pois é, isso é a falta de estabilidade visual, e é justamente o que o CLS se propõe a mensurar.
Existe alguns cálculos pra isso, mas são basicamente algumas pontuações que vão sendo somadas depois de mudanças inesperadas, levando em consideração o impacto e a distancia delas.
Pode ser medida tanto em laboratório quanto no campo.
A recomendação atual é:
Menor que 0,1 é bom
Entre 0,1 e 0,25 precisa melhorar
Maior que 0,25 é ruim
Performance Budgets
Performance Budget é exatamente o que o nome sugere: você define "budgets" para as métricas e evita ultrapassar isso. Tendo isso definido cedo é ótimo, assim com o tempo e entregas você garante que conforme o tempo for passando as métricas não vão piorando. O que é sempre ótimo.
Conclusão
É isso, métricas são um ótimo pontapé inicial. Sabendo o que olhar, fica muito mais fácil de saber o que melhorar. Espero que no próximo relatório do Lighthouse que você gerar, as coisas fiquem mais claras e boas ideias surjam.
É isso, espero que tenha ajudado com o pontapé inicial. Eventualmente pode (ou não) ter artigos sobre as ferramentas de análise, observabilidade, testes de carga e essas coisas.
See ya.
Fonte: https://web.dev/