---
title: "Browser Processing Anatomy"
slug: "browser-processing-anatomy"
updated: 2023-01-19T21:19:20Z
published: 2023-01-19T21:19:20Z
canonical: "docs.catchpoint.com/browser-processing-anatomy"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.catchpoint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser Processing Anatomy

Web browsers are the primary tools used to interact with content on the World Wide Web. It is important to understand how browsers handle content in order to debug possible impacts to performance. 

Browsers follow a client/server model; the browser runs as the client on a local computer and contacts a remote server with requests for information (generally using HTTP protocol which is described [here](https://www.catchpoint.com/blog/http-transaction-steps)). The server responds with packets of information (usually an HTML document following [W3C standards](http://www.w3.org/TR/html5/)) which the browser interprets and displays on the screen in the browser window. Multiple requests might be needed depending on the external resources referenced by the web page. The location of the information is specified by a URI (Uniform Resource Identifier), generally in the form of a URL (Uniform Resource Locator). This article focuses primarily on how a browser processes an HTML document and the components described within it. For a more indepth look at all the components and code that make up a browser, read [this wonderful article by Tail Garsiel](http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/).

<img src="https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/201441559-browserproc.png" width="695" height="308" />

 Browser processing of a web page is made up of five main components\events:

1.  **Start:** [HTTP     transaction](http://blog.catchpoint.com/2010/09/17/anatomyhttp/)     takes place. The browser resolves the entered domain name via DNS, connects, sends an HTTP request to the server for information, waits for responses, and then downloads the HTML file. Catchpoint’s **Response Time** metric measures from **Start** until it receives the base URL.

2.  **HTML Parsing Start:** The browser starts parsing the flat text HTML file inline from the base URL and begins building the Document     Object Model (DOM). This is where the nodes JavaScript references     are created. Text elements without styling will begin showing in the     browser window. As the HTML document is being parsed, the browser     will begin downloading external files referenced in the main HTML.     This includes external JavaScript files, images, CSS, etc. The     browser downloads them in the order they appear in the HTML     document. This is why it is considered good practice to place style     sheets at the top of the HTML code to ensure the style sheet is     available when objects are drawn. Please click [here](http://stevesouders.com/hpws/js-middle.php) to see an example provided by Steve Sounder using JavaScript.

3.  **DomContentLoaded:** The Browser finishes parsing the text of the HTML file to build the DOM and renders it to the window. Now styling elements such as CSS and images can be applied. This is when the browser starts rendering items other than text in the browser window.
    1.  JavaScript can trigger based off this event
    2.  JavaScript and CSS can trigger more HTTP requests for objects not referenced in the original text of the main HTML document file.
    3.  Depending on how the browser handles progressive rendering, multiple repaints can occur after DomContentLoaded due to styling being applied. For more information please see Steve Souder’s example located [here.](http://stevesouders.com/hpws/css-fouc.php)

5.  **onload:** Browser finishes rendering the html document and downloading the external files needed to do so. The user can now interact with the web page and user it. This is considered **Document Complete** for Catchpoint metrics.
    1.  Like DomContentLoaded, JavaScript can be triggered and cause more HTTP requests to load dynamic content.
    2.  An example of this is Catchpoint’s Real User tag.
    3.  This dynamic content loading is a factor behind the two-second window in Catchpoint’s **webpage response** metric.

6.  **unload**: Browser unloads rendered data in window. This is the event of exiting the browser or tab, loading a new web page in the browser window, or refreshing the page.
    1.  Can also trigger JavaScript.
    2.  Most commonly used for alert window’s asking users to confirm their action.

See Also   [Catchpoint Metrics ](https://docs.catchpoint.com/docs/Catchpoint-Metrics)