Open Bug 1561532 Opened 7 months ago Updated 8 days ago

Better UI/UX for raced cache feature


(DevTools :: Netmonitor, enhancement, P3)



(Not tracked)


(Reporter: Honza, Unassigned, NeedInfo)


(Blocks 2 open bugs)


This is a follow up for: bug 1358038 comment #81

Users seem to be confused by the additional (race) label displayed in Transferred column.
There is no additional comment and/or explanation and it's unclear what that label actually means.

We might want to introduce a new tooltip explaining what race cache with network means.
We might also introduce a "learn more" icon/link pointing to MDN.


@Harald, any tips what we could do here?

Flags: needinfo?(hkirschner)

Bugbug thinks this bug is a task, but please change it back in case of error.

Type: defect → task

I made the original comment on the other bug. I started seeing (raced) in my network requests but I'm just not sure what's actually happening. Here's an example: That example has 6 raced requests, and I think the first two used the network and the last four used the cache, but I'm not sure. The messaging isn't consistent--you can see further down that cached requests are grayed out and they still have a response code. None of the raced requests are grayed out like I would expect for something loaded from the cache, and some of them also don't have response codes even though the requests have completed.

I ran this by a few other devs and none of us were able to fully understand what's happening. The concept of racing is simple enough (once I found the bug that explained it), but I don't know how to interpret the network tab with raced requests.

@Harald: what do you think? Tooltip and MDN icon? Anything better?

Type: task → enhancement
Priority: -- → P3

Looks like we should have enough space to show a (?) help icon with a link to MDN, and add a title-tooltip to add additional context to "race", for example "This request was loaded from network as the cache was too slow" or "Loading this request from cache was too slow, so it was loaded from the network".

Given that this is impacting developers with in-deterministic behavior and that race isn't an easy concept, MDN needs to create a page to describe the why and how of RCWN.

Blocks: RCWN
Flags: needinfo?(hkirschner)

(In reply to :Harald Kirschner :digitarald from comment #5)

That explanation helped me too much. Because just the label (raced) didn't help me to understand the concept.
But now I know and this information can be very useful.


I started seeing this some time ago and finally decided to look it up.
I first went to but under Transferred it only states that:

Transferred: The number of bytes that were actually transferred to load the resource. This will be less than Size if the resource was compressed. From Firefox 47, if the resource was fetched from a service worker cache, then this cell displays "service worker".

Then I found via"(raced)".
I read the entire thread but actually the first tree posts was enough:

The RCWN feature in Necko adds the ability to race the cache with the network when the cache is slow. So if reading from the disk is slow, we will send a network request, and return the channel from the network, even though we have the entry in the cache. This way we provide the content to consumers faster.

Our concern is that requests that load from the network instead of the cache will confuse users, and they will think there is a problem with their caching headers, or with Firefox's caching. We want to avoid that by showing them why it loaded from the network instead (because we raced).

This information should really be added to MDN and preferably not in a corner like, but at least it should be mentioned there. Actually, that would probably be the best place to explain the race concept, with a link from devtools to it. Alternatively it could be mentioned at which there is already a link to in devtools (in the Timings pane after selecting a request in the network pane).

:honza, what do you think about a line in the details panel with a link to MDN?

Flags: needinfo?(odvarko)
You need to log in before you can comment on or make changes to this bug.