Several questions here - and rather confused terminology.
how long it takes to deliver a page, not dependant on network latency or bandwidth
But how long it takes to deliver a page is all about network latency and bandwidth. Also, the webserver has no concept of "pages" - only URLs - typically a page as view in a browser will be composed from multiple URLs, hopefully some of them will be cached. While there are some very expensive tools which try to derive page load times serverside, I've yet to see one which works well with caching and/or PRG.
%D logs the time between Apache starting to process a request (i.e. I believe it omits the handshake) and offloading it completely onto the local TCP stack.
You cannot measure just the time it takes to process the request and compose the response.
There is an Apache module which allows you to record when the response started - but that's only an indicator of when the complete response was available.
OTOH, if you use a reverse proxy close to the webserver, the network overhead will be minimal.
But this is still talking about URLs - not pages.
If you want to measure page response times, then take a look at episodes / yahoo boomerang / HTML5's webtiming API
Note that these are all about measuring end user experience - so the metrics are affected by the network. Boomerang incorporates functionality to measure baseline network perfromance.