O custo do seu JavaScript

William Grasel

@willgmbr

Vamos começar entendendo o problema!

Em média sites mobile carregam em

10 segundos!

53% dos usuários abandonam o site se não carregar em

3 segundos!

Sites interativos em menos de 5 segundos têm:

• 70% de sessões mais longas
• 35% menos taxa de rejeição
• 25% mais visibilidade de propagandas

Mães sempre dizem:

Tudo que é demais,

faz mal!

200kb de JPG e JS não significa a mesma coisa!

Para atingir os 5 segundos de interação, 300kb de JS seria o máximo aceitável

Normalmente entregamos MUITO mais que do que isso...

Mas antes de começar a falar de soluções...

Como podemos medir problema?

Para quem não sabe para onde vai qualquer caminho serve

75% de visibilidade do resultado final da página, segmentado através de dispositivos móveis e desktop.

Tempo de respostas das primeiras interações do usuário com os elementos visíveis da sua página.

Impacto da instabilidade da sua página durante o carregamento ao mudar os elementos de tamanho e lugar.

Evolução do Core Web Vitals

https://pagespeed.web.dev/

Performance não deveria ser algo que lembramos apenas quando já estiver tudo explodindo!

O próprio Google usa essas métricas para priorizar seus resultados de buscas

Entendendo o build e carregamento do seu JavaScript!

O que tem no seu bundle afinal?

Tem alguma dependência desnecessária?

Tem alguma dependência com impacto muito maior do que o esperado?

Tree Shaking

nem sempre funciona conforme o esperado...

As vezes é uma questão de importar as mesmas dependências de outra maneira!

Se esse é o resultado final do buld da sua aplicação, você tem um problema...

Lazy load por rotas deveria ser padrão em TODAS as aplicações Web!

Dynamic Imports

Não deixe para carregar na ultima hora!

Mas e esse tal de Server Side Rendering?

Se você precisa maximizar a experiencia do usuário

Já oferecendo algo para seu usuário ler e interagir, antes de carregar o JS...

Melhorando sua indexação e o ranking da sua página no Google

Pré-renderizar suas páginas pode ser uma estratégia importante!

Podendo ser em tempo de build, também conhecido como

Static Site Generation

Ou em tempo de execução, caso precise de uma renderização mais dinâmica!

Praticamente todas as suas métricas de carregamento podem ser melhoradas com SSR

Mas SSR vem com seus próprios desafios!

Primeiro e mais óbvio, temos o custo de infra

Além da complexidade de deploy e aumento de pontos de falha

Tenha certeza que sua página esta sendo reidratada corretamente!

Reaproveitando o DOM criado no servidor, em vez de destruir e criar tudo do zero

O que pode destruir sua métrica de CLS: Cumulative Layout Shift 

Melhores práticas atuais e o que o futuro nos aguarda?

E se o carregamento e reidratação for progressivo / seletivo?

Já da para fazer algo do tipo com SSR e Dynamic Imports

Executar isso manualmente é custoso e complexo em larga escala...

Precisamos que nosso ferramental evolua para que esse tipo de prática seja mais prático e fácil!

React vem direcionando esse problema com

Server Components

Explicitamente dizendo quais partes da sua App nem sequer precisam ser carregadas no navegador

Mas é uma abordagem que te obriga a trabalhar com SSR

Alguns frameworks mais novos vem testado uma abordagem de

Islands Architecture

Dividindo a aplicação naturalmente em áreas menores que possam ser sempre carregadas independentemente

Isso pode lembrar MFE para alguns, mas tem objetivos e implicações distintas

MFE vem resolver um problema organizacional de grandes times trabalhando em uma mesma aplicação

Islands Architecture vem resolver um problema técnico de carregamento

E como tudo que é bom na vida se copia...

Alguns frameworks grandes já estão copiando algumas dessas ideias!

Mas nem todo mundo está contente com a ideia de "reidratação"

Você não precisa sair daqui usando em produção esses novos frameworks

A não ser que tenha algum caso de uso com requisito extremo de performance!

Deixemos que os padrões surjam, se provem e sejam copiados!

Resumindo!

Evite carregar mais do que 300kb de JS no primeiro carregamento e em cada rota

Faça Lazy Loading por padrão nas rotas de todas as suas WebApps!

Use Core Web Vitals integrando o Lighthouse em sua CI

Use SSR quando realmente fizer sentido na sua aplicação!

Fique de olho no futuro e nas melhores práticas, mas sem ser arrastado por hypes!