Page MenuHomePhabricator

Track cache hit ratio in Navigation Timing data for resources
Closed, ResolvedPublic

Description

With the Resource Timing V2 coming to Firefox (it's in FF45) it gives us a really cool thing: By checking the transferSize of a resource we can know if it is picked up from cache or fetched from the server (transfer size is 0 when it's from cache). Chrome has it on its 2do list hopefully for Q2.

We need to think of how we can use it. Should we collect how many of the requests that are cached? Should we categorize Navigation Timing data as cache hits or not?

I'll add upstream as we probably want Chrome on board before we start using it, but we can prepare and think of how we best can use it before it's implemented.

Event Timeline

Peter created this task.Mar 17 2016, 5:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 17 2016, 5:39 PM
Krinkle added a subscriber: Krinkle.EditedMar 17 2016, 7:45 PM

It would certainly be very useful for performance analysis of ResourceLoader to be able to get telemetry into local cache hits.

Right now it's quite difficult to determine a regression in ResourceLoader. People sometimes look at HTTP 304 response rates to see how well ResourceLoader is performing but that's quite terrible. If a browser has a cache copy then ideally it would just use it. There would be no need for it to make an If-None-Match request, there'd be no need for the server to respond with HTTP 304.

And as such, our 304 response rate is extremely low (80% is HTTP 200, <20% is HTTP 304) - and that's brilliant. I would consider a 304 request to be an error, a regression. The reason it is as high as it is is because we have two major requests in our frontend (startup module and stylesheet) that don't have a version query parameter in the url, and as such require the browser to check for the latest version quite often.

Being able to track cache hits client-side would give us a more complete picture.

Krinkle triaged this task as Medium priority.May 26 2016, 3:13 PM
Peter added a comment.Jun 2 2016, 6:51 PM

One important thing that @Krinkle found out: Firefox do not include local cache hits in the resource timing list. 304 are included but not local hits. Chrome includes them both.

One thing that people do in practice (see https://www.youtube.com/watch?v=yrWLi524YLM) is that they check the actual timings in ResourceTimings. If times are between 0-10 ms they are always cache hits (maybe up to 40 ms). For us with the 304 that will not help us.

Peter added a comment.Oct 13 2016, 5:59 PM

With Chrome 54 we get encodedBodySize, decodedBodySize and transferSize! Lets try it out and see that it works as expected, then we could start outlining how we can use that.

Peter added a comment.Oct 13 2016, 6:15 PM

It looks promising in Chrome (comparing ResourceTiming with the network tab)

If the file is cached locally the transferSize is 0. For 304 the size is ca 500 bytes and the rest is 200 requests (transferSize over 500 bytes). This is SUPER EXCITING!

Peter added a comment.Nov 8 2016, 8:40 AM

I think we should add an event to report the cache hit ratio in chrome, lets discuss in the meeting on Thursday and I can make a mockup.

Peter added a comment.Nov 8 2016, 9:19 PM

This is interesting how Facebook uses this data from Chrome: https://groups.google.com/a/chromium.org/forum/m/#!msg/net-dev/DGVo2J4GKzc/pH1U2gOdAQAJ (and check the long load time from cache).

Krinkle changed the task status from Open to Stalled.Jul 29 2017, 4:45 AM
Peter closed this task as Resolved.Sep 12 2017, 3:02 PM
Peter claimed this task.

We will not get any extra information out if this: The HTML is never cached. JS/CSS for 5 minutes, images never.