Programaria Summit - Performance Front-end

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

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!
    

    View Slide

17. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. GOOGLE ANALYTICS
    1.
    

    View Slide

26. Pra quem estamos
    desenvolvendo?
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

29. OTIMIZAR?
    

    View Slide

30. DIMINUIR BYTES
    2.
    

    View Slide

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

    View Slide

32. QUAL A COISA MAIS
    PESADA?
    

    View Slide

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

    View Slide

34. IMAGENS
    

    View Slide

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

    View Slide

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

    View Slide

37. SVGS para icones, desenhos ou logos.
    

    View Slide

38. FONTES
    

    View Slide

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

    View Slide

40. QUAL A COISA MAIS
    CUSTOSA?
    

    View Slide

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

    View Slide

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
    

    View Slide

43. Há diferença em
    processamento!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. ❤
    WEBPACK
    ❤
    ❤
    

    View Slide

48. node_modules
    

    View Slide

49. View Slide

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

    View Slide

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

    View Slide

52. VERSÃO 4 ❤
    

    View Slide

53. OPTIMIZATION
    

    View Slide

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
    

    View Slide

55. View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

63. View Slide

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.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

69. ES6 Modules & module
    concatenation
    

    View Slide

70. ES6
    export
    import
    

    View Slide

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

    View Slide

72. PLUGINS +
    OTIMIZACOES
    

    View Slide

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)
    

    View Slide

74. View Slide

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

    View Slide

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

    View Slide

77. View Slide

78. PRIORIZACAO DE
    CODIGO
    2.
    

    View Slide

79. Ordem de carregamento coisas
    importa psicologicamente
    

    View Slide

80. View Slide

81. Diminuir nosso start render!
    

    View Slide

82. CRITICAL RENDER PATH
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

89. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

93. View Slide

94. CONCURRENT REQUESTS
    

    View Slide

95. INITIAL PAYLOAD
    

    View Slide

96. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
     

     View Slide

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

     View Slide

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

     View Slide

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.
     

     View Slide

104. 
     Olá
     
     
     
     
     

     View Slide

105. h1 {
     color: red
     }
     

     View Slide

106. DOM
     CSSDom
     Render
     Tree
     ATTACHMENT
     

     View Slide

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

     View Slide

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.
     

     View Slide

109. Olá
     

     View Slide

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

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

     View Slide

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

     View Slide

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.
     

     View Slide

114. PRIORIDADES
     

     View Slide

115. ASYNC vs DEFER
     

     View Slide

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

117. MEDIA CSS
     

     View Slide

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

     View Slide

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

     View Slide

120. RESOURCE HINTS
     

     View Slide

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

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

     View Slide

123. FONTES
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

127. LAZY LOAD
     

     View Slide

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

     View Slide

129. CACHEAR
     3.
     

     View Slide

130. Service Workers
     

     View Slide

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.
     

     View Slide

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
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

136. PRPL Pattern
     

     View Slide

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
     

     View Slide

138. AMP(Accelerated Mobile
     Pages)
     

     View Slide

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

     View Slide

140. METRIFICAR
     4.
     

     View Slide

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

     View Slide

142. Devtools / network
     

     View Slide

143. View Slide

144. View Slide

145. View Slide

146. Devtools / performance
     

     View Slide

147. View Slide

148. View Slide

149. View Slide

150. View Slide

151. Devtools / audit
     

     View Slide

152. View Slide

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

     View Slide

154. PERFORMANCE
     BUDGET
     5.
     

     View Slide

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

     View Slide

156. Quais métricas
     importam?
     

     View Slide

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

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
     

     View Slide

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
     

     View Slide

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

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
     

     View Slide

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

     View Slide

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
     

     View Slide

164. Crie milestones
     

     View Slide

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
     

     View Slide

166. CONTINUOUS
     INTEGRATION
     6.
     

     View Slide

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

     View Slide

168. View Slide

169. View Slide

170. View Slide

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/
     

     View Slide

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
     

     View Slide

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
     

     View Slide

174. Obrigada!
     anabastos
     @naluhh
     @anapbastos
     

     View Slide