Thread by @joaocunha

Seguindo a moda do momento:

1 RT = 1 dica de Performance ⚡️

1. O @SpeedCurve foi a melhor ferramenta que encontrei para ajudar a criar uma cultura de performance através de monitoramento. Ele te dá os insights, aponta quais são os principais problemas de forma automatizada - e ainda compara com os concorrentes.

2. Às vezes a melhor estratégia de font-loading é não carregar nenhuma fonte: o tal "System Font Stack". Apple = San Francisco, Linux = Ubuntu, Android = Robot, Windows = Segoe UI e por aí vai. Experiência nativa pra todo mundo.

3. Animações são um excelente recurso para ganhar tempo enquanto se carrega algo. Esse conceito se chama "Espera Ativa" e eu falo mais sobre ele em minha talk sobre Psicologia da Performance: eventials.com/Globalcode/tdc… (pule pra 15:30) - Foto: Round App

4. Use ferramentas como o Request Map Generator do @simonhearne para auditar os scripts de terceiros (analytics, ads, etc) do seu site. Na imagem, o mapa de requisições do UOL.

👉 requestmap.webperf.tools

5. A Performance também é uma ferramenta de ética e acessibilidade. Temos o privilégio de acessar a web através de conexões rápidas e ilimitadas mas essa não é a realidade da maioria. O YouTube alcançou novas populações inteiras quando ficou mais leve: blog.chriszacharias.com/page-weight-ma…

6. Use os Resource Hints para pré-carregar assets ou "aquecer" a conexão em background. O `dns-prefetch` faz um lookup no DNS, o `prefetch` carrega um asset, o `preconnect` faz o handshake e o `preload` carrega a página de destino inteira.

👉 medium.com/reloading/prel…

7. Siga minha lista de especialistas em Performance na Web pra se manter em dia twitter.com/joaocunha/list… 💪🧠

8. Com o Size Limit dá pra saber quais libs são as "big offenders" no tamanho total do seu bundle JS. Dá até pra colocar no seu pipeline de CI (Jenkins, Travis, etc.) para dar erro quando passar de um certo limite.

github.com/ai/size-limit

9. Defina um Performance Budget. Pode parecer contraproducente no início, mas ele vai ajudar a definir de maneira clara o que incluir e o que remover do seu stack ou de 3rd-party scripts.

👉 medium.com/@addyosmani/st…

10. Conheça as principais métricas de performance de renderização: FCP, FMP, TTI, FID e outras siglas são muito importantes e precisam ser acompanhadas de perto.

👉 speedcurve.com/blog/rendering…

11. 100KB de JS "pesam" até 100x mais que 100KB de uma imagem. Enquanto uma imagem precisa passar por processos de decode, rasterize e paint (processos rápidos), o JS passa por parse, compile e execute que são muito mais custosos.

12. Ainda sobre o JS, o tempo de processamento num celular mediano (Moto G4) é SEIS VEZES MAIOR que num iPhone 8. Num celular de entrada (Alcatel 1X), é VINTE E UMA VEZES MAIOR. Saiam da bolha pessoal na hora de testar a usabilidade ✌️

(imagem: @addyosmani)

13. Na hora de testar, levem em conta quem usa seu produto. Priorizem os perfis de usuários e usuárias mais populares.

Só acessar no Google Analytics:
Público → Dispositivos Móveis → Dispositivos

Vocês verão uma lista parecida com essa 👇

14. Sabe quando você clica no "like" aqui no Twitter? A resposta visual aparece antes mesmo de a API ser consultada (teste nesse tweet!). Trabalhe como se tudo fosse dar certo, removendo estados intermediários - o nome desse conceito é "Optimistic UI".

👉 smashingmagazine.com/2016/11/true-l…

15. Siga o padrão PRPL:

- "Push" os recursos críticos para a rota da URL inicial
- "Render" a rota inicial
- "Pre-cache" as outras rotas
- "Lazy-load" o resto e crie rotas restantes on-demand

👉 developers.google.com/web/fundamenta…

16. Já que é tudo sigla nessa bagaça, aproveite pra seguir o modelo RAIL de performance:

- Response (feedback em menos 100ms)
- Animation (60fps = 16ms por frame)
- Idle (estado intermediário, blocos de 50ms)
- Load (FMP o mais rápido possível)

👉 smashingmagazine.com/2015/10/rail-u…

17. Use Tree shaking para eliminar dead code da aplicação. Todos os module bundlers populares (Webpack, Parcel, Rollup, etc) já oferecem essa feature.

👉 developers.google.com/web/fundamenta…

18. Ative o Scope Hoisting no Webpack. Ele vai identificar cadeias de imports que podem ser convertidas em uma função inline sem comprometer o código.

👉 medium.com/webpack/brief-…

19. Faça Code Splitting do seu bundle. A "regra de ouro" era minificar tudo em um único arquivo JS, mas isso está longe de ser ideal. Envie o que a pessoa precisa *apenas quando ela precisa*. Isso é feito através de Dynamic Importing: olha a promise.

👉 hackernoon.com/lessons-learne…

20. Da mesma forma que você pode fazer Tree Shaking no JS, você pode usar ferramentas como o UnCSS para remover seletores CSS que não são utilizados, algo muito comum em bases de código grandes ou em component libraries.

👇

github.com/uncss/uncss

21. Falando em CSS, aí vai uma 🔥 P0L3M1K4: otimizar seletores CSS *pensando em performance* é inútil. Não dá pra prever o impacto porque o engine do browser reorganiza, divide, coleta e compila os seletores de maneira imprevisível.

👉 benfrain.com/css-performanc…

22. "Minha nossa, João, é muita coisa e eu não sei por onde começar!"

☝️ pelo @____lighthouse! Os reports são muito intuitivos e já mostram vários "matos altos" pra você cortar.

23. Dá pra reduzir *bastante* o tamanho de uma fonte usando a técnica de Subsetting: remova os caracteres desnecessários/ilegíveis/de outros alfabetos.

👉 thenewcode.com/878/Slash-Page…

24. Quando se usa custom fonts é importante pensar na estratégia de carregamento para evitar o FOIT (Flash Of Invisible Text).

Aqui vai um guia do @zachleat com algumas estratégias ("FOUT with a class" é a minha favorita) 👇

zachleat.com/web/comprehens…

25. Falando no @zachleat, ele é o cara que mais admiro no tópico de Web Fonts. O cara já escreveu quase 50 artigos - quando tiver alguma dúvida sobre o assunto, dá uma olhada nesse link que sua dúvida provavelmente já foi respondida. You rock, Zach!

👇

zachleat.com/web/fonts/

26. Apesar do WebP oferecer um tamanho de arquivo menor que o JPEG, ele não dispõe de progressive loading - ou seja, às vezes a percepção de performance pode ser inferior. Além disso ele é mais complexo de ser implementado em função do suporte. Teste com carinho! 💛

27. Quando for trabalhar com JPEGs, use sempre MozJPEG e habilite progressive loading. Não use JPEG-XR na Web porque deu ruim: o decode rola na main thread junto com o JS e trava o rolê todo.

👇

calendar.perfplanet.com/2018/dont-use-…

28. Carregue as imagens abaixo da primeira dobra com lazy load. Existem algumas técnicas: placeholder fixo, placeholder de cor dominante, versão de baixa qualidade (LQIP/SQIP), etc. O @Medium usa LQIP.

👉 imagekit.io/blog/lazy-load…
👉 developers.google.com/web/fundamenta…

29. O tempo pode ser dividido de duas maneiras: ⏱ Objetivo & 🧠 Subjetivo. O primeiro é mensurável com um relógio, enquanto o segundo é a percepção de como ele transcorre. Estudos do @NNgroup mostram que há métricas de tempo subjetivo também.

👉 pt.slideshare.net/joaocunha/alm-…

30. Seja 20% mais rápido que seu principal concorrente.

Existe um conceito interessante na Psicofísica chamado "Limiar Diferencial" que determina a partir de que ponto o cérebro percebe diferenças. No tempo, esse gatilho é de aproximadamente 20%.

👉 smashingmagazine.com/2015/09/why-pe…