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