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
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%
Slide 16
Slide 16 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 17
Slide 17 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 18
Slide 18 text
No content
Slide 19
Slide 19 text
E quem mais se importa sobre o quanto
velocidade impacta na experiência de
usuário?
A Google!
Slide 20
Slide 20 text
O quanto a sua empresa investe em
Search engine optimization(SEO)?
Slide 21
Slide 21 text
“Velocidade agora é usado como uma
fator de ranking em buscas mobile.”
https://developers.google.com/web/updates/2018/07/search-ads-speed
Slide 22
Slide 22 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 23
Slide 23 text
Quer aumentar a conversão de
usuários? Aumente a velocidade!
Slide 24
Slide 24 text
Deve ser medida, monitorada e
refinada continuamente.
PERFORMANCE IMPORTA
Slide 25
Slide 25 text
Não é um “problema de
desenvolvimento”
É um trabalho que deve ser feito
em conjunto entre o designer, UX
e o desenvolvedor.
Slide 26
Slide 26 text
GOOGLE ANALYTICS
1.
Slide 27
Slide 27 text
Pra quem estamos
desenvolvendo?
Slide 28
Slide 28 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 29
Slide 29 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 30
Slide 30 text
OTIMIZAR?
Slide 31
Slide 31 text
DIMINUIR BYTES
2.
Slide 32
Slide 32 text
Minimizar o tamanho dos bytes
de resources críticos pode
reduzir o overhead no processo
de renderização.
Slide 33
Slide 33 text
QUAL A COISA MAIS
PESADA?
Slide 34
Slide 34 text
Imagens são em média 60% dos bytes
necessários para carregar um site.
Google
Slide 35
Slide 35 text
IMAGENS
Slide 36
Slide 36 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 37
Slide 37 text
SVGS para icones, desenhos ou logos.
Renderizar um HTML é melhor do que baixar
uma imagem!
Slide 38
Slide 38 text
SVGS para icones, desenhos ou logos.
Slide 39
Slide 39 text
FONTES
Slide 40
Slide 40 text
WOFF2 tem 30% de redução no
seu tamanho.
Slide 41
Slide 41 text
QUAL A COISA MAIS
CUSTOSA?
Slide 42
Slide 42 text
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Slide 43
Slide 43 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 44
Slide 44 text
Há diferença em
processamento!
Slide 45
Slide 45 text
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Slide 46
Slide 46 text
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Slide 47
Slide 47 text
Como diminuir o tamanho do
código a ser carregado?
Slide 48
Slide 48 text
❤
WEBPACK
❤
❤
Slide 49
Slide 49 text
node_modules
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
Só ele já é o suficiente para reduzir
a maior parte do nosso bundle size!
Slide 52
Slide 52 text
Redundancia, breaking changes, configurações muito específicas
de plugins e loaders, doc ruim etc
Slide 53
Slide 53 text
VERSÃO 4 ❤
Slide 54
Slide 54 text
OPTIMIZATION
Slide 55
Slide 55 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 56
Slide 56 text
No content
Slide 57
Slide 57 text
// webpack.config.js
{
// ...
optimization: {
minimize: true,
}
};
Slide 58
Slide 58 text
Mode
Development / Production
Com isso o webpack aplica otimizações de
acordo com o modo de desenvolvimento.
Slide 59
Slide 59 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 60
Slide 60 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 61
Slide 61 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 62
Slide 62 text
Qual a parte mais pesada do
nosso projeto?
node_modules
Slide 63
Slide 63 text
https://github.com/webpack-contrib/webpack-bundle
-analyzer
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 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 66
Slide 66 text
Otimizar dependências
Closure Compiler pra otimizações
avançadas.
ContextReplacementPlugin pra bibliotecas
como Moment.js
Slide 67
Slide 67 text
React -> Preact
Ramda -> Rambda
Lodash -> UnderWater
Immutable -> Immutable-Light
Slide 68
Slide 68 text
https://github.com/GoogleChromeLabs/webpack-libs-optimizations
webpack-libs-optimizations
Slide 69
Slide 69 text
PARTIAL IMPORTS
// bad
import r from “ramda”;
r.pipe()
// good
import pipe from ramda/pipe;
Slide 70
Slide 70 text
ES6 Modules & module
concatenation
Slide 71
Slide 71 text
ES6
export
import
Slide 72
Slide 72 text
three-shaking
O bundler atravessa toda a árvore de
dependências, procura por dependências
usadas e remove as não usadas.
Slide 73
Slide 73 text
// 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.
Slide 74
Slide 74 text
PLUGINS +
OTIMIZACOES
Slide 75
Slide 75 text
CSS
CSS-loader
ExtractText
(Extrair o CSS para o navegador fazer cache mais
facilmente, download paralelo e parsing)
Slide 76
Slide 76 text
IMAGENS
Loaders para auto-build src sets
Plugins para compressão automatica
Slide 77
Slide 77 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 78
Slide 78 text
No content
Slide 79
Slide 79 text
PERFEITO!
Agora meu código está leve!
Slide 80
Slide 80 text
Bom...Isso não é muito realista
Slide 81
Slide 81 text
No content
Slide 82
Slide 82 text
PRIORIZACAO DE
CODIGO
2.
Slide 83
Slide 83 text
Ordem de carregamento coisas
importa psicologicamente
Slide 84
Slide 84 text
No content
Slide 85
Slide 85 text
Diminuir nosso start render!
Slide 86
Slide 86 text
CRITICAL RENDER PATH
Slide 87
Slide 87 text
Série de eventos envolvendo baixar
resources html css e scripts,
processar e renderizar o primeiro
pixel na tela.
Slide 88
Slide 88 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 89
Slide 89 text
style.css index.htm
l
dog.png britneySpears-
toxic.mp3
?????
Slide 90
Slide 90 text
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Slide 91
Slide 91 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 92
Slide 92 text
SERVER
HTTP/1.1 200 OK
Content-Type:
text/html
RESPONSE
Slide 93
Slide 93 text
No content
Slide 94
Slide 94 text
SERVER
HTTP/1.1 200 OK
Content-Type: text/css RESPONSE
Slide 95
Slide 95 text
SERVER
HTTP/1.1 200 OK
Content-Type: png RESPONSE
Slide 96
Slide 96 text
O conteúdo requisitado é
carregado em pequenos
chunks.
Slide 97
Slide 97 text
No content
Slide 98
Slide 98 text
CONCURRENT REQUESTS
Slide 99
Slide 99 text
INITIAL PAYLOAD
Slide 100
Slide 100 text
No content
Slide 101
Slide 101 text
DNS Lookup
anabastos.me => 123.54.92.4
https://alistapart.com/article/planning-for-performance/
Slide 102
Slide 102 text
https://alistapart.com/article/planning-for-performance/
Envia requisição pra torre de celular(2s)
Slide 103
Slide 103 text
Dominio
Google, Cloudflare, Yandex, Quad9, Norton,
OpenDNS
A maioria funciona muito bem na américa do
norte(USA, Canada)ou Europa.
Slide 104
Slide 104 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 105
Slide 105 text
Compressão
Em que o tamanho do arquivo é comprimido por
algoritmos como brotli ou gzip.
Você pode minificar e depois comprimir.
Slide 106
Slide 106 text
HTTP 2
Solicitar e parsear
requisições em paralelo
Slide 107
Slide 107 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 108
Slide 108 text
Olá
Slide 109
Slide 109 text
h1 {
color: red
}
Slide 110
Slide 110 text
DOM
CSSDom
Render
Tree
ATTACHMENT
Slide 111
Slide 111 text
O CSS é um recursos bloqueante, ou seja,
não existe sem renderização sem que
ambos tenham uma arvore de
renderização.
Slide 112
Slide 112 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 113
Slide 113 text
Olá
Slide 114
Slide 114 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 115
Slide 115 text
RENDER START
Quando a primeira coisa é desenhada na
tela.
Slide 116
Slide 116 text
Se a página html contêm algum script
altamente bloqueante o render start vai ser
atrasado
Slide 117
Slide 117 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 118
Slide 118 text
PRIORIDADES
Slide 119
Slide 119 text
ASYNC vs DEFER
Slide 120
Slide 120 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 121
Slide 121 text
MEDIA CSS
Slide 122
Slide 122 text
Bloqueia a renderização do navegador até que o recurso seja retornado.
Slide 123
Slide 123 text
Dependendo da orientação do dispositivo bloqueia a
renderização do navegador até que o recurso seja retornado.
Slide 124
Slide 124 text
RESOURCE HINTS
Slide 125
Slide 125 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 126
Slide 126 text
Se você tem CERTEZA que vai usar
essa conexão
Slide 127
Slide 127 text
FONTES
Slide 128
Slide 128 text
Para que suas fontes sejam
carregadas mais rápido
Slide 129
Slide 129 text
Resources externos
Slide 130
Slide 130 text
Pra lidar com código
bloqueante Javascript...
Slide 131
Slide 131 text
ensure
Dynamic Import
require.ensure([/* dependencies */], require => {
const Foo = require('foo');
}, error => {
// handle error
}, 'custom-bundle-name');
Slide 132
Slide 132 text
LAZY LOAD
Slide 133
Slide 133 text
/home
/about
/contact
Pagina
Inicial
() => import('./About')
() => import('./Contact)
Slide 134
Slide 134 text
CACHEAR
3.
Slide 135
Slide 135 text
Service Workers
Slide 136
Slide 136 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 137
Slide 137 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 138
Slide 138 text
optimize.SplitChunks
Code Splitting
Com isso você tem bundles menores e
controle de prioridade sobre seus
recursos.
Slide 139
Slide 139 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 140
Slide 140 text
https://webpack.js.org/guides/caching/
Slide 141
Slide 141 text
PRPL Pattern
Slide 142
Slide 142 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 143
Slide 143 text
AMP(Accelerated Mobile
Pages)
Slide 144
Slide 144 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 145
Slide 145 text
METRIFICAR
4.
Slide 146
Slide 146 text
O que demora mais?
O que é mais custoso?
Slide 147
Slide 147 text
Devtools / network
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 / performance
Slide 152
Slide 152 text
No content
Slide 153
Slide 153 text
No content
Slide 154
Slide 154 text
No content
Slide 155
Slide 155 text
No content
Slide 156
Slide 156 text
Devtools / audit
Slide 157
Slide 157 text
No content
Slide 158
Slide 158 text
APIs
● Navigation Timing API
● Resource Timing API
● User Timing API
Slide 159
Slide 159 text
PERFORMANCE
BUDGET
5.
Slide 160
Slide 160 text
Criar um ponto de início tangível para
métricas.
Slide 161
Slide 161 text
Quais métricas
importam?
Slide 162
Slide 162 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 163
Slide 163 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 164
Slide 164 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 165
Slide 165 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 166
Slide 166 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 167
Slide 167 text
Target Time Kilobyte Weight
Start Render 1.194s 114kb
Document Complete 2.52s 242kb
Fully Loaded 2.822s 271kb
(kbs / 8) * targetTime
Slide 168
Slide 168 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 169
Slide 169 text
Crie milestones
Slide 170
Slide 170 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 171
Slide 171 text
CONTINUOUS
INTEGRATION
6.
Slide 172
Slide 172 text
Metricas e
insights para
boas práticas
de código
Slide 173
Slide 173 text
No content
Slide 174
Slide 174 text
No content
Slide 175
Slide 175 text
No content
Slide 176
Slide 176 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 177
Slide 177 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 178
Slide 178 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 179
Slide 179 text
Obrigada!
anabastos
@naluhh
@anapbastos