[Network] Columns polish (width, and whether any can be dropped)

[violasong]

The new Network columns are looking great! There are a few things that could make them even better.

From @fvsch, regarding the badges looking a little cramped, discussed in this bug:

We currently use 4px of padding-left, and that's the whole separation between two columns' text. We could possibly go up to 6px (total cost = 16px) or 8px (total cost = 32px).

If the main issue is that the status badges are a bit too close to the left edge, we can perhaps shift them a bit:

.request-list-item .status-code {
    margin-inline-start: 2px;
}

For default column sizing, I'd also suggest slightly more width for the Size and slightly less width for Transferred/Cause. (Based on looking at what starts getting truncated at smaller sizes)

A bigger question is chrome parity. They don't seem to have Method or Transferred columns. Can we drop these?

[fvsch]

Default columns and column widths on a 1600px-wide window:

At first look, we can probably make the "Cause" and "Transferred" columns smaller, perhaps the same width as "Size".

Dropping the Method column: I guess in the majority use case everything is going to be GET, and if a developer is looking at Network when working on some form or interaction code they may already know that the corresponding request is a POST. Also you get this info when selecting a row (in the the request details).

We probably have users who do like it there by default, though.

Dropping the Transferred column:

A bigger question is chrome parity. They don't seem to have [the] Transferred column.

Actually their "Size" column is very much like our "Transferred" column:

• It shows the transferred size (compressed size for requests compressed with gzip, brotli or some other compression).
• It shows labels like (memory cache) and (disk cache) when the browser used the cached response instead of requesting the URL again.
• On hover, a tooltip shows the "Resource size", which corresponds to our "Size" column.
• If you select "Use large request rows" in the toolbar, the resource size is shown on a second line.

Chrome parity for this column would mean:

• Hiding our "Size" column by defaut
• Renaming "Transferred" to "Size" and "Size" to "Resource Size" (or some other label)
• Probably using a similar tooltip on the "Size" (Transferred) column

Personally I like having this column. It shows the resource size in the same way that a file listing does locally, and I like thinking about CSS or JS bundle sizes in minified-but-uncompressed sizes: e.g. for JS 500KB is big, 1MB is huge. When the Network panel shows the JS size as 150KB (gzipped size) instead of 500KB (resource size), it gives a false sense of "everything is alright, my JavaScript is actually small, no need to concern myself about performance" :P

I've often had to teach coworkers that their bundle size is not 3 jQueries like their thought, but more like 10 jQueries, just because Chrome hides this information away. (One minified jQuery = roughly 100KB on disk.) :/

[violasong]

Thanks for all the info on this! Wow, that's really good to learn about Transferred vs Size. Definitely sounds like a part we should keep. Maybe I'd rename Size to "File Size".

I just realized Chrome also doesn't have Cause, and it does seem mostly redundant with Type. That could be a better column to remove (or partially combine with Type) rather than removing Method.

---

For the columns, I think it'd be easier to parse by changing the flexibility on columns that barely vary in content size to be not flexible, or less flexible. The parts that flex could be File and Waterfall (i.e. flex ratio 2?) and domain (flex 1). Everything else could have static spacing (which could still have some responsiveness for bottom vs side dock).

Could look something like this:

[digitarald]

Great analysis, @fvsch! (should we show Size in general as multiples of jQuery? 😎)

Re columns: Cause and Type make sense to combine, and also thinking about Initiator. Chrome has a neat feature when holding shift and hover, could be reflected with an interactive offspring that combined Cause/Initiator. We also wanted to kick off a user testing session as Network panel is one of the most diverging between browsers and its hard to tell where we should converge without breaking existing users' workflow.

@violasong I like the idea of tweaking the heuristics to apply resizing weighted based on the content's space needs. Status, size and co don't need more space; compared to File, Domain and co. It will probably be a bit complicated

Looking at Chrome's Network column resizing, it has a few nice tweaks:

1. Does not resize waterfall when other columns on the left are resized
2. Resizing Waterfall resizes all columns to the left equally

[fvsch]

For the flexibility part, I think it might be doable since we use fixed table layout, for instance if you defined widths as:

Status: 44px
Method: 44px
Domain: 20%
File: 30%
Cause: 64px
Type: 64px
Transferred: 70px
Size: 70px
Waterfall: 40%

It's okay if the sum of percentages plus fixed widths is not 100%. Fixed table layout will keep the fixed px widths as-is, and the percentages will share what space is left (so the values I used are kind of like flex 2, 3 and 4).

So that is doable, but I'm not sure how we would handle resizing with this setup. (I have a few ideas but am not sure they improve on the way we do resizing right now.)

If we want to still have some "flex" for those shorter columns, that could be done by mixing pixel and percentage values with calc(), for instance:

Status: calc(15px + 4%)
Method: calc(15px + 4%)
Domain: 15%
File: 25%
Cause: calc(30px + 4%)
Type: calc(30px + 4%)
Transferred: calc(35px + 4%)
Size: calc(35px + 4%)
Waterfall: 35%

That works for display but I'm not sure we can make it work for resizing. :/

[In Chrome] Resizing Waterfall resizes all columns to the left equally

I think that's already the case in Firefox? Trying it out now, and at least on a large window it works like that. Maybe in a narrow window we constrain things a bit differently?

In my experience it's the only part of resizing Network columns that is not maddeningly frustrating.

[digitarald]

I think it might be doable since we use fixed table layout, for instance if you defined widths as:

This seems the easiest to code, but also to understand for users and it hopefully matches their expectations on which columns that want to shrink/grow.

I think that's already the case in Firefox?

So that is doable, but I'm not sure how we would handle resizing with this setup. (I have a few ideas but am not sure they improve on the way we do resizing right now.)

The implementation is indeed a tougher case. It does feel this isn't based on percentages but something using flex-grow/shrink. I think we need to prototype it to get a better feeling for it; as column resizing has a lot nuance in how different columns interact based on their position.

[digitarald]

The implementation is indeed a tougher case.

This could be immensely simplified if we move the name column first, like in Chrome and Safari, so it gets less affected by the current resizing heuristic (which is inspired by Chrome, but works better there because of the default column sorting).

[digitarald]

Ongoing discussion here, nothing pressing.

[digitarald]

Feel free to file bugs that I have missed that came out of this. Seems like some white space improvements came out of this.