nicjansma
commented
3 years ago Hi @ThierryMajutec,
That's correct, the time listed as AppCache in the diagram below is bound by fetchStart and domainLookupStart, and should mostly represent time taken by the browser to check the local browser cache (i.e. to decide if it needs to fetch something from the network):
The fetchStart attribute definition mentions this:
fetchStart must return the time immediately before the user agent starts checking any relevant application caches.
Do you confirm that the waiting time in case the browser has already established 6 TCP sessions to the same hostname and waits for a slot to be available ?
I think most of the "blocking time" (when waiting for an already-established connection to be free) will be between connectEnd and requestStart instead.
Are there any other main reasons to have significant AppCache value ?
Not that I'm aware, but each browser is free to do whatever work it thinks is necessary during the fetch timeline. At mPulse (a RUM provider) we have generally assumed time between fetchStart and domainLookupStart was mostly cache lookup time (i.e. time it takes to spin up the disk and check if content exists/is usable or not).
I was curious to see how frequently we see time spent during the AppCache block above. I looked at our mPulse RUM data, and over a few billion page loads, I see:
- 28% of page loads have at least 1ms difference between
fetchStartanddomainLookupStart - 50th percentile App Cache duration is 8ms
- 75th percentile App Cache duration is 29ms
- 95th percentile App Cache duration is 253ms
If we look at just App Cache durations from 0ms to 1,000ms, we see a lognormal distribution of times:
The last bucket at 1,000ms in the first graph represents all data taking at least 1,000ms or higher.
The second chart zooms into the durations from 1,000ms to 60,000ms (i.e. the final bucket in the first picture). There's a an interesting spike at 10,000ms (10s) and another small one at 20,000ms (20s). My guess is some browsers have cache-lookup timeouts at 10s/20s, and go to network instead?
Anyways, I'd be curious if any browser developers know differently, or if there's other common work done between those two timestamps.
By the way, though it's called AppCache in the diagram above, I don't believe this is supposed to be a reference to the AppCache browser feature that is being removed. It's meant to just be the "App Cache" lookup time.
noamr
yoavweiss
AppCache defined in the Time Navigation API does of course correspond to the time it takes by the browser to check the cache, but not only I guess. Do you confirm that the waiting time in case the browser has already established 6 TCP sessions to the same hostname and waits for a slot to be available ? Are there any other main reasons to have significant AppCache value ?