Programaria Summit - Performance FrontEnd

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. 39% das pessoas saem do site se as imagens demoram muito pra carregar ou não carregam 52% dos usuários citam que o carregamento é importante para a lealdade deles em um site. Meio segundo a mais é o suficiente pra diminuir o trafico em 20%
16. 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.
17. 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!
19. E quem mais se importa sobre o quanto velocidade impacta na experiência de usuário? A Google!
20. O quanto a sua empresa investe em Search engine optimization(SEO)?
21. “Velocidade agora é usado como uma fator de ranking em buscas mobile.” https://developers.google.com/web/updates/2018/07/search-ads-speed
22. 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
23. Quer aumentar a conversão de usuários? Aumente a velocidade!
24. Deve ser medida, monitorada e refinada continuamente. PERFORMANCE IMPORTA
25. Não é um “problema de desenvolvimento” É um trabalho que deve ser feito em conjunto entre o designer, UX e o desenvolvedor.
26. GOOGLE ANALYTICS 1.
27. Pra quem estamos desenvolvendo?
28. 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
29. 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!
30. OTIMIZAR?
31. DIMINUIR BYTES 2.
32. Minimizar o tamanho dos bytes de resources críticos pode reduzir o overhead no processo de renderização.
33. QUAL A COISA MAIS PESADA?
34. Imagens são em média 60% dos bytes necessários para carregar um site. Google
35. IMAGENS
36. 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. +++++
37. SVGS para icones, desenhos ou logos. Renderizar um HTML é melhor do que baixar uma imagem!
38. SVGS para icones, desenhos ou logos.
39. FONTES
40. WOFF2 tem 30% de redução no seu tamanho.
41. QUAL A COISA MAIS CUSTOSA?
42. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
43. 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
44. Há diferença em processamento!
45. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
46. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
47. Como diminuir o tamanho do código a ser carregado?
48. ❤ WEBPACK ❤ ❤
49. node_modules
51. Só ele já é o suficiente para reduzir a maior parte do nosso bundle size!
52. Redundancia, breaking changes, configurações muito específicas de plugins e loaders, doc ruim etc
53. VERSÃO 4 ❤
54. OPTIMIZATION
55. • 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
57. // webpack.config.js { // ... optimization: { minimize: true, } };
58. Mode Development / Production Com isso o webpack aplica otimizações de acordo com o modo de desenvolvimento.
59. 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
60. 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
61. 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
62. Qual a parte mais pesada do nosso projeto? node_modules
63. https://github.com/webpack-contrib/webpack-bundle -analyzer
65. 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.
66. Otimizar dependências Closure Compiler pra otimizações avançadas. ContextReplacementPlugin pra bibliotecas como Moment.js
67. React -> Preact Ramda -> Rambda Lodash -> UnderWater Immutable -> Immutable-Light
68. https://github.com/GoogleChromeLabs/webpack-libs-optimizations webpack-libs-optimizations
69. PARTIAL IMPORTS // bad import r from “ramda”; r.pipe() // good import pipe from ramda/pipe;
70. ES6 Modules & module concatenation
71. ES6 export import
72. three-shaking O bundler atravessa toda a árvore de dependências, procura por dependências usadas e remove as não usadas.
73. // webpack.config.js module.exports = { optimization: { concatenateModules: true, }, }; (https://medium.com/webpack/webpack-4-mo de-and-optimization-5423a6bc597a) Hoisting Coloca todos os módulos em um único escopo ao invés de escrever em closures separados. Fazer isso Gera bundles que são mais rápidos para serem executados.
74. PLUGINS + OTIMIZACOES
75. CSS CSS-loader ExtractText (Extrair o CSS para o navegador fazer cache mais facilmente, download paralelo e parsing)
76. IMAGENS Loaders para auto-build src sets Plugins para compressão automatica
77. 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)
79. PERFEITO! Agora meu código está leve!
80. Bom...Isso não é muito realista
82. PRIORIZACAO DE CODIGO 2.
83. Ordem de carregamento coisas importa psicologicamente
85. Diminuir nosso start render!
86. CRITICAL RENDER PATH
87. Série de eventos envolvendo baixar resources html css e scripts, processar e renderizar o primeiro pixel na tela.
88. 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
89. style.css index.htm l dog.png britneySpears- toxic.mp3 ?????
90. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
91. 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
92. SERVER HTTP/1.1 200 OK Content-Type: text/html RESPONSE
94. SERVER HTTP/1.1 200 OK Content-Type: text/css RESPONSE
95. SERVER HTTP/1.1 200 OK Content-Type: png RESPONSE
96. O conteúdo requisitado é carregado em pequenos chunks.
98. CONCURRENT REQUESTS
99. INITIAL PAYLOAD
101. DNS Lookup anabastos.me => 123.54.92.4 https://alistapart.com/article/planning-for-performance/
102. https://alistapart.com/article/planning-for-performance/ Envia requisição pra torre de celular(2s)
103. Dominio Google, Cloudflare, Yandex, Quad9, Norton, OpenDNS A maioria funciona muito bem na américa do norte(USA, Canada)ou Europa.
104. 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
105. Compressão Em que o tamanho do arquivo é comprimido por algoritmos como brotli ou gzip. Você pode minificar e depois comprimir.
106. HTTP 2 Solicitar e parsear requisições em paralelo
107. 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.
108. <div> <h1>Olá</h1> <div> <img src=”dog1.png”> </div> </div>
109. h1 { color: red }
110. DOM CSSDom Render Tree ATTACHMENT
111. O CSS é um recursos bloqueante, ou seja, não existe sem renderização sem que ambos tenham uma arvore de renderização.
112. 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.
113. Olá
114. 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.
115. RENDER START Quando a primeira coisa é desenhada na tela.
116. Se a página html contêm algum script altamente bloqueante o render start vai ser atrasado
117. 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.
118. PRIORIDADES
119. ASYNC vs DEFER
120. <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.
121. MEDIA CSS
122. <link href="style.css" rel=”stylesheet”> Bloqueia a renderização do navegador até que o recurso seja retornado.
123. <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.
124. RESOURCE HINTS
125. <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
126. Se você tem CERTEZA que vai usar essa conexão <link rel=”preconnect” href=”https://lalala.com”>
127. FONTES
128. Para que suas fontes sejam carregadas mais rápido <link rel=”preconnect” href=”fonte”>
129. Resources externos <link rel=”dns-prefetch” href=”https://lalala.com”>
130. Pra lidar com código bloqueante Javascript...
131. ensure Dynamic Import require.ensure([/* dependencies */], require => { const Foo = require('foo'); }, error => { // handle error }, 'custom-bundle-name');
132. LAZY LOAD
133. /home /about /contact Pagina Inicial () => import('./About') () => import('./Contact)
134. CACHEAR 3.
135. Service Workers
136. 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.
137. 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
138. optimize.SplitChunks Code Splitting Com isso você tem bundles menores e controle de prioridade sobre seus recursos.
139. { // ... 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 } };
140. https://webpack.js.org/guides/caching/
141. PRPL Pattern
142. 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
143. AMP(Accelerated Mobile Pages)
144. 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. .
145. METRIFICAR 4.
146. O que demora mais? O que é mais custoso?
147. Devtools / network
151. Devtools / performance
156. Devtools / audit
158. APIs • Navigation Timing API • Resource Timing API • User Timing API
159. PERFORMANCE BUDGET 5.
160. Criar um ponto de início tangível para métricas.
161. Quais métricas importam?
162. Quanto tempo até a página começar a renderizar? Quanto tempo até a página ser útil? Quanto tempo até carregar tudo?
163. 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
164. 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
165. De acordo com uma pesquisa psicológica, usuários sentem diferença na performance após 20% mais rápido ou mais devagar.
166. Atual Target(20% mais rápido) Start Render 1.492s 1.194s Document Complete 3.150s 2.52s Fully Loaded 3.527s 2.822s
167. Target Time Kilobyte Weight Start Render 1.194s 114kb Document Complete 2.52s 242kb Fully Loaded 2.822s 271kb (kbs / 8) * targetTime
168. 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
169. Crie milestones
170. • 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
171. CONTINUOUS INTEGRATION 6.
172. Metricas e insights para boas práticas de código
176. 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/
177. 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
178. 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
179. Obrigada! anabastos @naluhh @anapbastos