Programaria Summit - Performance Front-end

Programaria Summit - Performance Front-end

Fcfcfbcdbe8543b6d76c7566d6e1693c?s=128

Ana Luiza Portello

September 07, 2019
Tweet

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
  3. None
  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

  12. None
  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!
  17. None
  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

  49. None
  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
  55. None
  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

  63. None
  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)
  74. None
  75. PERFEITO! Agora meu código está leve!

  76. Bom...Isso não é muito realista

  77. None
  78. PRIORIZACAO DE CODIGO 2.

  79. Ordem de carregamento coisas importa psicologicamente

  80. None
  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

  89. None
  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.

  93. None
  94. CONCURRENT REQUESTS

  95. INITIAL PAYLOAD

  96. None
  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

  143. None
  144. None
  145. None
  146. Devtools / performance

  147. None
  148. None
  149. None
  150. None
  151. Devtools / audit

  152. None
  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

  168. None
  169. None
  170. None
  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