Programaria Summit - Performance Front-end

Transcript

1. PERFORMANCE DE FRONT END
2. Ola! Meu nome é Ana Bastos Sou engenheira de software e cientista da computação. 2 anabastos @naluhh @anapbastos
4. Dicas e um passo a passo para boas práticas de performance .
5. O frontend é a parte integral do nosso produto. Você trabalha para entregar um bom design, bom serviço...
6. Mas você já pensou na performance do seu frontend recentemente?
7. Se não, não tema!
8. A maioria das pessoas não levam isso como algo de tanto impacto.
9. Uma pesquisa pela MachMetric em 2018 mostra que o tempo de carregamento completo de uma página comum é em torno de 8-11 segundos e pesa em torno de 1.3MB a 2.5MB apesar da recomendação geral de ser abaixo de 500 KB https://www.machmetrics.com/speed-blog/average-page-load-times-websites-2018/
10. De acordo com a htttparchive os dados de tamanho e tempo são similares, e além disso a maior parte dos sites sequer considera o usuário mobile https://httparchive.org/
11. Mais de 50% do tráfego na internet é mobile
13. O quanto a demora do meu site impacta na experiência do usuário?
14. • 50% dos usuários esperam que a página carregue em apenas 2 segundos. Caso contrário já é provável que eles vão abandonar o site • 1s de delay = 7% de declínio em conversões • 75% dos usuários não retornam para um site que demora mais de 4 segundos para carregar https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/
15. Sites lentos são a maior razão para compradores abandonarem uma compra 79% dos compradores online afirmam que problemas em performance fazem com que ele fique longe de uma loja. E ainda pior, 44% afirmam que contariam a impressão negativa para outras pessoas na internet.
16. Um site lento é uma experiência ruim do usuário que pode fazer com que ele não seja convertido / saia ou fique insatisfeito. E obviamente isso machuca leads e vendas!
18. E quem mais se importa sobre o quanto velocidade impacta na experiência de usuário? A Google!
19. O quanto a sua empresa investe em Search engine optimization(SEO)?
20. “Velocidade agora é usado como uma fator de ranking em buscas mobile.” https://developers.google.com/web/updates/2018/07/search-ads-speed
21. O Google mudou seu algoritmo para priorizar sites rápidos principalmente em mobile tornando um fator crítico para SEO que não pode mais ser ignorado
22. Quer aumentar a conversão de usuários? Aumente a velocidade!
23. Deve ser medida, monitorada e refinada continuamente. PERFORMANCE IMPORTA
24. Não é um “problema de desenvolvimento” É um trabalho que deve ser feito em conjunto entre o designer, UX e o desenvolvedor.
25. GOOGLE ANALYTICS 1.
26. Pra quem estamos desenvolvendo?
27. 2-5x diferença entre os celulares mais devagares e os mais rápidos 75% da internet ainda é 2G ou 3G O nosso ferramental pode ser um pouco melhor do que o de quem está usando o produto
28. Nosso serviço só deve estar disponível para cidades ou também áreas rurais, periféricas ou suburbanas? Meu público alvo está em celular ou desktop? Pode estar no metrô ou em internet pública? Que computador ou celular eles tem? Use o google analytics e reflita um pouco em pra quem você está desenvolvendo!
29. OTIMIZAR?
30. DIMINUIR BYTES 2.
31. Minimizar o tamanho dos bytes de resources críticos pode reduzir o overhead no processo de renderização.
32. QUAL A COISA MAIS PESADA?
33. Imagens são em média 60% dos bytes necessários para carregar um site. Google
34. IMAGENS
35. Use o tamanho certo de imagens(png vs jpg, gif vs video) Existem técnicas de otimização de imagens(ImageOptim) Prefira efeitos CSS como sombras ou gradientes para evitar imagens. +++++
36. SVGS para icones, desenhos ou logos. Renderizar um HTML é melhor do que baixar uma imagem!
37. SVGS para icones, desenhos ou logos.
38. FONTES
39. WOFF2 tem 30% de redução no seu tamanho.
40. QUAL A COISA MAIS CUSTOSA?
41. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
42. Quanto mais Javascript mais tempo leva para que ele seja parseado e compilado até que o usuário interaja com o site. No final, acaba sendo mais caro que processar imagens ou fontes. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
43. Há diferença em processamento!
44. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
45. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
46. Como diminuir o tamanho do código a ser carregado?
47. ❤ WEBPACK ❤ ❤
48. node_modules
50. Só ele já é o suficiente para reduzir a maior parte do nosso bundle size!
51. Redundancia, breaking changes, configurações muito específicas de plugins e loaders, doc ruim etc
52. VERSÃO 4 ❤
53. OPTIMIZATION
54. • Caracteres de novas linhas(\n) • Espaços em branco • Blocos de delimitação • Comentarios • Torna variáveis e funções ilegíveis para humanos MINIFICACAO
56. // webpack.config.js { // ... optimization: { minimize: true, } };
57. Mode Development / Production Com isso o webpack aplica otimizações de acordo com o modo de desenvolvimento.
58. Tooling pra debugging de browser Uma compilação mais rápida pra um ciclo de desenvolvimento mais rápido Mensagens úteis em runtime // webpack.config.js module.exports = { mode: development // ... …. (https://medium.com/webpack/webpack-4-mo de-and-optimization-5423a6bc597a) Mode
59. Um output menor Código mais rápido em runtime Omite bibliotecas que estão como development Não expõe source code ou paths Acesso a assets melhor // webpack.config.js module.exports = { mode: ‘production’ // ... …. (https://medium.com/webpack/webpack-4-mo de-and-optimization-5423a6bc597a) Mode
60. occurrenceOrder flagIncludedChunks mergeDuplicateChunks removeEmptyChunks removeAvailableModules usedExports providedExports sideEffects concatenateModules splitChunks runtimeChunk noEmitOnErrors namedModules namedChunks nodeEnv minimize …. // webpack.config.js module.exports = { mode: ‘production’ // ... …. (https://medium.com/webpack/webpack-4-mo de-and-optimization-5423a6bc597a) Mode
61. Qual a parte mais pesada do nosso projeto? node_modules
62. https://github.com/webpack-contrib/webpack-bundle -analyzer
64. Mais da metade do tamanho do javascript vem de dependências e boa parte desse tamanho sequer é necessário. Por exemplo, Lodash pesa 72KB de código ao bundle, se você usar apenas 20 métodos, então 65kb de código minificado não faz nada. No moment.js tem 223KB de código, mas 170kb são só de idiomas diferentes.
65. Otimizar dependências Closure Compiler pra otimizações avançadas. ContextReplacementPlugin pra bibliotecas como Moment.js
66. React -> Preact Ramda -> Rambda Lodash -> UnderWater Immutable -> Immutable-Light
67. https://github.com/GoogleChromeLabs/webpack-libs-optimizations webpack-libs-optimizations
68. PARTIAL IMPORTS // bad import r from “ramda”; r.pipe() // good import pipe from ramda/pipe;
69. ES6 Modules & module concatenation
70. ES6 export import
71. three-shaking O bundler atravessa toda a árvore de dependências, procura por dependências usadas e remove as não usadas.
72. PLUGINS + OTIMIZACOES
73. IMAGENS // webpack.config.js module.exports = { module: { rules: [{ test: /\.(jpe?g|png|gif)$/, loader: 'url-loader', options: { limit: 10 * 1024, }, }, ], }}; Criar regras loaders para otimizar de acordo com o tipo da imagem. Url-loader Svg-url-loader image-webpack-loader Inline files smaller than 10 kB (10240 bytes)
75. PERFEITO! Agora meu código está leve!
76. Bom...Isso não é muito realista
78. PRIORIZACAO DE CODIGO 2.
79. Ordem de carregamento coisas importa psicologicamente
81. Diminuir nosso start render!
82. CRITICAL RENDER PATH
83. Série de eventos envolvendo baixar resources html css e scripts, processar e renderizar o primeiro pixel na tela.
84. A primeira visualização da página ou o que o usuário vê é crítica para experiência do usuário. Tentar otimizar cada passo no critical render path vai acelerar o processos de renderização
85. style.css index.htm l dog.png britneySpears- toxic.mp3 ?????
86. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
87. Primeiro Request Parsear o URL(procolo, dominio) Request DNS (anabastos.me => 63.245.208.161) Abre uma conexão TCP Envia uma requisição HTTP
88. SERVER HTTP/1.1 200 OK Content-Type: text/html RESPONSE
90. SERVER HTTP/1.1 200 OK Content-Type: text/css RESPONSE
91. SERVER HTTP/1.1 200 OK Content-Type: png RESPONSE
92. O conteúdo requisitado é carregado em pequenos chunks.
94. CONCURRENT REQUESTS
95. INITIAL PAYLOAD
97. DNS Lookup anabastos.me => 123.54.92.4 https://alistapart.com/article/planning-for-performance/
98. https://alistapart.com/article/planning-for-performance/ Envia requisição pra torre de celular(2s)
99. Dominio Google, Cloudflare, Yandex, Quad9, Norton, OpenDNS A maioria funciona muito bem na américa do norte(USA, Canada)ou Europa.
100. Dominio Brasil, Sao Paulo - #1 CloudFlare 2.71 ms - #2 CleanBrowsing 12.00 ms - #3 Google_DNS 29.71 ms - #4 Norton_DNS 114.71 ms - #5 Quad9 114.71 ms - #6 Comodo_DNS 129.85 ms - #7 OpenDNS 213.14 ms - #8 Yandex_DNS 238.14 ms
101. Compressão Em que o tamanho do arquivo é comprimido por algoritmos como brotli ou gzip. Você pode minificar e depois comprimir.
102. HTTP 2 Solicitar e parsear requisições em paralelo
103. Content Delivery Network(CDN). Basicamente ele espalha o servidor por diversas localizações e deixa o servidor mais próximo prover dados para os usuários. A distância menor faz carregar mais rápido.
104. <div> <h1>Olá</h1> <div> <img src=”dog1.png”> </div> </div>
105. h1 { color: red }
106. DOM CSSDom Render Tree ATTACHMENT
107. O CSS é um recursos bloqueante, ou seja, não existe sem renderização sem que ambos tenham uma arvore de renderização.
108. Imagens por exemplo não interferem na arvore de renderização então o navegador não espera que ela carregue pra renderizar a pagina.
109. Olá
110. Digamos que você tem um arquivo Javascript: <script src="test.js"></script> Esse script também é bloqueante na renderização do navegador pois aguarda até que o recurso seja retornado.
111. RENDER START Quando a primeira coisa é desenhada na tela.
112. Se a página html contêm algum script altamente bloqueante o render start vai ser atrasado
113. Otimizando a ordem de cada recurso crítico baixado e fazendo lazy-loading recursos não críticos podemos minimizar o tempo de total pro render start.
114. PRIORIDADES
115. ASYNC vs DEFER
116. <script src="javascript.js" async></script> Indica que é um asset não bloqueante então deve ser executado de forma assíncrona (coisas pequenas ou prioritárias). <script src="javascript.js" defer></script> Indica que o script só deve ser executado depois de toda a DOM ser parseada.
117. MEDIA CSS
118. <link href="style.css" rel=”stylesheet”> Bloqueia a renderização do navegador até que o recurso seja retornado.
119. <link href="style.css" rel=”stylesheet” media=”orientation:portrait”> Dependendo da orientação do dispositivo bloqueia a renderização do navegador até que o recurso seja retornado.
120. RESOURCE HINTS
121. <link rel=”preload”> Força o navegador a priorizar recursos que não devem ser bloqueados <link rel=”prefetch”> Avisa o navegador que recurso até é importante em futuras navegações mas não deve ser priorizado
122. Se você tem CERTEZA que vai usar essa conexão <link rel=”preconnect” href=”https://lalala.com”>
123. FONTES
124. Para que suas fontes sejam carregadas mais rápido <link rel=”preconnect” href=”fonte”>
125. Resources externos <link rel=”dns-prefetch” href=”https://lalala.com”>
126. Pra lidar com código bloqueante Javascript...
127. LAZY LOAD
128. /home /about /contact Pagina Inicial () => import('./About') () => import('./Contact)
129. CACHEAR 3.
130. Service Workers
131. Service Workers “Intercepta requisições” e usando a Cache API você pode criar estratégias diferentes do que vai ser salvo ou não pelo navegador e em quais ocasiões.
132. optimize.SplitChunks Code Splitting Dividir o código em vários bundles pra que eles sejam carregados sob demanda ou em paralelo. Com isso é possível ter bundles menores e controlar priorização, que tem um super impacto em carregação
133. optimize.SplitChunks Code Splitting Com isso você tem bundles menores e controle de prioridade sobre seus recursos.
134. { // ... splitChunks: { chunks: 'async', minSize: 30000, maxSize: 0, // Minimum size, in bytes, for a chunk to be generated. minChunks: 1, // Minimum number of chunks that must share a module before splitting maxAsyncRequests: 5, // Maximum number of parallel requests when on-demand loading. maxInitialRequests: 3, // Maximum number of parallel requests at an entry point. automaticNameDelimiter: '~', automaticNameMaxLength: 30, name: true, cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, priority: -10 // cache groups and priority } };
135. https://webpack.js.org/guides/caching/
136. PRPL Pattern
137. Um padrão que repensa a forma de criar aplicações web cuja base é lidar com conexões lentas, instáveis e dispositivos móveis insuficientes com recursos web que melhorar a experiência principalmente móvel • Push (enviar) recursos críticos para a rota do URL inicial. • Render (renderizar) a rota inicial. • Pre-cache (armazenar em cache) as demais rotas. • Lazy-load (carregar com atraso) e criar demais rotas de acordo com a ação do usuário. PRPL
138. AMP(Accelerated Mobile Pages)
139. AMP é uma segunda rota pra um website extremamente otimizada e rápida para mobile. Ao realizar uma busca no Google usando o celular, as páginas com AMP configurado ficam marcadas com a sua sigla e essa versão simplificada da página é carregada quase instantaneamente. A estimativa é que páginas compatíveis com a tecnologia abram com até 80% de mais velocidade e com isso google está dando uma extrema prioridade para esse tipo de site. .
140. METRIFICAR 4.
141. O que demora mais? O que é mais custoso?
142. Devtools / network
146. Devtools / performance
151. Devtools / audit
153. APIs • Navigation Timing API • Resource Timing API • User Timing API
154. PERFORMANCE BUDGET 5.
155. Criar um ponto de início tangível para métricas.
156. Quais métricas importam?
157. Quanto tempo até a página começar a renderizar? Quanto tempo até a página ser útil? Quanto tempo até carregar tudo?
158. Nome Start Render Document Complete Fully Loaded meusite.co m.br 7.388s 9.321s 11.940s Entrar no webpagetest.org e colocar seu site
159. Nome Start Render Document Complete Fully Loaded site1.com. br 1.492s 3.150s 3.527s site2.com .br 5.290s 7.769s 9.882s site3.com .br 4.891s 28.394s 29.980s
160. De acordo com uma pesquisa psicológica, usuários sentem diferença na performance após 20% mais rápido ou mais devagar.
161. Atual Target(20% mais rápido) Start Render 1.492s 1.194s Document Complete 3.150s 2.52s Fully Loaded 3.527s 2.822s
162. Target Time Kilobyte Weight Start Render 1.194s 114kb Document Complete 2.52s 242kb Fully Loaded 2.822s 271kb (kbs / 8) * targetTime
163. Uma conexão 3G tem 768 kilobits por segundo. Faz a conversão de byte = 8 bits 768/8 = 96 kbytes por segundo 96 * targetTime Target Time Kilobyte Weight Start Render 1.194s 114kb Document Complete 2.52s 242kb Fully Loaded 2.822s 271kb
164. Crie milestones
165. • Até o fim da sprint diminuir o tamanho do código em tanto. • Diminuir metade das imagens e metade das fontes. • Trocar icones por SVGs • Melhorar priorização do JS
166. CONTINUOUS INTEGRATION 6.
167. Metricas e insights para boas práticas de código
171. Psicologia dos segundos https://www.smashingmagazine.com/2015/09/why-perform ance-matters-the-perception-of-time/#the-need-for-perfo rmance-optimization-the-20-rule Artigo sobre planning https://alistapart.com/article/planning-for-performance/ Documentação do AMP https://amp.dev/documentation/guides-and-tutorials/start/ create/basic_markup/?format=websites Web fundamental do padrão PRPL https://developers.google.com/web/fundamentals/performa nce/prpl-pattern/
172. Webpack Dicas de otimizações com webpack https://developers.google.com/web/fundamentals/performa nce/webpack/decrease-frontend-size Otimizacoes de bibliotecas https://github.com/GoogleChromeLabs/webpack-libs-optim izations Docs de optimizations https://webpack.js.org/configuration/optimization/ Bundle analyzer https://github.com/webpack-contrib/webpack-bundle-anal yzer
173. Server Side Rendering Web Developers Google - Critical Rendering Path developers.google.com/web/fundamentals/performance/crit ical-rendering-path/ How browsers work internally - Tali Garsiel - Front-Trends 2012 vimeo.com/44182484 How Browsers Work: Behind the scenes of modern web browsers html5rocks.com/en/tutorials/internals/howbrowserswork
174. Obrigada! anabastos @naluhh @anapbastos