Azion JAMStack LCP Performance — melhora dos 2.8s para casa dos 400/600ms
No artigo anterior fala sobre como foi a Introdução Azion JAM Stack onde recomendo para introdutório deste.
Aqui voce irá ler um pouco dos resultados das small actions para otimizar a quantidade de recursos utilizados pela página, consequentemente melhorando expressivamente o tempo de carregamento das mais de 900 páginas que temos a baixo de https://www.azion.com/ .
Temos 4 sistemas separados respondendo para nosso domínio principal, cada um com suporte i18n configurado para 3 idiomas: português, inglês, espanhol;
- Blog
- Casos de Sucesso
- Documentação
- Landing Pages (marketing)
Apensar de serem projetos separados, todos utilizam os mesmos recursos que estão abaixo de https://assets.azion.com/static/
Relação SSG com LCP
Com a adoção do SSG no cenário Front-End vem também alguns ms a menos na hora de carregar a página. O que quero dizer com isso?
LCP — Largest Contentful Paint. É uma métrica voltada para o usuário para mensurar a percepção de load speed.
Com o SSG podemos montar grade parte do conteúdo da página em tempo de build, não temos mais aquele tempo do processamento da requisição.
Métrica LCP calcula o tempo de renderização do maior conteúdo/imagem mostrado na tela para visualização em relação a quando a página começou ser carregada.
Sobre o indicado para métricas, a baixo temos o recomendado
Temos que ter cuidado quando falamos em performance pois a percepção do usuário pode ser diferentes do que realmente é mensurado, fazendo um site que pode ter um tempo maior parecer mais rápido apenas por trabalhar na percepção de usuário.
Nunca me esqueço da frase:
> Percepção de usuário é performance. — Guilherme Moser, Terra Networks.
Qual trabalho foi feito para alcançar os resultados?
Em uma rápida análise podemos ver que tinha algo errado, preste atenção na imagem abaixo:
- Na faixa azul da aba network, podemos ver que temos um CSS de 2.0mb;
- Na faixa vermelha do coverage podemos ver 2 045 425 bytes de css sendo que 2 021 783 não utilizados, isso é 98.8% de processamento e tráfego desnecessário.
Por mais que temos a possiblidade de fazer cache no browser, jogar a responsabilidade toda para cima dele seria uma irresponsabilidade, pois acarretaria em outros problemas, como um simples e constante deploy com constante refresh de cache prejudicaria não só o LCP mas como TTFB, TBT, TTI entre outros.
Bom, olhando para esse cenário com certeza precisávamos atualizar essa estrutura urgente, pois pelo fato de ser um site baseado em JAM Stack não poderíamos aceitar aquele péssimo desempenho de performance.
Mãos ao trabalho
O trabalho basicamente foi quebrar o CSS. Veja nas imagens abaixo o que tinhamos:
Nossa primeira versão de site contava com esse compilado de CSS para todas as páginas.
Iniciamos transformando o que estava em ./pages/_file.scss para ./pages/_page.scss assim automaticamente na hora do Jekyll compilar não precisaria alterar destino nem alterar código.
Com isso cada arquivo que não possui _ (usado por default no sass) para quando usar como import e não output, ao compilar geraria 1 para 1 em relação arquivo/output.
O que passou de apenas um bundle.css imenso de 2.0mb para vários arquivos menores, no qual mais ou menos cada um tem 100k. (ainda sem contar gzip)
Mas e os arquivos compartilhamos? Foi testado arquivo por arquivo para ver o que era realmente necessário ou não, e com isso chegamos ao compilado para fazer shared em todas as páginas:
Bem menor né? Esse é o arquivo final de recursos compartilhados onde cara página interna vai usar algo como:
Em uma das páginas com maior número de componentes ficou com aproximadamente 90k após compilado.
Integrando com o HTML
Para quem usa ferramentas de SSG está acostumado a configurar Front-Matters, as ferramentas utilizam esse tipo de marcação ao topo do arquivo para dizer como o conteúdo deve ser compilado.
Com isso apenas fizemos pequenas mudanças nas nossas páginas.
Passamos de um header nas páginas HTML que continham tudo que precisava
para:
Agora, esse estilo irá vir da configuração do Front-Matter que será atualizado durante o build. Algo como:
Podemos ver que utilizamos o máximo dos recursos já utilizados com sutil alteração onde nos proporcionou enormes ganhos.
Quais foram os resultados?
No primeiro momento tinhamos esse tipo de resultado."
No novo modelo chegamos a ter mais de 70% de melhoria:
Ambos os testes eram para a página, https://www.azion.com/pt-br/
Benchmark
- Melhora de LCP de: 2.1s para 1.3s;
- Melhora de First Byte de: 0.256s para 0.18s;
- Melhora de Start Render de: 1.9s para 0.6s;
- Melhora de First Contentful Paint de: 1.8s para 0.63s;
- Melhora de Speed Index de: 2s para 0.7s;
Para mais resultados pode ser olhado diretamente nos testes.
Novidades em breve
Ao que tudo indica, a importancia da arquitetura JAMStack está cada vez mais consolidado.
A partir de junho um rollout irá começa ocorrer onde LCP, FID e CLS montam o novo sinal do ranking do Google “Page Experience”.
