Clever Geek Handbook

Engines in the browser - how do they interact?

I've been trying to find out more under the hood when it comes to web development, JavaScript in particular, and how different mechanisms interact with the JavaScript engine. For example, I know the rendering engine communicates, HTTP requests, etc. I'm just wondering when the JavaScript Engine should send data to another engine, for example, the rendering engine, how much more computational power does the JavaScript engine run when the data is received?

+3


source to share


3 answers


The web is a standardized platform that runs at the application layer of the Internet Protocol Suite .

It is a hypermedia system consisting of a protocol (HTTP), a markup language, a style language (CSS), and a browser API (web API).

The web was developed in earlier hypermedia systems such as HyperCard and uses a similar event-driven single-threaded process.

The crux of your question is: "How do different parts of the browser interact with a web page?"

The answer is a mixture of vendor-specific implementation and standardized behavior as defined by the W3C and WHATWG standards bodies.

A high-level rendering process might be something like this:

The incoming message is displayed in the browser application by the network operating system subsystem (which in turn received the stream through the TCP IPS transport layer) as a byte stream encoded using UTF-8.

Thus, the browser's networking subsystem receives an octet stream as input to UTF-8.

The browser will most likely process the incoming byte stream in a stream or process other than the one coordinating the rendering of the UI to avoid blocking the browser.

The browser understands the textual HTTP protocol Tim Berners-Lee invented in 1989 and interprets the incoming bytes as an HTTP message.

The body of the message will match the markup of the page. As soon as the page markup is received, it will be streamed for rendering.



Starting at the top of the markup, the browser rendering process will start parsing according to the algorithm defined by the W3C / WHATWG .

When JavaScript is encountered, it tends to run immediately, but there are complex rules about what happens when.

When resource links (eg images, scripts, stylesheets) are encountered, requests to download them will be made. Some will block the rendering process, some won't.

When a piece of JavaScript is encountered, evaluating it will usually block the UI. This is because a single thread of execution has been developed on the web to control the rendering of a page, and JavaScript is part of that process. As far as I know, multi-threaded UI rendering systems are unusual due to their complexity (although I could be wrong about that).

This way the browser will extract JavaScript from the markup (or associated script resource) and pass it to the JavaScript engine for evaluation. JavaScript runtime is an application that allows you to evaluate a language based on a stack. It has a stack and a heap and logic to transform a JavaScript script into a form that the processor can understand.

There are zero or more stack frames on the stack. JavaScript stack frames are named execution contexts. The execution context is like a bookmark in a book and helps the runtime keep track of where it is in script execution. It is only when the stack is empty of execution contexts that the browser can continue its rendering work - so yes, running JavaScript will usually block rendering.

Communication between different browser subsystems (networking, JavaScript runtime, rendering) will happen through a heap dedicated to the browser process, or if the browser is multiprocessor, communication mechanisms between processes opened by a particular operating system (for example, named pipes).

Once there is enough (according to the W3C specification) markup (HTML) and styles (CSS), and enough from the script (JavaScript), the rendering will be done.

Rendering is a vendor specific process, but most browsers will feel like a high level. Each HTML element is processed in turn. Chrome uses the following sequence for each element on the page:

  • The JavaScript that is applied to the element is evaluated.
  • The CSS styles applied to the element are evaluated.
  • The element is positioned on the page accordingly.
  • The element is colored with a bitmap (colored pixels).
  • The element is composed. This is the final look he calculated according to the impact of various layers of other elements on the page.

This process can be repeated several times on any element, depending on the content of the page and the changes made dynamically using scripts.

+1


source


Typically computers can perform billions of calculations every second. However, the render stream only refreshes 60x (refresh rate / VSync) and network requests are much slower. Offloading them per thread is cheaper compared to blocking waiting.



Another reason for unloading a drawing is to make the interface attractive: even if something is running in the JS thread, the loaded render thread will still react as usual.

0


source


Very rude, as it is:

  • The browser receives the HTML page (or HTML data that was sent to it).
  • The browser starts to interpret and process the page
  • In the section head

    , if it sees any external linked files such as JavaScript and CSS files, it immediately triggers a download request.
  • If there is JavaScript, either in HTML or in a linked file, JavaScript is executed immediately, unless it uses a newer option async

    . This is why JavaScript usually includes an event handler when the document has finished loading.
  • The rest continues ...

When taking a break, please note that material is head

processed as it is received, not later.

  • Content is body

    processed from top to bottom.
  • While this is happening, a DOM (Document Object Model) is created.
  • HTML content is displayed.
  • Any additional external data such as images will trigger its own download requests. This content is loading in parallel, not waiting. This is why poorly designed HTML often leads to redrawing after images are loaded.
  • The CSS that has been loaded so far is being applied simultaneously.

This is for static content. There is one more step, if you have JavaScript that changes the content:

  • JavaScript can change the content of the document at any time.
  • Often, but not always, changing content can cause redrawing. This will be necessary if the change affects the layout.
  • JavaScript can also change individual CSS styles of HTML elements. Again, this can cause redrawing.
0


source






More articles:


All Articles