It will not be accurate pure performance of loading the page.
It is summary of all processes running, including QTP, scripts, AUT and so on.
Pure loading time is possible to take with specific performance tools only ("LoadRunner", for example).
But it is good enough for comparison if you run TestCase every build. At least, you can say: if page loading is faster or slower.
Another issue to consider is the technology used to implement the web page being loaded. I recently did some testing on a Sony online game retail site and they use client-side AJAX (back channel) "conversations" with the server to dynamically load products available for each user (product availability is based on age and other factors). In this scenario QTP often finds the browser is "ready" (i.e. browser sync returns TRUE) before the page is "fully" loaded with all product images--where the images are being downloaded via one or more AJAX back channel(s).
This normally causes no problems with QTP because if you (1) load the page and then (2) click on say the third product image, QTP will implicitly wait (with a timeout) for the third image to appear and be enabled. But this scenario will definately give you false load times with the above suggested approaches. And I don't see a reliable solution for determining the "full" page load time (i.e. browser ready with ALL product images loaded as well) in the scenario I describe (using QTP).