Seeing slow static asset loading

[bdwain]

I am having an issue running my tests and I'm just wondering if anyone has any advice on what might be wrong.

When my test loads, the browser seems to load static assets very slowly (much more slowly than if I just run my app in the browser normally). Very small assets (like a few kb) are taking up to 5 seconds to load, and it is causing my tests to timeout. The assets are loaded from a local dev server, so it should be very fast. The slowness is causing my assertions to time out and fail.

I'm not convinced the content of my app matters, because it happens even when loading index.html (which is 1.7 kb), and that is the first thing that would be loaded.

It does not happen to my coworkers with the same code, and I've tried to match their versions of testcafe, node, nvm, yarn, chrome. os x, and everything else I can think of. We are in the same office with the same internet speeds, using similar computers. It happens on firefox and safari also.

It sounds more like an issue with my machine than a bug, but I'm not really sure what might be wrong. Is this something anyone has seen before? Or is there any advice anyone has on where I should look for things that might be wrong or causing the slowness?

Specify your

• operating system: OS X High Sierra
• testcafe version: 0.21.1 (also 0.18 and 0.22)
• node.js version: 9.11.1 (also 8 and 10)

[miherlosev]

Hi @bdwain

Would you please provide a screenshot of the 'Network' panel of the Firefox DevTools and mark slow asserts on it?

[bdwain]

Sure. If you look there, the very first request takes over 5 seconds and it's just a 5 kb html file from localhost. gfr-orders-e8856f00b.css and gfr-orders-e8856f00b.js are also very slow, as are a bunch of static assets towards the bottom.

[LavrovArtem]

Could you please capture a screenshot and show response headers for slow requests?

[bdwain]

Sure (one thing to note is that index.html is not so slow anymore. but the rest of the static assets are)

This one had a 304 after the app refreshed in the test (but it was slow with a 200 the first time also)

The browser itself just shows my app's loader

(there's also the black testcafe bar below that with my test description and browser info, Chrome 69, Mac OS X 10.13.6)

[LavrovArtem]

Thanks for the provided information about response headers. However, the information is currently insufficient to determine the cause of the issue and find a precise solution. Please clarify the steps to replicate the issue so that we will be able to provide you with any solution.

[bdwain]

after further inspection, it seems the worst offender for me is a json file that i request with window.fetch, not a javascript file. That file is tiny (240 bytes). It seems different in the devtools because that file has an initiator of hammerhead.js in the devtools network tab, rather than my code.

The problem seems to be when the response is a 304 (not 200) after refresh, and not so much on initial load. It seems to behave differently compared to when I hit my local site directly in the browser, as if testcafe's local server is slowing things down somehow.

I ran node ./node_modules/.bin/testcafe chrome --debug-on-fail ./foo.js and this is foo.js

fixture('foo')
test('is slow', async t => {
  await t.navigateTo('http://localhost:5101');
  await t.wait(15000);
  //here i look at the network tab and toggles.json loaded very quickly (like 200 ms)
  await t.eval(() => {
    window.location.reload();
  });
  await t.wait(150000);
  //here i look at the network tab and toggles.json loaded slowly (like 3.5 seconds)
});

Here is the request and response headers for the initial fast request

and here are the ones for the slow request,

If i just run my site normally on my local server, on refresh, when toggles.json returns a 304, it is still fast (like 10 ms). So it seems like testcafe is slowing down the 304 response somehow.

[LavrovArtem]

It looks like it is the 0.18 version and the described issue was already fixed in higher versions. Could you please specify a version of testcafe that was used in the previous comment?

[bdwain]

I'm on version 0.22.0, not 0.18. Does it say 0.18 somewhere? I don't see that in my node_modules folder

[LavrovArtem]

Thank you for the provided information. No, it is just my supposition. TestCafe can be installed locally and globally at the same time. To check the exact version that is used for running tests, you can verify your version by running this command:

testcafe --version

We would need a sample to reproduce this behavior and thoroughly research it.

[bdwain]

I verified my version is 0.22.

You want a sample application that reproduces this? I can try to make one, but it only seems to happen on my machine, not other people I work with, so it might be hard to reproduce on your end. That's why I was wondering if there is some setting you could think of that might affect how files are loaded from testcafe.

[bdwain]

what was the issue in 0.18? Maybe it would help diagnose my issue?

[LavrovArtem]

Until we have a clear reproduction sample where we can see the issue in action, we are not able to find a solution.

You can learn more about the issue in the previous version in this PR.

[miherlosev]

I will close the issue because no activity has been encountered for a long time.
Feel free to reopen the issue if the problem persists and you can provide an example to reproduce it.

[Bakanych]

It's happening now for the latest version too (1.8.4).

[alexey-lin]

Sorry to hear that. But we cannot find the cause of the issue without reproducing it on our side.