Browser Processing Anatomy

  • 2 minute(s) read
Prev Next

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). The server responds with packets of information (usually an HTML document following W3C standards) 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.

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

  1. Start: HTTP transaction 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 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.

  4. 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.

  5. 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