Open Bug 1338065 Opened 8 years ago Updated 2 years ago

cached and 200 OK - Improving the visual layout of resources fetched from the browser cache

Categories

(DevTools :: Netmonitor, defect, P3)

53 Branch
defect

Tracking

(Not tracked)

People

(Reporter: karlcow, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

It's a couple of time I'm getting bitten by this UX/design issue in netmonitor.

Context:

Let's say you have a Web site sending a response with Cache-Control and Etag headers. For example:

    Cache-Control: private, max-age=3600
    Etag: "foobar"

The server tells us:
1. This resource has a lifetime of 1 hour for the Cache
2. During this 1 hour, use the resource in the cache
3. After this one hour, subsequent request will be sent 
   with a 'If-None-Match: "foobar"' to check if the resource 
   has changed.

The first request gives a 200 OK and the browser generates a caching key for future validation. Then the next request, the browser doesn't hit the network and just uses the cached resource.


My Issue:

In the network panel, the line is showed as
* a gray circle 
* 200 (when we over we get a "200 OK (cached)")
* usual information
* Transfer says cached

when the resource line is clicked, we get the panel with headers fully displayed AND (0 B) beside the request and response headers.
Response gives the response payload.


I wonder if there would be a better way to convey the information that there was no interaction with the network at all. Probably the 200 is the thing which misleads me each time, because it is somehow means answer from a server.

Thinking out loud. I don't have a solution, but things to test

* Dropping the 200.
* Changing the background-color to another light color
* Cache Expiration time left, aka when will be the next request. 
  1st request: 1h then the next request,  45 minutes later, says: 15m.
  aka Expiring in 900s.
Summary: cached and 200 OK → cached and 200 OK - Improving the visual layout of resources fetched from the browser cache
All cache request rows will turn into grey color (new feature recently land in Nightly). 

Karl Dubost, do you think that grey color hint make this better?
Flags: needinfo?(kdubost)
Priority: -- → P3
Attached image Cache-devtools.jpg (deleted) —
yes Bug 1338386 solved a couple of issues, but not all. That's cool.

Basically what I'm saying here is: Be explicit.

The request/response panel doesn't have to use these keywords but something which helps devs to understand what is really happening.

I would also remove the display of request headers, because they are not deserving any useful purpose here. This is different from a conditional request where there is a request happening resulting in 304.

See the lose screenshot/mockup (better things can be proposed)
Assignee: nobody → kdubost
Flags: needinfo?(kdubost)
Product: Firefox → DevTools

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Assignee: nobody → karl+moz
Severity: normal → S3
Assignee: karl+moz → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: