Most of the time, if you ask someone how a web browser works, they will say it is used to display a web page. A slightly more technical answer might be, it downloads a web page and associated files, and displays it based upon the HTML codes.
While this is correct, it is correct only at a most basic level.
A web browser does several jobs for the end user to make it so the browser can see a downloaded file.
The first step is that it downloads the requested web file. This could be from a user clicking on a link from another web page, pulling something from their favorites/bookmarks, or typing in the address directly.
As the file is being downloaded, the browser will start to parse the file so it can build the DOM, or Document Object Model. This, in conjunction with the external files, is how the browser will determine what it will need to display.
As it downloads the source file, it tracks all of the external file references it needs to know about to load and display the page. This includes external web pages in an iframe, CSS documents, JavaScript files, images, etc. It adds these files to a download queue.
Because of the queue, it will start to download those files in the order it finds them. Early web browsers could only download a couple of files at a time. Most modern web browsers will download between eight and sixteen files simultaneously from the same domain. If you have multiple domains, you can increase the number of files being downloaded in parallel.
Once it downloads the external file it will parse those files looking for external references as well as adding more files to the download queue if necessary.
Everything seems to run smoothly, until you get to a JavaScript. Because JavaScript files can be run once they are downloaded and modify the contents of the HTML document the browser pauses downloading any more files once it starts to download a JavaScript file. It will also pause rendering of the screen for the same reason. This process is called blocking.
Because JavaScript by default is considered to be a blocking call, it is recommended that all JavaScript be placed at the end of the HTML document, just before the closing body tag, or be given the async attribute which holds off on the auto rendering.
As the styles are downloaded, the browser starts to determine how to display the web page. This means that styles and CSS files should be placed higher up on the page, preferably within the head tag. It will start displaying the web page as it can, modifying the flow of the page as missing content is downloaded and ready to be displayed.
The Browser Wars Continue
Years ago there were the “Browser Wars” which each browser attempted to one up the other with new features and compatibility with their interpretation of the specifications. This lead to webpages not necessarily looking the same when viewed with different browsers.
Now these wars continue, but not quite as they used to. Now they focus more on security, speed, and meeting all of the specification, rather than trying to add to the specification.
Most browsers have a separate engine for running the JavaScript. This allows one team to focus on developing JavaScript engines and another to focus on display speed for static HTML. This can also mean it’s hard to determine the “fastest” browser.
Google’s Chrome has spent a lot of time on their JavaScript engine and it is the fastest of the main browsers. If you look at the Google properties, such as GMail, Google Docs, etc, they use lots of JavaScript, so this makes sense that they would want a faster JavaScript engine as it makes their own properties look good.
Microsoft’s Edge on the other hand tends to be faster for static content or where there is just a little JavaScript because they tend to have more static websites for their main users. Microsoft’s web properties and products tend to use less JavaScript.
This is one of the issues that web developers have to work around – knowing that there are several main browsers, each with their own strengths and weaknesses, and you can’t control which browser a person who visits your website will use.
How a Web Browser Works was originally found on Access 2 Learn
