Page Render Time
Just like page load time, this is a metric of how quickly a web page is loaded, but this measures the time it takes to actually have the web page ready for the visitor to use and interact with. While load time measures the actual time in takes to download images, Js, CSS and other objects in to the visitors browser, render time measure the time it takes to actually process these and show their end-result to the visitor.
Nowadays with heavy use of CSS & JavaScript in web pages, the load time is not always the most accurate metric to determine delay experienced by visitors. Some external content can take many seconds to load even after the actual on-site content of a web page has already loaded.
While not limited to it, client-side A/B or multivariate testing can be one of the legitimate reasons for a longer page render time, as most platforms offering testing such as Google Website Optimizer and Omniture Test & Target employ methods to populate test areas on a web page after it has loaded using JavaScript. This is not exactly a matter of extreme concern, as well-devised tests can contribute to far better conversion than slightly faster rendering time would; and they usually are active for a limited time per section being tested.
Other reasons why the time needed to render a web page for presentation could be longer than the time it takes to download the individual objects that make up the web page are:
- Processor-intensive demanding code such as compressed JavaScript. While it might be quicker to download a compressed JS file, it may take a visitors computer longer to actually process some such files, adding to the render time.
- Resource-consuming or large CSS files that could take longer to apply formatting to elements on slower computers.
- Dependant code that needs third-party code libraries to be loaded before it is run.
Be a Good Host! Tidy up before Letting People in.
No matter what the excuse for prolonging the final presentation of your web page to the visitor, analyze the visual and tangible effects of having your page partially loaded into the visitor’s browser while other elements are still being processed. If the few seconds between the download and presentation miss critical elements that could impair the use of your web page, disable functionality that is dependent on what has not fully loaded yet. For example, if a link is supposed to load a an overlay bubble into the web-page, load it in disabled state and use code to check the availability of the objects it depends on, and only activate it when you are certain clicking on it will lead to your intended result and not errors or worse nothing!
A great free tool that we use daily to determine our load and rendering times is the Mozilla Firebug add-on for FireFox. Just install, visit the webpage in mind, enable the “Net” panel (i.e. tab), refresh and watch it detail every elements load time broken down quite granularly into connection, download and load times. There are even high-level indicators for major milestones during the page load i.e. when most all objects have been loaded (currently depicted as a blue vertical line), and when all images have loaded in addition to other objects (currently shown as a red vertical line).