Slide 1

Slide 1 text

PERFORMANCE DE FRONT END

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Se não, não tema!

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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/

Slide 10

Slide 10 text

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/

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

● 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/

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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!

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Deve ser medida, monitorada e refinada continuamente. PERFORMANCE IMPORTA

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

GOOGLE ANALYTICS 1.

Slide 26

Slide 26 text

Pra quem estamos desenvolvendo?

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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!

Slide 29

Slide 29 text

OTIMIZAR?

Slide 30

Slide 30 text

DIMINUIR BYTES 2.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

QUAL A COISA MAIS PESADA?

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

IMAGENS

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

SVGS para icones, desenhos ou logos.

Slide 38

Slide 38 text

FONTES

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

QUAL A COISA MAIS CUSTOSA?

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Há diferença em processamento!

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

❤ WEBPACK ❤ ❤

Slide 48

Slide 48 text

node_modules

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

VERSÃO 4 ❤

Slide 53

Slide 53 text

OPTIMIZATION

Slide 54

Slide 54 text

● 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

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Qual a parte mais pesada do nosso projeto? node_modules

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

ES6 Modules & module concatenation

Slide 70

Slide 70 text

ES6 export import

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

PLUGINS + OTIMIZACOES

Slide 73

Slide 73 text

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)

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

PERFEITO! Agora meu código está leve!

Slide 76

Slide 76 text

Bom...Isso não é muito realista

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

PRIORIZACAO DE CODIGO 2.

Slide 79

Slide 79 text

Ordem de carregamento coisas importa psicologicamente

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Diminuir nosso start render!

Slide 82

Slide 82 text

CRITICAL RENDER PATH

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

O conteúdo requisitado é carregado em pequenos chunks.

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

CONCURRENT REQUESTS

Slide 95

Slide 95 text

INITIAL PAYLOAD

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

HTTP 2 Solicitar e parsear requisições em paralelo

Slide 103

Slide 103 text

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.

Slide 104

Slide 104 text

Olá

Slide 105

Slide 105 text

h1 { color: red }

Slide 106

Slide 106 text

DOM CSSDom Render Tree ATTACHMENT

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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.

Slide 109

Slide 109 text

Olá

Slide 110

Slide 110 text

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.

Slide 111

Slide 111 text

RENDER START Quando a primeira coisa é desenhada na tela.

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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.

Slide 114

Slide 114 text

PRIORIDADES

Slide 115

Slide 115 text

ASYNC vs DEFER

Slide 116

Slide 116 text

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.

Slide 117

Slide 117 text

MEDIA CSS

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

Dependendo da orientação do dispositivo bloqueia a renderização do navegador até que o recurso seja retornado.

Slide 120

Slide 120 text

RESOURCE HINTS

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

Se você tem CERTEZA que vai usar essa conexão

Slide 123

Slide 123 text

FONTES

Slide 124

Slide 124 text

Para que suas fontes sejam carregadas mais rápido

Slide 125

Slide 125 text

Resources externos

Slide 126

Slide 126 text

Pra lidar com código bloqueante Javascript...

Slide 127

Slide 127 text

LAZY LOAD

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

CACHEAR 3.

Slide 130

Slide 130 text

Service Workers

Slide 131

Slide 131 text

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.

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

{ // ... 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 } };

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

PRPL Pattern

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

AMP(Accelerated Mobile Pages)

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

METRIFICAR 4.

Slide 141

Slide 141 text

O que demora mais? O que é mais custoso?

Slide 142

Slide 142 text

Devtools / network

Slide 143

Slide 143 text

No content

Slide 144

Slide 144 text

No content

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

Devtools / performance

Slide 147

Slide 147 text

No content

Slide 148

Slide 148 text

No content

Slide 149

Slide 149 text

No content

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

Devtools / audit

Slide 152

Slide 152 text

No content

Slide 153

Slide 153 text

APIs ● Navigation Timing API ● Resource Timing API ● User Timing API

Slide 154

Slide 154 text

PERFORMANCE BUDGET 5.

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

Quais métricas importam?

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

Atual Target(20% mais rápido) Start Render 1.492s 1.194s Document Complete 3.150s 2.52s Fully Loaded 3.527s 2.822s

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

Crie milestones

Slide 165

Slide 165 text

● 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

Slide 166

Slide 166 text

CONTINUOUS INTEGRATION 6.

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

No content

Slide 169

Slide 169 text

No content

Slide 170

Slide 170 text

No content

Slide 171

Slide 171 text

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/

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

Obrigada! anabastos @naluhh @anapbastos