RSS Feeds

The Anatomy and Timing of a Web Request – Part I

My academic background was mathematics, specialising in operations research and statistics.  I put this to good use when I first started my career in an IT consultancy, in working one the development and use of detailed simulations of large-scale Army Command and Control Systems.  You might wonder what on earth modelling large voice communications networks over thirty years ago has to do with using modern web services, but in fact the conceptualisation and analytic techniques are very similar, (though the time constants involved have shrunk from seconds to milliseconds).  This foundation in modelling and analysing large communicating sequential systems has proved invaluable in my work in systems optimisation during my career, and has influenced my approach to systems engineering.

What I show in this article is that:

Using the Google Chrome network analyser

I now want to explore a typical phpBB query in depth, and in one specific case: displaying the phpBB community forum’s board index.  To understand what goes on in the interval between a user clicking the board index link and the time taken to complete page is assembled for viewing, you need to have a suitable tool to instrument this process.  I recommend using Google Chrome, because the developer tools that you need are part of the standard download (though most modern browsers have an add-on pack which provides similar functionality).  The main view that I will use to do this instrumentation is the Network Panel.  You can access this when visiting any website with Chrome by typing Shift+Ctrl+i whilst viewing the page.

What I want to do first is to discuss the base case when the browsers local cache is empty.  This Chrome explorer window is active so you can click on different options and objects to drill down for more information.  Alternatively, you can right-click and select “Export all to HAR” which copies the analysis content to the clipboard in JSON format, then paste this into a test editor and save it to file.  I have written a simple PHP filter, (which you can download from here) to convert this HAR format into tab-separated variable (TSV) for loading into Calc or Excel for further analysis (which is what I do).  To give you some idea of what this tool does, the screen snapshot to the right shows the display for this index page.  (Click on the image to get the full-size version).

If you look at the zoomed figure, then you will see that it took my browser some 5.02 seconds to download the 55 files comprising some 314 Kbytes needed to render the page.  Revisiting this page later in the same browsing session took some 1.06 seconds and this time nearly all files were already cached locally on the PC with only 2 files comprising 9 Kbytes needing to be downloaded.  If I did a “page refresh” then the time increased to 3.51 seconds but with still only 2 files comprising 9 Kbytes needing to be downloaded.

Note that the figures that I quote here are the main milestone reported by the network tool, and that is when the main page has been rendered and is stable to the viewer.  The DOM content load might be an earlier time milestone, but if images of HTML/CSS-undefined size are to be viewed, the view will still jerk around as these load.  Further images may continue load and javascript download and fill in content (but this are not visually distracting to the user reading the page) before the “onload” event fires.  So the network tool reports all three separately.

The user experience on these extremes is very different: on the first view the page is terribly sluggish and stuttered during loading; on the second it is almost a case of click-2-3-bang and the page was displayed.  Note that whilst the exact timing will vary from request to request, the general timing pattern will be similar.  I want to look at little more into the loading timeline and consider why were these are so different.  In the HTTP 1.1 protocol, the individual requests are multiplexed over shared TCP/IP connections, and by convention, the browser will open up at most two such streams per host site referenced.  Each request can be thought of as a Remote Procedure Call (RPC) from the browser, where the input parameters are a set of request headers, and the output is a set of response headers with an optional content.

The timeline for the phpBB communitiy website bulletin index

Timeline (mSec)
(cache empty)


0 - 873
0 - 975
0 – 898

The core index.php request does the bulk of the application processing and outputs HTML document.  As pbpBB does all its processing before it generates its output, this appears as delay then a content download from the browser perspective.  The download is streamed into the browser parser, and the first thing that it does parse the HTML header, so the header javascript and CSS files referenced can be processed before the content has been loaded.

598 – 2,132
667 - 706
643 - 1.498

The 5 javascript files linked in the header are downloaded.  These total 107Kbytes and are uncompressed.

1,903 – 3,204
708 - 732
1,255 – 1,986

The 9 CSS files linked in the header are downloaded.  These total 85Kb and the static CSS files are uncompressed.  Once these are downloaded the browser now has enough information to start to render the page.  This takes a few tens of mSec.  If the image tags have defined dimensions then the browser can allocate frame-space to hold each image ahead of loading it and subsequently avoid reflow of the page as images download.

3,246 - 5,018
733 - 1,024
2,043 – 3,658

The 40 files linked in the CSS and the HTML body are downloaded.  Image files are already in a compressed format, so no further compression is necessary.  These total 124 Kbytes.  As each is downloaded, the browser adds it to the page.

There is a big difference for the user between a 1 second and a 5 second delay in rendering a web page.  These are typical timings when the phpBB site was relatively lightly loaded.  The variance in response means that the worst quartile will be a lot longer than these times.  The phpBB admins have got a reasonable set of Apache configuration settings have also configured a Varnish caching accelerator to boost response, but these settings still fall short of optimum.  I find the refresh time of ~3.5 seconds quite worrying.  A typical phpBB installer using a shared hosting service with default Apache settings would perform at or below this 5 second mark.  This is quite unnecessary as the .htaccess files can be used to achieve most of the required performance gains.

I have also got an ODS spreadsheet detail (here) for those interested in looking at the detailed figures.  But the main points that I want to emphasise are:

These guidelines are discussed in detail on the Google Web Performance Best Practices page.

Specific comments on the phpBB website

Just looking at this page, I can cast these general observations about phpBB and this site. Given the expertise of the phpBB team, The fact that I can make them about this site shows that they can make quite a difference to site performance if you aren’t careful. This is more an issue of website configuration rather than an application coding one, because my OOo community forums run over 2x faster than the phpBB ones (1.78s vs 5.02s for clear-cache load and 0.47s vs 1.06s for primed-cache load on the trial that I did.)

Programmatic cache negotiation

There are three aspects to ensuring that PHP scripts carry out optimum negotiation with the client browser:

What still constrains performance is the server-side internal overheads of responding to this request, and this will be the subject of my next article.

Post a comment

Please note that your name is required and that all posts will not be visible until authorised by an administrator.

  A valid mail address must be supplied
A cookie will store your name/url for three months
 Sorry, but you must answer this easy sum as a SPAM prevention measure.

You should be aware that all information on blog site is © Terry Ellison 2010 and made open access under the Creative Commons Artistic Licence.

Your comments will only publicly available after you have carried out email confirmation. Your email address will only used for this purpose and is not made public.

Comments that are not confirmed will be automatically deleted after 7 days.

The blog author reserves the right to delete comments which breach copyright or the rules of site etiquette as he determines (such as unnecessary use of obscenity or spam content).