Recomendados
Recomendados
Más contenido relacionado
Destacado
Similar a TDC 2015 - Otimizando a performance do front end
Similar a TDC 2015 - Otimizando a performance do front end (20)
TDC 2015 - Otimizando a performance do front end
- 1. Otimizando a performance do front- end em uma aplicação real
- 6. 1.52M+ de requests ~3 segundos
- 7. 8M+ de requests ~2 segundos
- 8. Performance é a feature mais importante.
- 11. PERCEPÇÃO HUMANA
- 18. MAIS CONVERSÕES
- 19. Como eles se sentem?
- 20. SPEED MATTERS
- 21. MÉTRICAS
- 23. Requisição http
- 24. Requisição http
- 25. Requisição http
- 26. Requisição http
- 27. 80% do tempo é gasto no Front-end.
- 28. DEFINIR METAS
- 32. DO NOT BLOCK!
- 35. <script />
- 36. <script async />
- 38. REDES LENTAS
- 39. JÁ TESTOU SEU SITE EM UMA 3G?
- 46. GZIP
- 47. Net flix gain
- 49. Cuidado com JS de terceiros.
- 50. PRE-FETCH / DNS- PREFETCH / PRE-RENDER
- 51. Don't stop.
- 52. HANDS-ON!
- 53. Confreaks
- 54. Confreaks
- 55. Confreaks
- 56. Confreaks
- 57. Confreaks
- 58. Confreaks
- 59. 9to5mac
- 61. One more
- 66. Quick wins
- 67. NGX_PAGESPEED
- 68. HTTP 2.0/SPDY
- 69. FERRAMENTAS
- 70. Page speed Insights NewRelic Google Analytics http://stevesouders.com/cuzillion/ > performance.timing Google Web tools
- 71. REFERÊNCIAS
- 73. RESUMO
- 74. Carregue inicialmente somente o que você precisa
- 75. Não bloqueie o critical rendering path (usuários não gostam de ver uma tela em branco)
- 76. Conheça a sua aplicação, ajude o browser!
- 78. Tenha métricas de cada mudança
Notas del editor
- A RD é uma startup criada em 2011 especializada em Marketing Digital e tem como principal produto o RD Station, um software que reune varias ferramentas de mkt digital em uma só plataforma.
- Mas vale a pena? em Junho nós serviamos 1,50M de requests em um page load de média de 3 segundos
- Hoje, 2 milhões a mais, com praticamente a mesma infra, e batendo os 2 segundos da média. Escalabidade + velocidade.
- Começar com a seguinte afirmação. Performance é a sua melhor feature! Do que adianta ter todas as features do mundo, se você não as faz bem e rápido.
- No Front end? O que é performance no front end
- No Front end temos a humanas, acontece no client. fazem parte da equação, a experiencia de uso deles é o mais importante. E a maneira em como entregamos isso a eles é critico. Tanto de design/usabilidade e velocidade.
- No Front end temos a humanas, acontece no client. fazem parte da equação, a experiencia de uso deles é o mais importante. E a maneira em como entregamos isso a eles é critico. Tanto de design/usabilidade e velocidade.
- O usuário pode se comportar diferentemente de acordo com os tempos de resposta.
- 100ms - OK 1000ms - OK!
- 10000ms - NOT OK! chances altas do usuario utilizar outra ferramenta e ainda falar mal.
- Qual vocêss preferem? Do ponto de vista do usuario. Neste ponto, vemos que o load time não é "real". Qual é a experiencia do usuario aqui? Mobile??
- Estudos indicam, sites mais rapidos, geram maior.
- Google usa a velocidade em comparação para o Ranking. Caso do Bing - Speed == R$ - Inicio do projetom queremos aumentar o engajamento, queremos mais conversões. e foi assim que começou o projeto performance do RDStation. Mas como eu sei que o site está rápido?
- Começamos pelas métricas, ver os pontos, os gargalos. Utilizamos o New Relic, e lá temos uma nota. Então nosso objetivo era aumentar essa nota. Toda ferramenta de métricas tem uma, o webpage test tem o Speed Index por exemplo.
- Começamos pelas métricas, ver os pontos, os gargalos. Utilizamos o New Relic, e lá temos uma nota. Então nosso objetivo era aumentar essa nota. Toda ferramenta de métricas tem uma, o webpage test tem o Speed Index por exemplo.
- Todo o caminho entre o usuario ida-volta - 400ms só em latencia, DNS lookup - webpage.test
- E se esse site fosse pra ser carregado em 1 segundo?
- 3 segundos até carregar por completo, só renderiza em 1.6s. é bloqueado até então, enquanto baixa e monta os assets.
- 3 segundos até carregar por completo, só renderiza em 1.6s. é bloqueado até então, enquanto baixa e monta os assets.
- No Front end temos a humanas, acontece no client. fazem parte da equação, a experiencia de uso deles é o mais importante. E a maneira em como entregamos isso a eles é critico. Tanto de design/usabilidade e velocidade.
- A partir das métricas, nós definimos metas. Não sabiamos ao certo como atacar todos os pontos. Mas definir metas, foi um óttimo começo, começamos a estudar formas de melhorar, investigar, analisar, etc. Formamos um time somente para atacar estas melhorias.
- A cultura da RD é ágil, principalmente do time de produto. Agile é nossa base. Por isso nosso objetivo é colocar UX neste processo, e não o contrário. Quando falamos em Agile, falamos em uma cultura! Não temos somente backlogs, sprints, reviews, dailies... Nós temos a necessidade de trabalhar de forma ágil porque é esse o nosso combustível. É como funcionamos e é como sabemos trabalhar. Nosso produtos têm deploys constantes. Tem dias em que deployamos mais de 10 pull requests, e isso é motivo de orgulho para nós. Preferimos pedir licença do que pedir desculpas.
- Critical Rendering Path. HTML é parseado incrementalmente e vai fazendo o download de assets. Cria a DOM e o CSSOM para montar a Render Tree e finalmente Renderizar. Porém é bloqueado sempre que encontra o algo CSS e Javascripts sincronos. Pois Javascripts podem modificar tanto o DOM quanto o CSSOM. Por razões de Usabilidade o Browser bloqueia a renderização, pois seria péssimo renderizar sem estilos.
- Eliminate Javascript from the CRP POR ISSO COLOCAMOS O JAVASCRIPT NO FUNDO DA PAGINA!!! Mas o browser fica sem fazer nada enquanto é bloqueado? Não, o Parser é inteligente, enquanto a renderização é bloqueada ele continua a parsear e baixar os assets. Porém o usuário pode ficar vendo uma tela branca.
- Não bloqueie o PARSER. Essa é a regra.
- Somente o necessárrio para que o Browser consiga fazer renderizar o mais cedo possivel - No XYZ plugins - No full framework
- Delegue eventos, carregue tudo assincronamente.
- tags scripts bloqueiam, async nelas!
- ASYNC! Uma promessa ao browser dizendo que o seu código não vai fazer mudanca alguma no DOM ou no CSSOM, logo ele não irá bloquear
- Quase ninguem usa, dias atras postaram isso D:
- 3G sofrida de todos nós
- O mais importante, analise suas páginas, o seu site, defina os pontos criticos. O que não for critico, carregue depois
- Note que não existe nenhum css externo
- O que o usuário irá olhar primeiro? qual o objetivo daquela página para o usuário? Falar do exemplo do Google.com.br, se entrar no google.com.br vai ver CSS inline. É uma balança. Inline de css vai contra os principios do povo ;) Falar também das técnicas de LocalStorage
- Realmente você usa todo aquele CSS? aquele framework de CSS, realmente usa ele inteiro? Você cria um projeto novo e adiciona um framework de css por 'adicionar', é um tiro no pé.
- Obviamente, latencia, networking...
- Otimizar e comprimir as imagens, usar sprites, isso diminui o tamanho delas consideravelmente… Quem gosta de abrir um site e fazer download de uma jpeg de 3mb ? Seu plano de dados do celular agradece.
- Juntar tudo!
- GZIP EM TODOS OS ASSETS! Simples e fácil, pode configurar no próprio servidor, nginx/apache
- $$$$$ Netflix $$$$ MICROSOFT/BING
- Falar do exemplo de latencia dos 400ms do nodejs.org
- Falar do exemplo de latencia dos 400ms do nodejs.org
- Ajudar o browser. Pré-renderizar, fazer o fetch do DNS, fazer fetch de assets que serão usados nas próximas páginas para cache
- Falar do exemplo de latencia dos 400ms do nodejs.org
- O mais importante, analise suas páginas, o seu site, defina os pontos criticos. O que não for critico, carregue depois
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Mostrar o demo ou pegar screenshots
- Hands on. Vamos analisar! minha rede lenta.. 400ms só no backend. OK! porémm 14 segundos até carregar por completo.. WTF o que acham?
- 8 javascripts, 8 csss, dezenas de imagens, essa tela fica em branco, pelo menos não tem imagem de 5mb
- 7 fucking seconds? um CSS de 242kb no final da pagina? wtf
- EASY WAY OUT. NGX_PAGESPEED
- HOPE FOR THE FUTURE
- Web Tools -> Audit, Timeline (Critical Path)
- O mais importante, analise suas páginas, o seu site, defina os pontos criticos. O que não for critico, carregue depois
- Usabilidade é importante, seus usuários são importantes são humanos, nós temos muito preconceito com eles.
- Ajude o browser, ele otimiza o que pode, mas somente você conhece a sua aplicação, defina os pontos mais criticos, e os otimize :) Use as ferramentas, e métricas pra te auxiliarem
- Utilizando essas técnicas, muito provavelmente você irá economizar recursos, seus usuários vão ficar mais felizes, engajados, e não vão falar mal!
- Começar com a seguinte afirmação. Performance é a sua melhor feature! Do que adianta ter todas as features do mundo, se você não as faz bem e rápido.
- Alguem tem alguma razão sobre o porque não investir nisso?? SHUT UP AND TAKE MY MONEY