It described the browser as single threaded, but then talked about multiple concurrent tasks. Aren't those threads?
One more question: are there any browsers that use multiple threads to lay out the various object models and render the page? If it's been found to be too difficult, what were the issues?
Parallel layout is generally considered to be a complex engineering problem by domain experts.
Rendering the page, as in deciding the colour of each pixel and putting them on the screen, based on the layout, style, and various other things, can be done with lots of parallelism, on the CPU or on the GPU (that is preferred on most platforms in production browser engines, these days).
https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... is a really cool article that is related, that is a few years old but what it says is largely correct today.
Browsers are not literally implemented in a single thread.
Javascript execution is determined by an event loop. Events are queued up by whatever means the browser implementer wants as long as there is only a single thread actually consuming the events. This is where the notion of being "single-threaded" originates. The web developer assigns handler functions to event listeners which are called by this consuming thread later when the event occurs.
This kind of concurrency is cooperative multitasking. The code is executed asynchronously, but not in parallel.
The renderer is the entry point since the HTML contains the CSS and JS tags. Generally speaking, the HTML is rendered line-by-line in the order the tags are written, but in practice there are some aspects that deviate from this such as the "async" and "defer" attributes for script tags as well as any HTML or CSS requiring network requests that cannot block rendering the rest of the page (img tags, url CSS values, etc.)
Naturally this ability to make network requests is implemented as a thread pool (at least on modern browsers), but any Javascript waiting on that would not execute until the event is consumed and its handler is called which preserves the illusion of being "single-threaded". As for loading images, fonts, etc. from CSS/HTML, the developer cannot control when they are loaded and rendered. Anything that really does need threads is handled by the browser already.
(Browser is here, very early stages, not appropriate for any kind of use really while I move to fltk: https://github.com/jmthackett/freeflow )
Annoyingly it segfaults a bit at the moment, but it'll get there with time.
Also, I love mdn. To this day it's the best technical writing about web development. Every concept is so well explained.
I would like one that goes a little bit deeper into the initial part of the Browser-Server interaction (but still readable in one sitting). Touching things like the headers sent by the browser.
The response is the similar. But starts with the status line, the headers, then the body (not HTML body, but the payload of the response:
HTTP/1.1 200 OK Date: Fri, 13 Oct 2023 15:04:05 GMT Server: Apache/2.4.41 (Unix) Last-Modified: Mon, 9 Oct 2023 16:30:00 GMT ETag: "2d-58e4-4d5f487a7b300" Accept-Ranges: bytes Content-Length: 1024 Content-Type: text/html Connection: keep-alive <html> <head> <title>Example Page</title> </head> <body> <h1>Welcome to www.example.com!</h1> <p>This is a sample webpage.</p> </body> </html>
* https://developer.chrome.com/blog/inside-browser-part1/
* https://developer.chrome.com/blog/inside-browser-part2/
* https://developer.chrome.com/blog/inside-browser-part3/
* https://developer.chrome.com/blog/inside-browser-part4/
Paul's article references it
Shame bad websites and make them chase "green" scores.
Lighthouse is already built into Chrome amongst many other tools. Lighthouse scores are already a factor for search result rankings. The fact of the matter is, those junk sites don't care.
Even if these scores were exposed to the user by default instead of hidden away in a dev tool, it's just not a strong enough incentive for those sites to change or users to care. Rankings are more strongly affected by adwords, time-to-first-byte, link juice, etc.
