HTMLSP - Navegadores por de baixo dos panos

HTMLSP - Navegadores por de baixo dos panos

Fcfcfbcdbe8543b6d76c7566d6e1693c?s=128

Ana Luiza Portello

April 25, 2019
Tweet

Transcript

  1. ANA LUIZA BASTOS github.com/anabastos @naluhh @anapbastos Software Developer na Quanto

    e cientista da computação pela PUC-SP anabastos.me
  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. NAVEGADORES POR DE BAIXO DOS PANOS

  4. Estrutura high level do navegador Como funciona o parser do

    navegador Fluxo renderização de paginas web Otimizações de critical render path
  5. Qual a função do navegador?

  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. None
  8. COMPONENTES PRINCIPAIS DO NAVEGADOR

  9. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  10. THE MAIN FLOW

  11. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  12. USER INTERFACE

  13. None
  14. anabastos.me

  15. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  16. Parsear o URL(procolo, dominio) Request DNS (anabastos.me => 63.245.208.161) Abre

    uma conexão TCP Envia uma requisição HTTP
  17. SERVERZINHO HTTP/1.1 200 OK Content-Type: text/html RESPONSE

  18. SERVERZINHO HTTP/1.1 200 OK Content-Type: text/css RESPONSE

  19. O conteúdo requisitado é carregado em pequenos chunks.

  20. None
  21. CONCURRENT REQUESTS

  22. style.css index.html dog.png britneySpears- toxic.mp3 ?????

  23. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  24. 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)
  25. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  26. RENDERING ENGINE

  27. WEBKIT GECKO BLINK TRIDENT

  28. FLUXO DE RENDERIZAÇAO

  29. 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; }
  30. 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>
  31. PARSER Construção da árvore de renderização

  32. 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
  33. JSON.parse

  34. GRAMMARS REGRAS DE SYNTAX QUE O DOCUMENTO DEVE SEGUIR DE

    ACORDO COM A LINGUAGEM TODA LINGUAGEM TEM UMA GRAMATICA DETERMINISTICA(VOCABULARIO)
  35. GRAMMARS LINGUAGENS DE PROGRAMACAO LINGUAGUENS DE MARCACAO LINGUAGENS DE ESTILO

    SAO “CONTEXT FREE GRAMMAR”
  36. 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”.
  37. CHARACTERS(UTF-8) <html><head>...</head> <body> <h1>Olá Intercon</h1> <p>tudo bem?</p></body></html> CONSTRUÇÅO DE ÁRVORE

    TOKENIZAÇÅO
  38. ANALISE LEXICA ANALISE SINTATICA { PARSER

  39. ANALISE LEXICA (SE O VOCABULARIO FAZ SENTIDO) ANALISE SINTATICA (SE

    FAZ SENTIDO) Oi Ash87h12d Oi tudo bom? ? oi tudo
  40. ANALISE LEXICA Com as regras da gramática quebra o código

    em tokens internamente que definem suas propriedades e regras.
  41. Eu vou no HTMLSP Pronome Verbo Contração Substantivo

  42. Dentro do HTML tenho inicio de tags, fim de tags,

    nomes de tributos e valores de atributos
  43. <body>Hello</body> startTag Text endTag

  44. Eu vou no HTMLSP <body>Hello</body> HTML BODY ‘Hello’ ?

  45. 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
  46. <duv> span { clor: #FFFF } consolr.log

  47. Esses tokens são enviados para o construtor da árvore que

    os reconhece e monta a nossa DOM.
  48. 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
  49. HTMLHtmlElement HTMLBodyElement HTMLHeaderElement HTMLHeadElement Olá <h1> </h1> l á O

    <img> HTMLImageElement
  50. 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>
  51. HTMLHtmlElement HTMLBodyElement HTMLHeadElement HTMLHeaderElement Olá HTMLDivElement HTMLImageElement HTMLDivElement HTMLImageElement

  52. 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.
  53. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO

  54. 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
  55. “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.
  56. h1 [] [ text “Olá mundo”] p [ class =”alert”]

    [ text “tudo bem?”] h1 { color: red } CSSStyleElement CSSRule Selectors h1 Declaration Color red
  57. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO CSS

  58. DOM CSSDom

  59. Com a DOM e a CSSOM juntos o navegador consegue

    criar a árvore de renderização.
  60. DOM CSSDom Render Tree ATTACHMENT

  61. 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.
  62. BODY IMG H1 Color: Red; HEAD HTML RENDER TREE

  63. 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.
  64. BODY IMG H1 Color: Red; HEAD HTML RENDER TREE Posição:

    (0,0) Dimensão: Viewport Dimensão: Block
  65. None
  66. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  67. PAINTING A camada UI Backend tem o papel de atravessar

    cada elemento da render tree desenhando usando toda a UI da página.
  68. Olá

  69. None
  70. None
  71. BYTES CHARACTERS CONSTRUÇÅO DE ÁRVORE TOKENIZAÇÅO JAVASCRIPT

  72. USER INTERFACE BROWSER ENGINE RENDERING ENGINE NETWORKING JS INTERPRETER UI

    BACKEND
  73. SPIDERMONKEY V8

  74. 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.
  75. Para melhorar a experiência do usuário 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
  76. OK DE QUE ISSO IMPORTA?

  77. CRITICAL RENDER PATH

  78. Série de eventos envolvendo baixar resources html css e scripts,

    processar e renderizar o primeiro pixel na tela.
  79. Se a página 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
  80. None
  81. None
  82. 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
  83. None
  84. None
  85. OTIMIZAR?

  86. PRIORIDADES

  87. 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.
  88. 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.
  89. ASYNC vs DEFER

  90. <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.
  91. 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.
  92. MEDIA CSS

  93. <link href="style.css" rel=”stylesheet”> Bloqueia a renderização do navegador até que

    o recurso seja retornado.
  94. <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.
  95. PRELOAD vs PREFETCH

  96. <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
  97. INITIAL PAYLOAD

  98. DNS Prefetching

  99. DNS Lookup anabastos.me => 123.54.92.4 Resources externos <link rel=”dns-prefetch” href=”https://lalala.com”>

  100. - DNS Prefetching - Conecta TCP - Requisita HTTP

  101. Se você tem CERTEZA que vai usar essa conecção <link

    rel=”preconnect” href=”https://lalala.com”>
  102. as

  103. None
  104. <link as=”image” href=”dogFofo.png”> <link as=”music” href=”britneySpearsToxic.mp3”>

  105. Minimizar o tamanho dos bytes de resources críticos pode reduzir

    o overhead no processo de renderização
  106. 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. SVGS para logos.
  107. Diminuir o tamanho do código de bibliotecas

  108. React -> Preact Ramda -> Rambda Lodash -> UnderWater Immutable

    -> Immutable-Light
  109. Diminuir o tamanho dos pacotes a serem carregados

  110. WEBPACK

  111. node_modules

  112. Pra lidar com código bloqueante Javascript...

  113. 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');
  114. CODE SPLITTING & LAZY LOAD

  115. 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.
  116. /home /about /contact Pagina Inicial () => import('./About') () =>

    import('./Contact)
  117. None
  118. 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
  119. OBRIGADA :) speakerdeck.com/anabastos anabastos.me github.com/anabastos @naluhh @anapbastos