Why is Chrome waiting before every second request when using webpack-dev-server?

Question

Can someone help me understand what is happening in the hundreds of milliseconds before the initial connection?

It happens on every other request only as shown.

The requests are POSTs made to the same ressource on localhost - against an ASP.NET Core web application.

I've looked at other similar questions and answers too, but I have seen no examples where there's just nothing before the initial connection. Everyone else seems to have a bar of "Stalled" or "Queueing".

The "short" requests look like this:

Chrome version: 74.0.3729.131 (Officiel version) (64-bit)

UPDATE 1: This does not happen in Microsoft Edge. Every request is short there. No wait.

UPDATE 2: Downloading a HAR file for a long request reveals a very long "connect" time:

 "timings": {
  "blocked": 1.135999995024409,
  "dns": 0.0030000000000000027,
  "ssl": -1,
  "connect": 301.202,
  "send": 0.18900000000002137,
  "wait": 79.29900000206612,
  "receive": 3.750999996555038,
  "_blocked_queueing": 0.8449999950244091
},

The short one have a connect time of -1:

  "timings": {
      "blocked": 0.9680000060191378,
      "dns": -1,
      "ssl": -1,
      "connect": -1,
      "send": 0.091,
      "wait": 50.74499999642931,
      "receive": 2.582000000984408,
      "_blocked_queueing": 0.8130000060191378
    },

But why?

UPDATE 3: Turns out that this only happens when proxying through webpack-dev-server. I'll add that tag too. Still only happens in Chrome though.

UPDATE 4: A summary of what seems to be the case right now, the pattern emerges when using:

• Proxy via webpack-dev-server from localhost:3000 -> localhost:3001, not when going directly to the endpoint at localhost:3001
• locahost:3000 as the address in Chrome, not when using 127.0.0.1:3000.
• Chrome (multiple version including 74.0.3729.131), not Microsoft Edge
• Windows 10, not Ubuntu 19.04

Both in NodeJS 10 and NodeJS 12. Tested on multiple machines and with Chrome in incognito mode as well.

Wad

It seems to be another kind of emptiness than this for example #31104647 ... or is it just a new way to visualize the same thing? – Wad

Answer 1

I posted this as an issue here https://github.com/webpack/webpack-dev-server/issues/1850 and a solution was found.

Details can be found in the issue discussion, but the solution was to listen directly on IPv6 loopback address instead, like:

const server = new WebpackDevServer(webpack(config), {
  hot: true,
  writeToDisk: false,
  historyApiFallback: true,
  contentBase: path.join(__dirname, 'src'),
  proxy: [{
    context: ["/api/**"],
    target: "http://localhost:5000",
    logLevel: 'debug'
  }]
});

// Listen on ::1, details here https://github.com/webpack/webpack-dev-server/issues/1850
server.listen(3000, '::1', err => {
  if (err) {
    return console.log(err);
  }

  console.log('Listening at http://localhost:3000/');
});

Wad

Thanks for sharing your analysis and solution! I added the response-time middleware to webpack's express app instance which did not show any stalls. Wireshark in capturing loopback traffic did not show any long latency either. To people using the declarative webpack configuration, this corresponds to the host property. – Shererd