Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CodeCamp 2016 - How the web and browsers actual...

James Macfie
April 08, 2016
0
59

CodeCamp 2016 - How the web and browsers actually work

James Macfie

April 08, 2016
Tweet

More Decks by James Macfie

See All by James Macfie
WalterScript. Next level scripting
macfie
0
110
We bite in this family
macfie
0
72
WDCNZ 2015 - Automating the Real World
macfie
0
360

Featured

See All Featured
Faster Mobile Websites
deanohume
305
30k
The Cult of Friendly URLs
andyhume
78
6.1k
Agile that works and the tools we love
rasmusluckow
328
21k
Making the Leap to Tech Lead
cromwellryan
133
9k
A better future with KSS
kneath
238
17k
Producing Creativity
orderedlist
PRO
341
39k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
Documentation Writing (for coders)
carmenintech
66
4.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.5k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Writing Fast Ruby
sferik
628
61k

Transcript

  1. @jamesmacfie How the web and browsers actually work An in-depth

    look at how things are rendered to the screen #codecamp

  2. #codecamp This is a talk about some technical things we

    often gloss over

  3. #codecamp What happens when we enter in a domain? And

    how is that information rendered to the screen?

  4. Oh look, we’ve entered a url and pressed enter #codecamp

  5. Before the browser does anything, it checks the url validity

    #codecamp If there are invalid characters, the browser will use Punycode to make the URL valid. bücher.com xn--bcher-kva.com/ büücher.com xn--bcher-kvaa.com/ münchen.com xn--mnchen-3ya.com/

  6. Does the browser need to force the request to use

    https? #codecamp There’s an internal cache of sites that have requested to only be communicated with https, not http HTTP Strict Transport Security LISt

  7. Now the browser can request the domain’s ip address #codecamp

    Cache Hosts file Local network DNS resolver

  8. #codecamp www. Domains resolve right to left google.COM

  9. Example for www.google.com #codecamp Recursive resolver Root resolver “Hey, can

    I have the IP address for www.google.com?” “Don’t have it - try xxx.xxx.xxx.xxx” “Don’t have it - try xxx.xxx.xxx.xxx” TLD resolver “Hey, can I have the IP address for www.google.com?” Domain resolver “Hey, can I have the IP address for www.google.com?” Sure, it’s -xxx.xxx.xxx.xxx”

  10. #codecamp At this point, we still haven’t made a request

    for any data

  11. This is what a request and response looks like #codecamp

    Request Response 200 OK Content-Length: 243 Content-Type: text/html [response headers] <html> <head> <title>Howdy</title> </head> GET / HTTP/1.1 Host: google.com Connection: close [other headers]

  12. We use different ports for http and https #codecamp 80

    HTTP 443 HTTPS

  13. Now, what’s this tcp/ip I’ve heard about? #codecamp TCP/IP handles

    how data is transferred 1 4 7 2 5 8 3 6 9 6 1 7 2 9 5 3 4 8 1 4 7 2 5 8 3 6 9

  14. WOOHOO! Now we start getting the document contents

  15. These are the different parts of a browser #codecamp User

    interface Browser engine Rendering engine Networking Data persistence JavaScript UI Backend

  16. #codecamp Let’s talk about the rendering engine

  17. Rendering html basically does this #codecamp Parse HTML and create

    the DOM tree Parse styles and create the render tree Layout the render tree Paint the render tree

  18. #codecamp Apologies, but we’re going to go into a bit

    of detail about parsing things

  19. #codecamp In a nutshell, parsing is translating some input into

    a structure that can be used in code

  20. For example, 2 + 3 - 1 could return this

    #codecamp Expression - Number 1 Expression + Number 2 Number 3

  21. #codecamp Grammars, vocabulary, and syntax

  22. XML is a context free grammar #codecamp <memo> <addressee>John</addressee> <sender>Carla</addressee>

    <date>19980901</date> <title>New coffee maker</title> <body> The new coffee maker has been installed! Operation is simple: put a cup in the opening and press the red button. </body> </memo>

  23. #codecamp parsing involves two processes - lexical analysis and syntax

    analysis

  24. Lexical analysis - breaking the input into tokens #codecamp Expression

    - Number 1 Expression + Number 2 Number 3

  25. Syntax analysis - converting tokens into a tree #codecamp Expression

    - Number 1 Expression + Number 2 Number 3

  26. #codecamp Ok, sure. but how is parsing html different?

  27. #codecamp HTML is not a context free grammar so we

    cannot use common parsing techniques

  28. #codecamp How html is parsed is defined by the w3c

  29. #codecamp There are two main reasons for this: - HTML

    parsers are extremely fault tolerant - the html can be modified as it is being parsed

  30. html’s forgiving nature is pretty nice really #codecamp <html> <div>

    <p> </div> </span>Crappy HTML </p> </html> <html> <head></head>
 <body> <div> <p></p> </div> Crappy HTML <p></p> </body> </html>

  31. html’s forgiving nature is pretty nice really #codecamp <table> <table>

    <tr><td>inner table</td></tr> </table> <tr><td>outer table</td></tr> </table> <table> <tr><td>outer table</td></tr> </table> <table> <tr><td>inner table</td></tr> </table>

  32. HTML’s parsing process is reentrant #codecamp Dynamic code can modify

    the HTML as it is being parsed. This can add extra tokens to the HTML. Think about a script tag that gets evaluated in the middle of the input which contains a document.write call

  33. The html parsing flow #codecamp DOM tree construction Network data

    Tokeniser Script execution DOM document.write()

  34. #codecamp both the tokeniser and the tree constructor act like

    a state machine

  35. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Data”

  36. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Tag open”

  37. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Tag name”

  38. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Data”

  39. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Token created: start-tag {name: html}

  40. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Data”

  41. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Token created: character {data: C}

  42. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Tag open”

  43. Let’s look at how the tokeniser would parse this #codecamp

    <html> <body> Codecamp </body> </html> Current state: “Close tag open”

  44. We end up with twelve tokens #codecamp start-tag { name:

    html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html }

  45. Next the DOM tree is constructed from the tokens #codecamp

    First, the root document node is created and all other nodes will be added to this. For each token, the spec defines which DOM element is relevant. These elements are added both to the DOM tree and also to the stack of open elements.

  46. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: Initial

  47. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: Before html HTMLHtmlElement

  48. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: Before head HTMLHtmlElement HTMLHeadElement

  49. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: In head HTMLHtmlElement HTMLHeadElement

  50. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: After head HTMLHtmlElement HTMLHeadElement

  51. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: In body HTMLHtmlElement HTMLHeadElement HTMLBodyElement

  52. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: In body HTMLHtmlElement HTMLHeadElement HTMLBodyElement Text

  53. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: In body HTMLHtmlElement HTMLHeadElement HTMLBodyElement Text

  54. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: After body HTMLHtmlElement HTMLHeadElement HTMLBodyElement Text

  55. How does this get converted into the dom tree? #codecamp

    start-tag { name: html } start-tag { name: body } character { data: C } character { data: o } character { data: d } character { data: e } character { data: c } character { data: a } character { data: m } character { data: p } end-tag { name: body } end-tag { name: html } State: After after body HTMLHtmlElement HTMLHeadElement HTMLBodyElement Text

  56. This is our final dom tree #codecamp HTMLHtmlElement HTMLHeadElement HTMLBodyElement

    Text <html> <body> Codecamp </body> </html>

  57. slightly more complicated #codecamp HTMLHtmlElement <html> <body> <div> <p>Code</p> <p>camp</p>

    </div> <div> <p> <span>2016</span> </p> </div> </body> </html> HTMLHeadElement HTMLBodyElement HTMLDivElement HTMLDivElement HTMLParagrahElement HTMLParagraphElement HTMLParagraphElement HTMLSpanElement Text Text Text

  58. #codecamp AnD... We’re done parsing the html

  59. We can now execute ‘defer’ scripts #codecamp <script> Ref: https://html.spec.whatwg.org/

    Parse HTML Fetch script Execute script <script async> <script defer>

  60. #codecamp Styles also pause the parsing of html. Well, mostly

  61. #codecamp Not all of these styles will block <link href=“style.css"

    rel=“stylesheet"> <link href=“style.css" rel="stylesheet" media=“all”> <link href="portrait.css" rel="stylesheet" media=“orientation:portrait"> <link href=“print.css" rel="stylesheet" media="print">

  62. #codecamp WHILE the DOM tree is being constructed, so is

    another tree - the render tree

  63. #codecamp Unlike html, css is a context free grammar

  64. For example - dom tree #codecamp <head></head> <body> <p> Codecamp

    <span> 2016 </span> </p> <span> Wellington </span> <div> <img src=“codecamp.jpg” /> </div> </body> body span div img p span text text text head

  65. For example - cssom #codecamp body {
 font-size: 16px; }

    p { font-weight: bold; } p span { display: none; } span { color: red; } img {
 float: right; } img p span body span font-size: 16px; font-weight: bold; font-size: 16px; font-size: 16px; font-weight: bold; display: none; color: red; font-size: 16px; color: red; font-size: 16px; float: right; Note - this doesn’t include browser styles so is incomplete, but hopefully you get the idea div font-size: 16px;

  66. Not all dom nodes are rendered to the screen #codecamp

    The <head> tag, for example, has no visual element. Neither does anything with display: none.

  67. For example - render tree #codecamp div p span body

    font-size: 16px; font-weight: bold; font-size: 16px; font-size: 16px; color: red; font-size: 16px; float: right; text text img font-size: 16px;

  68. BTW, some nodes have more than one element to render

    #codecamp Take a select box for example Select an item Item number two Item number three Item number four Item number one Input Button Dropdown box

  69. Some nodes are also present in a different position #codecamp

    That is, the node is present both in the DOM tree and render tree, but not at the same point. Eg, an absolute or fixed positioned element

  70. Previous example with an absolutely positioned img #codecamp body span

    div p span img body {
 position: relative } img {
 position: absolute; }

  71. Where does the visual property information come from? #codecamp It

    comes from a few different places: - the browser’s defaults - user stylesheets - author stylesheets (those from the developer) - inline styles

  72. #codecamp style rules can appear multiple times The order of

    these rules is very important

  73. #codecamp not only does the browser have to keep track

    of the order, but also calculate the specificity

  74. #codecamp Example - different sources of css /* Browser defaults

    */ body {
 font-family: serif; } /* Author styles */ body {
 font-family: sans-serif; } #header { font-family: Helvetica; } h1 { font-family: ‘Comic Sans MS’; } <body> <main> <h1 id=“header” style=“font- family: Impact;”>Hello!</h1> </main> </body>

  75. #codecamp GECKO creates an extra couple of trees for styles

    - a rule tree and a style context tree

  76. #codecamp Example - here’s some html and some css /*

    1 */ div { display: block; text-indent: 1em; } /* 2 */ h1 { display: block; font-size: 3em; } /* 3 */ span { display: block; } /* 4 */ .un { text-decoration: underline; } <body> <div> <h1>Birdy bird</h1> <span class=“un”>Name: <strong>Spotted shag</strong></span> <span>Family: <em class=“un”>Phalacrocoracidae</em></span> </div> </body>

  77. #codecamp Example - This would be the dom tree <body>

    <div> <h1>Birdy bird</h1> <span class=“un”>Name: <strong>Spotted shag</strong></span> <span>Family: <em class=“un”>Phalacrocoracidae</em></span> </div> </body> div span.un h1 em.un span body strong

  78. #codecamp Example - th is would be the rule tree

    /* 1 */ div { display: block; text-indent: 1em; } /* 2 */ h1 { display: block; font-size: 3em; } /* 3 */ span { display: block; } /* 4 */ .un { text-decoration: underline; } A (null) C: 2 E: 4 B: 1 F: 4 D: 3

  79. #codecamp Example - this would be the style context tree

    body div span.un h1 span em.un strong B: 1 C: 2 A: null E: 4 F: 4 D: 3

  80. There are also hash maps for quickly looking up styles

    #codecamp Both gecko and webkit implement a few different hash maps for storing references to styles - ids - classes - tags - general

  81. #codecamp We have our styles, now we need to calculate

    layout

  82. determining layout positions is a recursive process #codecamp To figure

    out the exact position of each node in the render tree, we start at the root and traverse it to compute the geometry of all nodes. <body> <main style=“width:50%”> <div style=“width:50%”>
 Hello! </div> </main> </body> Hello! Viewport (size = device width) div (50%) div (50%)

  83. Layout - briefly #codecamp 1. A node determines it’s own

    width 2. Over all the nodes children: 1. A child x and y positions set 2. Layout is called on the child if necessary 3. The parent uses the childs accumulated height to determine it’s own height

  84. #codecamp

  85. #codecamp small changes to the dom should have a proportionally

    small processing time

  86. #codecamp Final step - paint all the things

  87. #codecamp each node in the render is painted individually

  88. Painting things happens in a certain order #codecamp 1. Background

    colour 2. Background image (which includes gradients) 3. Border 4. Children 5. Outline

  89. We’ve finished rendering! we can now interact with stuff

  90. Places where this info came from #codecamp HTML5 Rocks article

    (from 2011, but very in depth) http://www.html5rocks.com/en/tutorials/internals/howbrowserswork Google’s BlinkOn internal talks https://www.youtube.com/channel/UCIfQb9u7ALnOE4ZmexRecDg Google Developers https://developers.google.com/web/fundamentals/performance Mozilla - Gecko overview https://wiki.mozilla.org/Gecko:Overview

  91. @jamesmacfie Thanks #codecamp

  92. #codecamp