Implement HTTP caching on our side

[inikulin]

We need to implement HTTP caching of resources on our side. Since we invalidate any browser cache with each test run we can end up with situation when we abuse external CDNs or websites with requests if we have lot's of fast-running tests. The solution is to implement HTTP cache on our side, or at least a part of it. The spec is here: https://tools.ietf.org/html/rfc7234 Please, investigate ASAP.

[Dmitry-Ostashev]

The site mentioned in the issue https://github.com/DevExpress/testcafe/issues/4877 is also working extremely slowly with hammerhead.

[miherlosev]

https://stackoverflow.com/questions/60986884/webpage-load-times-slow-inside-testcafe-studio-browser

[link89]

Hi, is there any progress about this issue? We find that testcafe will exhaust bandwidth if we set the concurrency to 20.

I think we can break this task into 2 stags.

Stage 1

Cache responses of GET requests whose URL pattern matches users' configuration. For example, users can export an environment variable,

export TESTCAFE_HAMMERHEAD_CACHE_PATTERN=.+example.com/.\*\(js\|css\|html\)

And inside hammerhead we can create a regular expression from this envvar and use it to test against every GET request and cache the response when it is matched.

Stage 2

Cache response automatically (respect RFC 7234). May make use of tools like https://github.com/kornelski/http-cache-semantics

I think for most use cases stage 1 is good enough. How do you think about this? I think we can create a PR if you agree with the proposal.

[LavrovArtem]

Thank you for the provided information about the http-cache-semantics module. We would like to repeat the native browser behavior and implement caching on our side. It will get rid of our need for additional settings. Unfortunately, we aren't considering the first stage provided by you.

[link89]

@LavrovArtem

We would like to repeat the native browser behavior and implement caching on our side.

On second thoughts I don't think that we should repeat the native browser behavior. The cache acts more like a temporary server during case execution so that it doesn't need to respect the cache-control policy set by the web server.

In our case, we are using testcafe to test a PWA project and cache policy is control by service-worker. We don't want the browser to cache the content for us, so on the server-side we will always add no-cache to response headers.

What we need is to change this web server <==> hammerhead <==> browsers into this hammerhead (cache web server's content) <==> browsers

What I need to point out is that web asset WON'T be changed during case execution, so we can always cache content in hammerhead no matter how cache-control options are set.

The reason to provide options like TESTCAFE_HAMMERHEAD_CACHE_PATTERN can simplify the implementation as users can use this option to tell hammerhead what should be cached. For example, it is easy to use a regular expression to express the rule to cache everything except /v1/api/.*.

As a conclusion, I think what we need is just STAGE I. How do you think about this? @LavrovArtem

[Farfurix]

@link89

Hello,

We currently adhere to this approach. We will update this thread once we have any results.

[timostark]

Hi @Farfurix ,

One question: I've implemented an extremly basic caching using RequestMock (For Cache Hits) and RequestHook (For Cache Miss) - see https://github.com/timostark/ui5-testcafe-selector-utils/blob/main/src/ui5Cache.ts .

While this is working and increases startup time of heavy applications by around 50%, it is not as good as it could be (1 minute 50 to 50 seconds). When checking the performance trace of vscode, i've recognized that testcafe another 50% of the time is lost during script post processing (which is understandable, regarding teh tasks done here). From the RequestMock/Hook interface i am not able to cache the "adjusted" versions of the scripts, but only the original ones. Question: With your native cache implementation, will you cache the "enhanced" versions of the scripts, or 1:1 the scripts from the server?

Thanks, Timo

[Farfurix]

@timostark

Hello,

TestCafe is already caching processed scripts (less than 50 MB) within one test. The current implementation of caching implies emulation of native browser behavior: the corresponding processed resources will be cached for all tests in your run. Once we have a testing build we will publish it.

[miherlosev]

Folks,

We are happy to introduce the initial release of the HTTP caching feature. It's shipped with testcafe@1.11.1-alpha.1. The documentation for the feature is in progress and is located in this PR. Try running your tests and share your results with us.

[PaulMEdwards]

Would it be possible to expose a configuration parameter to adjust the maximum cacheable asset file size? For our specific case we would like to increase it from 5mb to 9mb or 10mb.

I'll gladly create a new Feature Request issue for this if desired.

Thanks in advance!

[miherlosev]

Hi @PaulMEdwards

The maximum cache size is 50 MB and the maximum cached size for media resources is 5 MB. Please create a separate feature request to specify the maximum size of caching parameters.

For all I will close this issue since the HTTP Caching feature is implemented. If you have any feature requests or face problems, please create separate issues for them.