The Network panel should identify slow HTTP requests and mark them in the UI using an icon.

The logic used to identify slow request is based on the time that is needed to get the response from the server. It's represented by an existing waitingTime.

It's similar to the TTFB (Time to first byte), but the time needed to send the HTTP request isn't included.

The waiting time is calculated from:

• The time needed for the server to process the request.
• The time needed for the server to send back the first byte of the response to the client.

If the Waiting time is higher than 500 ms we should show an icon within the File column.
See the mockups:
https://www.figma.com/file/rTeLZ1cmvHbgfJt91AloNi/DevTools-Network%3A-Details-Pane%2C-table-redesign-(V)?node-id=0%3A1

The 500 (default) threshold should be stored within a pref. The pref is only accessible through about:config.

devtools.netmonitor.waitingTime.slow
(any better name?)

• The default value: 500 (ms)
• If the value is <= 0 - the icon should not be displayed at all (the feature is effectively disabled)

The icon should have a tooltip, something like as follows:

• Slow resource (time to first byte is over 500 ms)
• This resource has a slow time to first byte (over 500ms)

We might want to send the waitingTime field within the “responseStart” packet, so it's immediately available (see bug 1646027 for inspiration).

Honza

Victoria, can you please attach the icon, thanks.

Harald, can you please provide text for the tooltip, thanks.

Link to turtle icon from victoria
https://drive.google.com/file/d/1AuDTdDp66H42A0nlPGzBS_aKNpTzlHx8/view

Quickly bouncing it off Victoria, we came up with this for v0:

Slow request: The server response times (TTFB), {waiting time}, is over the recommended limit of {limit}.

(any better name?)

What about devtools.netmonitor.audits.slowTtfb? Mostly because waiting as label is lacking context on its own.

Related 1, Lighthouse's server response audit fails for over 600ms: https://web.dev/time-to-first-byte/ , without any specific reason on why that number. This audit is also only applied to the root document (where server response time is most critical).

Related 2, this audit-naming issue also reflects the conflicting definition of server response vs actual ttfb: https://github.com/GoogleChrome/lighthouse/issues/10720

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

What about devtools.netmonitor.audits.slowTtfb? Mostly because waiting as label is lacking context on its own.

As we discussed on Matrix, it's better to avoid 'ttfb' since what we measure
doesn't include connection neither sending time.

Honza

As we discussed on Matrix, it's better to avoid 'ttfb'

Sure, then devtools.netmonitor.audits.slowServerResponse is more correct.

Backed out changeset 4237adea1a08 (bug 1648373) for dt failures at browser_webconsole_stubs_network_event.js.
https://hg.mozilla.org/integration/autoland/rev/d51e8342a2629f6957abcdf08517d60207494323

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=W81Ix0pzTSK2VC_lZE4fAQ.0&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=4237adea1a08ae3854e8d21c36a507ff6c233986

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308026539&repo=autoland&lineNumber=4168

https://hg.mozilla.org/mozilla-central/rev/1d555b195c2f

Added a screenshot and description of the turtle icon under the File column in the Network request columns section of the Network request list article.