Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Navegadores por de baixo dos panos - Ana Luiza Bastos

50 views

Published on

Ana Luiza Bastos - Fullstack Developer, Quanto

Como funciona o passo a passo da renderização de elementos do navegador do request ao website funcional e como otimizar a performance para garantir uma melhor experiência de usuário.

Apresentado no InterCon 2018 - https://eventos.imasters.com.br/intercon

Published in: Software
  • Be the first to comment

  • Be the first to like this

Navegadores por de baixo dos panos - Ana Luiza Bastos

  1. 1. ANA LUIZA BASTOS github.com/anabastos @naluhh @anapbastos Software Developer na Quanto e cientista da computação pela PUC-SP anabastos.me
  2. 2. JSLADIES fb.com/jsladiesbr twitter.com/jsladiessp meetup.com/JsLadies-BR LAMBDA.IO t.me/lambdastudygroup github.com/lambda-study-group meetup.com/Lambda-I-O-Sampa- Meetup
  3. 3. NAVEGADORES POR DE BAIXO DOS PANOS
  4. 4. Estrutura high level do navegador Fluxo renderização de paginas web Otimizações de critical render path
  5. 5. Qual a função do navegador?
  6. 6. Apresentar o conteúdo requisitado de um servidor de acordo com a especificação do HTML CSS(W3C) e servindo em uma janelinha
  7. 7. COMPONENTES PRINCIPAIS DO NAVEGADOR
  8. 8. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  9. 9. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  10. 10. USER INTERFACE
  11. 11. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  12. 12. BROWSER ENGINE Intermedia UI e a engine de renderização Responsavel por persistência dados(Cookies, LocalStorage, IndexedDB). Web APIs(canvas, WebSocket, Animation, WebWorkers, WebGL)
  13. 13. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  14. 14. RENDERING ENGINE
  15. 15. WEBKIT GECKO BLINK TRIDENT
  16. 16. THE MAIN FLOW
  17. 17. anabastos.me
  18. 18. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  19. 19. Parsear o URL(procolo, dominio) Request DNS(anabastos.me => 63.245.208.161) Abre uma conexão TCP Envia uma requisição HTTP
  20. 20. SERVERZINHO HTTP/1.1 200 OK Content-Type: text/html RESPONSE
  21. 21. SERVERZINHO HTTP/1.1 200 OK Content-Type: text/css RESPONSE
  22. 22. O conteúdo requisitado é carregado em pequenos chunks.
  23. 23. CONCURRENT REQUESTS
  24. 24. style.css index.html dog.png britneySpears- toxic.mp3 ?????
  25. 25. FLUXO DE RENDERIZAÇAO
  26. 26. h1 [] [ text “Olá mundo”] p [ class =”alert”] [ text “tudo bem?”]<h1>Olá</h1> <img src=”dog.png”> h1 [] [ text “Olá mundo”] p [ class =”alert”] [ text “tudo bem?”]h1 { color: red; }
  27. 27. BYTES 3C 62 6F 64 79 3E 48 65 6C 6C 6F 2C 20 3C 73 70 61 6E 3E 77 6F 72 6C 64 21 3C 2F 21 73 70 61 6E E 77 6F 72 6C 64 21 3C 2F 21 73 70 61 6E E 77 6F 72 6C 64 21 3C 2F 21 73 70 61 6E 3C 62 6F 64 79 3E 48 65 6C 6C 6F 2C 20 3C 73 70 E 77 6F 72 6C 64 21 3C 6E E 77 6E E8 77 B2 6E E 77 6E E8 77 B2 B1 CHARACTERS(UTF-8) <html><head></head> <body> <h1>Olá</h1> <p>tudo bem?</p> </body> </html>
  28. 28. PARSER Construção da árvore de renderização
  29. 29. PARSEAR Parsear significa traduzir uma estrutura para algo que o código possa usar. O resultado geralmente é um árvore de nós que representam a estrutura dos documentos
  30. 30. GRAMMARS REGRAS DE SYNTAX QUE O DOCUMENTO DEVE SEGUIR DE ACORDO COM A LINGUAGEM TODA LINGUAGEM TEM UMA GRAMATICA DETERMINISTICA(VOCABULARIO) ISSO SE CHAMA “CONTEXT FREE GRAMMAR”
  31. 31. A engine começa a parsear o HTML e converte-lo a “Nós da DOM” Esses DOM nós se tornam uma arvore chamada “content tree”.
  32. 32. CHARACTERS(UTF-8) <html><head>...</head> <body> <h1>Olá Intercon</h1> <p>tudo bem?</p></body></html> CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO ANALISE LEXICA ANALISE SINTATICA {PARSER
  33. 33. ANALISE LEXICA (SE O VOCABULARIO FAZ SENTIDO) ANALISE SINTATICA (SE FAZ SENTIDO) Oi Ash87h12d Oi tudo bom? ? oi tudo
  34. 34. ANALISE LEXICA Com as regras da gramática quebra o código em tokens internamente que definem suas propriedades e regras.
  35. 35. Eu vou no intercon Pronome Verbo Contração Substantivo
  36. 36. Dentro do HTML tenho inicio de tags, fim de tags, nomes de tributos e valores de atributos
  37. 37. <body>Hello</body> startTag Text endTag
  38. 38. Eu vou no intercon <body>Hello</body> HTML BODY ‘Hello’ ?
  39. 39. h1 [] [ text “Olá mundo”] p [ class =”alert”] [ text “tudo bem?”]<h1>Olá</h1> <img src=”dog.png”> <h1> </h1> l á StartTag: h1 EndTag: h1 Character Character Character O TOKENS <img> ImageTag
  40. 40. <htm> span { clor: #FFFF } consolr.log
  41. 41. Esses tokens são enviados para o construtor da árvore que os reconhece e monta a nossa DOM.
  42. 42. ANALISE SINTATICA É responsável por construir uma árvore de nós analisando se a estrutura do documento está de acordo com as regras sintáticas
  43. 43. HTMLHtmlElement HTMLBodyElement HTMLHeaderElement HTMLHeadElement Olá <h1> </h1> l á O <img> HTMLImageElement
  44. 44. h1 [] [ text “Olá mundo”] p [ class =”alert”] [ text “tudo bem?”] <div> <h1>Olá</h1> <div> <img src=”dog1.png”> <img src=”dog2.png”> </div> </div>
  45. 45. HTMLHtmlElement HTMLBodyElement HTMLHeadElement HTMLHeaderElement Olá HTMLDivElement HTMLImageElement HTMLDivElement HTMLImageElement
  46. 46. O resultado final de todo esse processo é o Document Object Model, ou "DOM", da nossa página simples, que é usado pelo navegador para todos os demais processamentos da página.
  47. 47. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO
  48. 48. Enquanto a DOM estava sendo renderizada nosso style.css é encontrado referenciado em nosso head. Assim como o HTML precisamos converter o CSS pelo mesmo processo desta vez criando um “CSS Object Model” ou CSSOM
  49. 49. “Flex” e o”Bison” são parser generators do WebKit para parsear automaticamente de arquivos com gramática CSS. As regras de objetos CSS contêm seletores e a declaração dos objetos correspondentes a gramática CSS.
  50. 50. h1 [] [ text “Olá mundo”] p [ class =”alert”] [ text “tudo bem?”] h1 { color: red } CSSStyleElement CSSRule Selectors h1 Declaration Color red
  51. 51. No momento de calcular os estilos da página o navegador começa com a regra mais aplicável(body) e logo em seguida vai refinando para as regras mais específicas.
  52. 52. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO JAVASCRIPT CSS
  53. 53. DOM CSSDom
  54. 54. Com a DOM e a CSSOM juntos o navegador consegue criar a árvore de renderização. O navegador pinta cada nó da pagina. Todo esse processo toma tempo e pode impactar na performance da pagina web.
  55. 55. DOM CSSDom Render Tree ATTACHMENT
  56. 56. BODY IMGH1 Color: Red; HEAD HTML RENDER TREE
  57. 57. LAYOUT / REFLOW Layout é o processo recursivo que começa da raiz da arvore(<html>) e continua recursivamente por toda a hierarquia do HTML computando informação geométrica de que cara render requer Dando as exatas coordenadas de onde cada nó deve aparecer na tela.
  58. 58. BODY IMGH1 Color: Red; HEAD HTML RENDER TREE Posição: (0,0) Dimensão: Viewport Dimensão: Block
  59. 59. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  60. 60. PAINTING A camada UI Backend tem o papel de atravessar cada elemento da render tree desenhando usando toda a UI da página.
  61. 61. Olá
  62. 62. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO JAVASCRIPT
  63. 63. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI BACKEND
  64. 64. SPIDERMONKEY V8
  65. 65. O javascript pode criar e modificar todo o DOM ou o CSSOM. Quando o analisador do HTML encontra uma tag “script” ela para toda a construção da DOM e só retoma quando conclui a execução.
  66. 66. Para melhorar a experiencia do usuario o engine de renderização vai tentar mostrar o conteúdo na tela assim que possível então não espera que outro HTML seja parseado até começar a construir a página
  67. 67. OK DE QUE ISSO IMPORTA?
  68. 68. CRITICAL RENDER PATH
  69. 69. Série de eventos envolvendo baixar resources html css e scripts, processar e renderizar o primeiro pixel na tela.
  70. 70. Se a pagina html contêm algum script altamente bloqueante o render start, o tempo levado para receber o primeiro byte de dados para o URL primário, vai ser atrasado
  71. 71. 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
  72. 72. OTIMIZAR?
  73. 73. PRIORIDADES
  74. 74. Otimizando a ordem de cada recurso crítico baixado e fazendo lazy-loading recursos não críticos podemos minimizar o tempo de total do critical render path.
  75. 75. Digamos que você tem um arquivo Javascript: <script src="test.js"></script> Esse script também é bloqueante na renderização do navegador pois aguarda até que o recurso seja retornado.
  76. 76. ASYNC vs DEFER
  77. 77. <script src="javascript.js" async></script> Indica que é um asset não bloqueante então deve ser executado de forma assíncrona(coisas pequenas ou prioritárias). <script src="javascript.js" defer></script> Indica que o script só deve ser executado depois de toda a DOM ser parseada.
  78. 78. Tanto o HTML quanto o CSS são recursos bloqueantes, ou seja, não existe sem renderização sem que ambos tenham uma arvore de renderização.
  79. 79. MEDIA CSS
  80. 80. <link href="style.css" rel=”stylesheet”> Bloqueia a renderização do navegador até que o recurso seja retornado.
  81. 81. <link href="style.css" rel=”stylesheet” media=”orientation:portrait”> Dependendo da orientação do dispositivo bloqueia a renderização do navegador até que o recurso seja retornado. <link href="style.css" rel=”stylesheet” media=”print”> Só aplica o CSS quando a página está sendo já gravada. Portanto é não bloqueante.
  82. 82. PRELOAD vs PREFETCH
  83. 83. <link rel=”preload”> Força o navegador a priorizar recursos que não devem ser bloqueados <link rel=”prefetch”> Avisa o navegador que recurso até é importante em futuras navegações mas não deve ser priorizado
  84. 84. INITIAL PAYLOAD
  85. 85. Minimizar o tamanho dos bytes de resources críticos pode reduzir o overhead no processo de renderização
  86. 86. IMAGENS Existem técnicas de otimização de imagens para reduzir o load time da página(compressão, escala, CSS sprites) Prefira efeitos CSS como sombras ou gradientes para evitar imagens.
  87. 87. Diminuir o tamanho do código de bibliotecas
  88. 88. React -> Preact Ramda -> Rambda Lodash -> UnderWater Immutable -> Immutable-Light
  89. 89. Diminuir o tamanho dos pacotes a serem carregados
  90. 90. WEBPACK
  91. 91. node_modules
  92. 92. DUPLICAÇAO DE CODIGO
  93. 93. SplitChunksPlugin Separa código que é da aplicação e o que é utilitário Listando bibliotecas como “vendor” faz com que se crie um arquivo individual que o browser consegue cachear o conteúdo com mais facilidade.
  94. 94. Pra lidar com código bloqueante Javascript...
  95. 95. CODE SPLITTING & LAZY LOAD
  96. 96. O code splitting permite que você divida seu código em pequenos bundles que podem ser carregados sob demanda ou em paralelo. Com isso você tem bundles menores e controle de prioridade sobre seus recursos.
  97. 97. /home /about /contact Pagina Inicial () => import('./About') () => import('./Contact)
  98. 98. ensure Dynamic Import está em stage3 da proposal para o js Plugin Babel (syntax-dynamic-import) require.ensure([/* dependencies */], require => { const Foo = require('foo'); }, error => { // handle error }, 'custom-bundle-name');
  99. 99. Web Developers Google - Critical Rendering Path developers.google.com/web/fundamentals/performance/critical-re ndering-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
  100. 100. OBRIGADA :) speakerdeck.com/anabastos anabastos.me github.com/anabastos @naluhh @anapbastos

×