We have now reached step 6 of the web cycle and are back at the web browser.  The web browser is receiving an initial HTTP response from the web server. The first part of this response tells the web browser is whether or not the web server is delivering some useful information.  That happens via the response status, which will be 200 OK if the HTTP request is being properly fulfilled.  The second part are additional so-called response headers which provide information about the content that is contained in the response.  And the third part is the actual content.

For today, we will examine the case where the content consists of a web page in HyperText Markup Language or HTML. We will have an entire Tech Tuesday on just HTML in the future but for today we will focus on just one aspect of HTML which is critically important to understanding the web cycle: the (frequent) need for additional requests to be made to the same and/or other web servers. Leaving aside the “how” for a moment, HTML describes what is on a web page.  On my blog here the page consists mostly of text, but in the sidebar titled Shapeways, you are seeing several images of 3D printed objects.

When your web browser made its first request to this page, the HTML that came back did not also contain those images!  Instead, it contained information that told your web browser to go to a different URL from the URL of the page and request those images there.  In fact, every image that you see on a page (generally) requires a separate HTTP request to fetch the data for that image.  Each of those requests invokes the entire web cycle that we are just going through.  Now I just counted and an initial request to the frontpage of Continuations, spawned an additional 53 (!) requests to get all the pieces needed for that page.

How did I determine that?  I use Google Chrome as one of my web browsers and it has a set of developer tools built in that let you inspect what happens when a page is loaded.  To see these go to the “View” menu and select “Developer Tools” from the “Developer” sub menu (these are the Mac OS X instructions but I am assuming Chrome for Windows has a similar menu). This will give you an additional window.  Select the “Network” button, go back to your primary browser window and reload the page.  You should now see something similar to this:

This is a list of all the requests the browser is making to get the pieces necessary for this page.  For each request you can see what was requested from where and how long that request took to complete. Apple’s Safari web browser has a similar developer menu built in as do the latest versions of Firefox.

What is the take away from today?  Even before it gets around to figuring out how to display all the content that it has received, a web browser does an awful lot of work just sending out requests to receive all the various pieces of a web page.  These requests are sent more or less in parallel (as the image above shows) because if they were sent one after the other, the page would take a very long time to load. In turn each of these requests hits a web server somewhere that needs to respond.  All of that runs over the network.  We take the fact that a web page loads quickly almost for granted these days and yet fundamentally the fact that it loads at all given everything that goes on is quite remarkable.