TDC 2015 - Otimizando a performance do front end

320 visualizações

Publicada em

Palestra sobre otimização de performance no Front-end e no brwoser

Publicada em: Engenharia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
320
No SlideShare
0
A partir de incorporações
0
Número de incorporações
28
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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
  • TDC 2015 - Otimizando a performance do front end

    1. 1. Otimizando a performance do front- end em uma aplicação real
    2. 2. Full stack engineer @andrehjr andre.junior@resultadosdigitais.com. br ANDRÉ JUNIOR
    3. 3. 1.52M+ de requests ~3 segundos
    4. 4. 8M+ de requests ~2 segundos
    5. 5. Performance é a feature mais importante.
    6. 6. NO FRONT-END?
    7. 7. Microsoft Amazon Google
    8. 8. PERCEPÇÃO HUMANA
    9. 9. Tempo de primeira resposta
    10. 10. Tempo de primeira resposta
    11. 11. Tempo de primeira resposta
    12. 12. https://developers.google.com/web/fundamentals/performance/critical-rendering-path/
    13. 13. MELHOR ENGAJAMENTO
    14. 14. MAIOR RETENÇÃO DE USUÁRIOS
    15. 15. MAIS CONVERSÕES
    16. 16. Como eles se sentem?
    17. 17. SPEED MATTERS
    18. 18. MÉTRICAS
    19. 19. REAL USER MONITORING (RUM)
    20. 20. Requisição http
    21. 21. Requisição http
    22. 22. Requisição http
    23. 23. Requisição http
    24. 24. 80% do tempo é gasto no Front-end.
    25. 25. DEFINIR METAS
    26. 26. FIRST RENDER ~600m
    27. 27. Critical Rendering Path
    28. 28. Critical Rendering Path
    29. 29. DO NOT BLOCK!
    30. 30. CARREGUE SOMENTE O NECESSÁRIO
    31. 31. CARREGUE TODO O RESTO ASSINCRONAMENTE
    32. 32. <script />
    33. 33. <script async />
    34. 34. REDES LENTAS
    35. 35. JÁ TESTOU SEU SITE EM UMA 3G?
    36. 36. INLINE CRITICAL CSS
    37. 37. REDUZIR REQUESTS AO SERVER
    38. 38. IMAGENS EM SPRITE
    39. 39. MINIFICAR JAVASCRIPT / CSS
    40. 40. GZIP
    41. 41. Net flix gain
    42. 42. USE CONTENT DELIVERY NETWORK (CDN)
    43. 43. Cuidado com JS de terceiros.
    44. 44. PRE-FETCH / DNS- PREFETCH / PRE-RENDER
    45. 45. Don't stop.
    46. 46. HANDS-ON!
    47. 47. Confreaks
    48. 48. Confreaks
    49. 49. Confreaks
    50. 50. Confreaks
    51. 51. Confreaks
    52. 52. Confreaks
    53. 53. 9to5mac
    54. 54. One more
    55. 55. Quick wins
    56. 56. NGX_PAGESPEED
    57. 57. HTTP 2.0/SPDY
    58. 58. FERRAMENTAS
    59. 59. Page speed Insights NewRelic Google Analytics http://stevesouders.com/cuzillion/ > performance.timing Google Web tools
    60. 60. REFERÊNCIAS
    61. 61. RESUMO
    62. 62. Carregue inicialmente somente o que você precisa
    63. 63. Não bloqueie o critical rendering path (usuários não gostam de ver uma tela em branco)
    64. 64. Conheça a sua aplicação, ajude o browser!
    65. 65. Mais performance, economizando recursos! (R$$$$)
    66. 66. Tenha métricas de cada mudança
    67. 67. @andrehjr andre.junior@resultadosdigitais.com.br shipit.resultadosdigitais.com.br We're hiring! ;) QUESTIONS?

    ×