Programaria Summit - Performance FrontEnd

Transcript

1. PERFORMANCE
   DE FRONT END
   

   View Slide

2. Ola!
   Meu nome é Ana Bastos
   Sou engenheira de
   software e cientista da
   computação.
   2
   anabastos
   @naluhh
   @anapbastos
   

   View Slide

3. View Slide

4. Dicas e um passo a passo
   para boas práticas de
   performance .
   

   View Slide

5. O frontend é a parte integral do
   nosso produto.
   Você trabalha para entregar um
   bom design, bom serviço...
   

   View Slide

6. Mas você já pensou na performance
   do seu frontend recentemente?
   

   View Slide

7. Se não, não tema!
   

   View Slide

8. A maioria das pessoas não levam isso
   como algo de tanto impacto.
   

   View Slide

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/
   

   View Slide

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/
    

    View Slide

11. Mais de 50% do tráfego na internet é
    mobile
    

    View Slide

12. View Slide

13. O quanto a demora do meu site
    impacta na experiência do
    usuário?
    

    View Slide

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/
    

    View Slide

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%
    

    View Slide

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.
    

    View Slide

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!
    

    View Slide

18. View Slide

19. E quem mais se importa sobre o quanto
    velocidade impacta na experiência de
    usuário?
    A Google!
    

    View Slide

20. O quanto a sua empresa investe em
    Search engine optimization(SEO)?
    

    View Slide

21. “Velocidade agora é usado como uma
    fator de ranking em buscas mobile.”
    https://developers.google.com/web/updates/2018/07/search-ads-speed
    

    View Slide

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
    

    View Slide

23. Quer aumentar a conversão de
    usuários? Aumente a velocidade!
    

    View Slide

24. Deve ser medida, monitorada e
    refinada continuamente.
    PERFORMANCE IMPORTA
    

    View Slide

25. Não é um “problema de
    desenvolvimento”
    É um trabalho que deve ser feito
    em conjunto entre o designer, UX
    e o desenvolvedor.
    

    View Slide

26. GOOGLE ANALYTICS
    1.
    

    View Slide

27. Pra quem estamos
    desenvolvendo?
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

30. OTIMIZAR?
    

    View Slide

31. DIMINUIR BYTES
    2.
    

    View Slide

32. Minimizar o tamanho dos bytes
    de resources críticos pode
    reduzir o overhead no processo
    de renderização.
    

    View Slide

33. QUAL A COISA MAIS
    PESADA?
    

    View Slide

34. Imagens são em média 60% dos bytes
    necessários para carregar um site.
    Google
    

    View Slide

35. IMAGENS
    

    View Slide

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.
    +++++
    

    View Slide

37. SVGS para icones, desenhos ou logos.
    Renderizar um HTML é melhor do que baixar
    uma imagem!
    

    View Slide

38. SVGS para icones, desenhos ou logos.
    

    View Slide

39. FONTES
    

    View Slide

40. WOFF2 tem 30% de redução no
    seu tamanho.
    

    View Slide

41. QUAL A COISA MAIS
    CUSTOSA?
    

    View Slide

42. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
    

    View Slide

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
    

    View Slide

44. Há diferença em
    processamento!
    

    View Slide

45. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
    

    View Slide

46. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
    

    View Slide

47. Como diminuir o tamanho do
    código a ser carregado?
    

    View Slide

48. ❤
    WEBPACK
    ❤
    ❤
    

    View Slide

49. node_modules
    

    View Slide

50. View Slide

51. Só ele já é o suficiente para reduzir
    a maior parte do nosso bundle size!
    

    View Slide

52. Redundancia, breaking changes, configurações muito específicas
    de plugins e loaders, doc ruim etc
    

    View Slide

53. VERSÃO 4 ❤
    

    View Slide

54. OPTIMIZATION
    

    View Slide

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
    

    View Slide

56. View Slide

57. // webpack.config.js
    {
    // ...
    optimization: {
    minimize: true,
    }
    };
    

    View Slide

58. Mode
    Development / Production
    Com isso o webpack aplica otimizações de
    acordo com o modo de desenvolvimento.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

62. Qual a parte mais pesada do
    nosso projeto?
    node_modules
    

    View Slide

63. https://github.com/webpack-contrib/webpack-bundle
    -analyzer
    

    View Slide

64. View Slide

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.
    

    View Slide

66. Otimizar dependências
    Closure Compiler pra otimizações
    avançadas.
    ContextReplacementPlugin pra bibliotecas
    como Moment.js
    

    View Slide

67. React -> Preact
    Ramda -> Rambda
    Lodash -> UnderWater
    Immutable -> Immutable-Light
    

    View Slide

68. https://github.com/GoogleChromeLabs/webpack-libs-optimizations
    webpack-libs-optimizations
    

    View Slide

69. PARTIAL IMPORTS
    // bad
    import r from “ramda”;
    r.pipe()
    // good
    import pipe from ramda/pipe;
    

    View Slide

70. ES6 Modules & module
    concatenation
    

    View Slide

71. ES6
    export
    import
    

    View Slide

72. three-shaking
    O bundler atravessa toda a árvore de
    dependências, procura por dependências
    usadas e remove as não usadas.
    

    View Slide

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.
    

    View Slide

74. PLUGINS +
    OTIMIZACOES
    

    View Slide

75. CSS
    CSS-loader
    ExtractText
    (Extrair o CSS para o navegador fazer cache mais
    facilmente, download paralelo e parsing)
    

    View Slide

76. IMAGENS
    Loaders para auto-build src sets
    Plugins para compressão automatica
    

    View Slide

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)
    

    View Slide

78. View Slide

79. PERFEITO!
    Agora meu código está leve!
    

    View Slide

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

    View Slide

81. View Slide

82. PRIORIZACAO DE
    CODIGO
    2.
    

    View Slide

83. Ordem de carregamento coisas
    importa psicologicamente
    

    View Slide

84. View Slide

85. Diminuir nosso start render!
    

    View Slide

86. CRITICAL RENDER PATH
    

    View Slide

87. Série de eventos envolvendo baixar
    resources html css e scripts,
    processar e renderizar o primeiro
    pixel na tela.
    

    View Slide

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
    

    View Slide

89. style.css index.htm
    l
    dog.png britneySpears-
    toxic.mp3
    ?????
    

    View Slide

90. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
    

    View Slide

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
    

    View Slide

92. SERVER
    HTTP/1.1 200 OK
    Content-Type:
    text/html
    RESPONSE
    

    View Slide

93. View Slide

94. SERVER
    HTTP/1.1 200 OK
    Content-Type: text/css RESPONSE
    

    View Slide

95. SERVER
    HTTP/1.1 200 OK
    Content-Type: png RESPONSE
    

    View Slide

96. O conteúdo requisitado é
    carregado em pequenos
    chunks.
    

    View Slide

97. View Slide

98. CONCURRENT REQUESTS
    

    View Slide

99. INITIAL PAYLOAD
    

    View Slide

100. View Slide

101. DNS Lookup
     anabastos.me => 123.54.92.4
     https://alistapart.com/article/planning-for-performance/
     

     View Slide

102. https://alistapart.com/article/planning-for-performance/
     Envia requisição pra torre de celular(2s)
     

     View Slide

103. Dominio
     Google, Cloudflare, Yandex, Quad9, Norton,
     OpenDNS
     A maioria funciona muito bem na américa do
     norte(USA, Canada)ou Europa.
     

     View Slide

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
     

     View Slide

105. Compressão
     Em que o tamanho do arquivo é comprimido por
     algoritmos como brotli ou gzip.
     Você pode minificar e depois comprimir.
     

     View Slide

106. HTTP 2
     Solicitar e parsear
     requisições em paralelo
     

     View Slide

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.
     

     View Slide

108. 
     Olá
     
     
     
     
     

     View Slide

109. h1 {
     color: red
     }
     

     View Slide

110. DOM
     CSSDom
     Render
     Tree
     ATTACHMENT
     

     View Slide

111. O CSS é um recursos bloqueante, ou seja,
     não existe sem renderização sem que
     ambos tenham uma arvore de
     renderização.
     

     View Slide

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.
     

     View Slide

113. Olá
     

     View Slide

114. Digamos que você tem um arquivo Javascript:
     
     Esse script também é bloqueante na renderização do
     navegador pois aguarda até que o recurso seja retornado.
     

     View Slide

115. RENDER START
     Quando a primeira coisa é desenhada na
     tela.
     

     View Slide

116. Se a página html contêm algum script
     altamente bloqueante o render start vai ser
     atrasado
     

     View Slide

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.
     

     View Slide

118. PRIORIDADES
     

     View Slide

119. ASYNC vs DEFER
     

     View Slide

120. 
     Indica que é um asset não bloqueante então deve
     ser executado de forma assíncrona
     (coisas pequenas ou prioritárias).
     
     Indica que o script só deve ser executado depois de toda a
     DOM ser parseada.
     

     View Slide

121. MEDIA CSS
     

     View Slide

122. 
     Bloqueia a renderização do navegador até que o recurso seja retornado.
     

     View Slide

123. media=”orientation:portrait”>
     Dependendo da orientação do dispositivo bloqueia a
     renderização do navegador até que o recurso seja retornado.
     

     View Slide

124. RESOURCE HINTS
     

     View Slide

125. 
     Força o navegador a priorizar recursos que não devem ser
     bloqueados
     
     Avisa o navegador que recurso até é importante em futuras
     navegações mas não deve ser priorizado
     

     View Slide

126. Se você tem CERTEZA que vai usar
     essa conexão
     href=”https://lalala.com”>
     

     View Slide

127. FONTES
     

     View Slide

128. Para que suas fontes sejam
     carregadas mais rápido
     
     

     View Slide

129. Resources externos
     href=”https://lalala.com”>
     

     View Slide

130. Pra lidar com código
     bloqueante Javascript...
     

     View Slide

131. ensure
     Dynamic Import
     require.ensure([/* dependencies */], require => {
     const Foo = require('foo');
     }, error => {
     // handle error
     }, 'custom-bundle-name');
     

     View Slide

132. LAZY LOAD
     

     View Slide

133. /home
     /about
     /contact
     Pagina
     Inicial
     () => import('./About')
     () => import('./Contact)
     

     View Slide

134. CACHEAR
     3.
     

     View Slide

135. Service Workers
     

     View Slide

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.
     

     View Slide

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
     

     View Slide

138. optimize.SplitChunks
     Code Splitting
     Com isso você tem bundles menores e
     controle de prioridade sobre seus
     recursos.
     

     View Slide

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 }
     };
     

     View Slide

140. https://webpack.js.org/guides/caching/
     

     View Slide

141. PRPL Pattern
     

     View Slide

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
     

     View Slide

143. AMP(Accelerated Mobile
     Pages)
     

     View Slide

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

     View Slide

145. METRIFICAR
     4.
     

     View Slide

146. O que demora mais?
     O que é mais custoso?
     

     View Slide

147. Devtools / network
     

     View Slide

148. View Slide

149. View Slide

150. View Slide

151. Devtools / performance
     

     View Slide

152. View Slide

153. View Slide

154. View Slide

155. View Slide

156. Devtools / audit
     

     View Slide

157. View Slide

158. APIs
     ● Navigation Timing API
     ● Resource Timing API
     ● User Timing API
     

     View Slide

159. PERFORMANCE
     BUDGET
     5.
     

     View Slide

160. Criar um ponto de início tangível para
     métricas.
     

     View Slide

161. Quais métricas
     importam?
     

     View Slide

162. Quanto tempo até a página começar a
     renderizar?
     Quanto tempo até a página ser útil?
     Quanto tempo até carregar tudo?
     

     View Slide

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
     

     View Slide

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
     

     View Slide

165. De acordo com uma pesquisa
     psicológica, usuários sentem
     diferença na performance após
     20% mais rápido ou mais
     devagar.
     

     View Slide

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
     

     View Slide

167. Target Time Kilobyte Weight
     Start Render 1.194s 114kb
     Document Complete 2.52s 242kb
     Fully Loaded 2.822s 271kb
     (kbs / 8) * targetTime
     

     View Slide

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
     

     View Slide

169. Crie milestones
     

     View Slide

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
     

     View Slide

171. CONTINUOUS
     INTEGRATION
     6.
     

     View Slide

172. Metricas e
     insights para
     boas práticas
     de código
     

     View Slide

173. View Slide

174. View Slide

175. View Slide

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/
     

     View Slide

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
     

     View Slide

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
     

     View Slide

179. Obrigada!
     anabastos
     @naluhh
     @anapbastos
     

     View Slide