Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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".

Waterfall for all requests

Waterfall for single request

The "short" requests look like this:

enter image description here

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.

like image 940
asgerhallas Avatar asked May 06 '19 15:05

asgerhallas


People also ask

Why does chrome Say “Waiting for cache”?

The simple answer is, because the information that Chrome downloaded to your PC has become inaccessible. The cache is where your browser stores certain information about your browsing activity, so it can load websites faster when required. The “waiting for cache” message is displayed when the Chrome browser is unable to access this information.

Why doesn’t Webpack-Dev-Server force a browser refresh?

However, webpack-dev-server is not monitoring changes to your contentBase so it does not force a browser refresh. Setting watchContentBase to true in your Webpack configuration, will ‘fix’ this issue, but in the wrong way. When using webpack-dev-server, you should never have to run Webpack CLI to make ‘live-reload’ work.

Should I run Webpack CLI when using Webpack-Dev-Server?

When using webpack-dev-server, you should never have to run Webpack CLI to make ‘live-reload’ work. When you make code changes to any code dependency pointed to by entry webpack-dev-server re-generates ‘bundle.js’ in-memory, and makes it available over publicPath.

How to fix Google Chrome stuck on waiting to download?

Top 9 Ways to Fix Google Chrome Stuck on Wait­ing to Down­load Issue. 1 1. Restart Your Computer. It’s a good practice to shut down your computer after using it instead of putting it on sleep or hibernating it. If you are ... 2 2. Set Correct Date and Time. 3 3. Download Offline Installer. 4 4. Turn off Smart Screen. 5 5. Enough Storage. More items


1 Answers

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/');
});
like image 192
asgerhallas Avatar answered Oct 19 '22 11:10

asgerhallas