Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Programaria Summit - Performance FrontEnd

Programaria Summit - Performance FrontEnd

Ana Luiza Portello

September 07, 2019
Tweet

More Decks by Ana Luiza Portello

Other Decks in Programming

Transcript

  1. Ola! Meu nome é Ana Bastos Sou engenheira de software

    e cientista da computação. 2 anabastos @naluhh @anapbastos
  2. O frontend é a parte integral do nosso produto. Você

    trabalha para entregar um bom design, bom serviço...
  3. 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/
  4. 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/
  5. • 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/
  6. 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%
  7. 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.
  8. 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!
  9. E quem mais se importa sobre o quanto velocidade impacta

    na experiência de usuário? A Google!
  10. “Velocidade agora é usado como uma fator de ranking em

    buscas mobile.” https://developers.google.com/web/updates/2018/07/search-ads-speed
  11. 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
  12. Não é um “problema de desenvolvimento” É um trabalho que

    deve ser feito em conjunto entre o designer, UX e o desenvolvedor.
  13. 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
  14. 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!
  15. Minimizar o tamanho dos bytes de resources críticos pode reduzir

    o overhead no processo de renderização.
  16. 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. +++++
  17. 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
  18. • 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
  19. 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
  20. 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
  21. 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
  22. 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.
  23. three-shaking O bundler atravessa toda a árvore de dependências, procura

    por dependências usadas e remove as não usadas.
  24. // 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.
  25. CSS CSS-loader ExtractText (Extrair o CSS para o navegador fazer

    cache mais facilmente, download paralelo e parsing)
  26. 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)
  27. Série de eventos envolvendo baixar resources html css e scripts,

    processar e renderizar o primeiro pixel na tela.
  28. 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
  29. 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
  30. Dominio Google, Cloudflare, Yandex, Quad9, Norton, OpenDNS A maioria funciona

    muito bem na américa do norte(USA, Canada)ou Europa.
  31. 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
  32. Compressão Em que o tamanho do arquivo é comprimido por

    algoritmos como brotli ou gzip. Você pode minificar e depois comprimir.
  33. 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.
  34. O CSS é um recursos bloqueante, ou seja, não existe

    sem renderização sem que ambos tenham uma arvore de renderização.
  35. 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.
  36. 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.
  37. 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.
  38. <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.
  39. <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
  40. Se você tem CERTEZA que vai usar essa conexão <link

    rel=”preconnect” href=”https://lalala.com”>
  41. ensure Dynamic Import require.ensure([/* dependencies */], require => { const

    Foo = require('foo'); }, error => { // handle error }, 'custom-bundle-name');
  42. 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.
  43. 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
  44. { // ... 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 } };
  45. 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
  46. 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. .
  47. Quanto tempo até a página começar a renderizar? Quanto tempo

    até a página ser útil? Quanto tempo até carregar tudo?
  48. 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
  49. 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
  50. De acordo com uma pesquisa psicológica, usuários sentem diferença na

    performance após 20% mais rápido ou mais devagar.
  51. Target Time Kilobyte Weight Start Render 1.194s 114kb Document Complete

    2.52s 242kb Fully Loaded 2.822s 271kb (kbs / 8) * targetTime
  52. 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
  53. • 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
  54. 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/
  55. 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
  56. 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