How browser rendering works
How exactly do browsers render websites? I’ll deconstruct the method shortly, but first, it’s important to recap some basics. A web browser could be a piece of software that loads files from a distant server (or perhaps an area disk) and displays them to you — with user interaction. However, within a browser, there’s a bit of software that figures out what to display to you supported by the files it receives. this is often called the browser engine. The browser engine may be a core software component of each major browser, and different browser manufacturers call their engines different names. The browser engine for Firefox is named Gecko, and Chrome’s is termed Blink, which happens to be a fork of WebKit.
Computer receiving data
Got that? The browser reads the raw bytes of knowledge, and not the particular characters of code you’ve got written. Let’s move. The browser receives the bytes of knowledge, but it can’t really do anything with it; the raw bytes of information must be converted to a form it understands. this is often the primary step.
From raw bytes of HTML to DOM
What the browser object must work with could be a Document Object Model (DOM) object. So, how is the DOM object derived? Well, pretty simple.
First, the raw bytes of information are converted into characters.
Bytes are converted to characters
You may see this with the characters of the code you’ve got written. This conversion is completed and supported by the character encoding of the HTML file. At this time, the browser’s gone from raw bytes of knowledge to the particular characters within the file. Characters are great, but they aren’t the ultimate result.
Characters Are Converted To Tokens
So, what are these tokens? A bunch of characters in a very computer file doesn’t do the browser engine plenty excellent. Without this tokenization process, the bunch of characters will just lead to a bunch of meaningless text, i.e., HTML code — which doesn’t produce an actual website. after you save a file with the .html extension, you signal to the browser engine to interpret the file as an HTML document. Within the parsing process, and particularly during tokenization, every start and end HTML tag within the file is accounted for.
The parser understands each string in angle brackets (e.g.,) and understands the set of rules that apply to every one of them. as an example, a token that represents an anchor tag will have different properties from one that represents a paragraph token. Conceptually, you will see a token as some variety of organization that contains information on a couple of certain HTML tags. Essentially, an HTML file is countermined into small units of parsing called tokens. this is often how the browser begins to know what you’ve written.
A Conceptual Illustration Of A Token
Tokens are great, but they’re also not our conclusion. After the tokenization is finished, the tokens are then converted into nodes. you will consider nodes as distinct objects with specific properties. In fact, a far better thanks to explaining this can be to determine a node as a separate entity within the document object tree. Nodes are great, but they still aren’t the ultimate results.
Now, this is often something we will work with.
An Example DOM Tree Graphic
If you remember from web design 101, you don’t open the CSS or JS go in the browser to look at a webpage. No — you open the HTML file, most times within the form index.html. this is often exactly why you are doing so: the browser must undergo transforming the raw bytes of HTML data into the DOM before anything can happen.
HTML Goes In First
Depending on how large the HTML file is, the DOM construction process may take your time. regardless of how small, it does take it slow, irrespective of the file size.
