William Grasel PRO
Desenvolvedor Web, Google Developer Expert, Microsoft Most Valuable Professional, palestrante, consultor e coordenador do AngularSP.
O custo do seu JavaScript
William Grasel
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 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
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!
Referências
- The Cost Of JavaScript In 2018 – Addy Osmani
- The Cost Of JavaScript In 2023 – Addy Osmani
- Performance Implications of Application Architecture - IO'19
- Rendering Patterns - patterns.dev
- Islands Architecture - JASON Format
- Hydration is Pure Overhead - builder.io
- Partial Hydration - React
- Partial Hydration - Gatsby
- RFC: Deferred Loading - Angular
- Deliver instant apps at scale - Qwik
Obrigado! =)
O custo do seu JavaScript
By William Grasel
O custo do seu JavaScript
À medida que criamos sites que dependem mais fortemente do JavaScript, às vezes pagamos pelo que enviamos de maneiras que nem sempre podemos ver facilmente. E na maioria das vezes o JavaScript é o recurso mais caro que seu site usa atualmente, especialmente em computadores móveis e de baixo custo. Vamos entender e corrigir problemas de desempenho do JavaScript para que tudo carregue mais rapidamente.
