CODEWITHSUNDEEP
google-chromehttphttprequestgoogle-chrome-devtools
setec
setec

Reputation: 16120

Understanding Chrome network log "Stalled" state

I've a following network log in chrome:

network log

I don't understand one thing in it: what's the difference between filled gray bars and transparent gray bars.

Upvotes: 238

Views: 267393

Answers (8)

Roman Starkov
Roman Starkov

Reputation: 61510

One other scenario when a fetch can stall: when you fetch the same URL multiple times in parallel, if the fetch is configured to use the cache (which is on by default for GET), the second fetch will wait in the "stalled" state for the first fetch to complete.

This is true in Chrome but not in Firefox. I did not test Safari.

Not that there are many reasons to do this intentionally - but it can happen naturally in React Strict Mode, when effects are called twice. So if you see stalls in those, either ignore it (as it's dev only) or disable caching, eg with fetch(url, { cache: no-store }).

Upvotes: 0

Imran Qadir Baksh - Baloch
Imran Qadir Baksh - Baloch

Reputation: 34054

We hit this issue today and we have found QUIC protocol making this issue. We have disabled QUIC from chrome://flags and site started to working.

Upvotes: 3

briefy
briefy

Reputation: 221

https://developer.chrome.com/docs/devtools/network/reference/?utm_source=devtools#timing-explanation

This comes from the official site of Chome-devtools and it helps. Here i quote:

  • Queuing If a request is queued it indicated that:
  • The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images.
  • The request was put on hold to wait for an unavailable TCP socket that's about to free up.
  • The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1. Time spent making disk cache entries (typically very quick.)
  • Stalled/Blocking Time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.

Upvotes: 10

bertman12
bertman12

Reputation: 1

I recently had an issue with a request stalling as well. This may be helpful if you have exhausted all other fixes mentioned in other answers.

If you are using the fetch API for requests, then you may want to also try removing the 'keep-alive' property in the request options.

This was an annoying bug for me and removing this got rid of the stalling issue.

Upvotes: 0

Renno K
Renno K

Reputation: 81

Since many people arrive here debugging their slow website I would like to inform you about my case which none of the google explanations helped to resolve. My huge stalled times (sometimes 1min) were caused by Apache running on Windows having too few worker threads to handle the connections, therefore they were being queued.

This may apply to you if you apache log has following note:

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

This issue is resolved in Apache httpd.conf. Uncomment : Include conf/extra/httpd-mpm.conf

And edit httpd-mpm.conf 

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

Note that you may not need 2000 threads, or may need more. 2000 was OK for my case.

Upvotes: 7

Kevin .NET
Kevin .NET

Reputation: 473

My case is the page is sending multiple requests with different parameters when it was open. So most are being "stalled". Following requests immediately sent gets "stalled". Avoiding unnecessary requests would be better (to be lazy...).

Upvotes: 2

Naga Kiran
Naga Kiran

Reputation: 8745

DevTools: [network] explain empty bars preceeding request

Investigated further and have identified that there's no significant difference between our Stalled and Queueing ranges. Both are calculated from the delta's of other timestamps, rather than provided from netstack or renderer.

Currently, if we're waiting for a socket to become available:

  • we'll call it stalled if some proxy negotiation happened
  • we'll call it queuing if no proxy/ssl work was required.

Upvotes: 16

Alexander O&#39;Mara
Alexander O&#39;Mara

Reputation: 60587

Google gives a breakdown of these fields in the Evaluating network performance section of their DevTools documentation.

Excerpt from Resource network timing:

Stalled/Blocking

Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation. Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome's maximum six TCP connection per origin rule.

(If you forget, Chrome has an "Explanation" link in the hover tooltip and under the "Timing" panel.)

Basically, the primary reason you will see this is because Chrome will only download 6 files per-server at a time and other requests will be stalled until a connection slot becomes available.

This isn't necessarily something that needs fixing, but one way to avoid the stalled state would be to distribute the files across multiple domain names and/or servers, keeping CORS in mind if applicable to your needs, however HTTP2 is probably a better option going forward. Resource bundling (like JS and CSS concatenation) can also help to reduce amount of stalled connections.

Upvotes: 275

Related Questions