@yaustar I tried adding the Disable Brotli Compression Extension to Chrome. It did change all the compression to “gzip”. But I still get the freeze, even without br.
I think one of my last theories is related to WebGL still. Something with the initialization, maybe at a driver level. Maybe for some reason it crashes. Only happening during certain circumstances. Possibly due to exhausted resources or something.
It’s possible it has nothing to do with hosting/DNS/caching/compression etc which is what I previously assumed. One reason for me believing in WebGL problems is still that the freeze went away if I bypassed the create render device in the engine. And the freeze did go away if I added WebGPU as the render api of choice…
Maybe I should just consider this problem unsolvable right now. And yeah, maybe create a Chromium issue.
Not sure about initialization issue. The freeze seems to happen before any scripts or resources are downloaded, so there is no canvas in the DOM yet, even.
You are most probably correct. I’m a novice when it comes to these things. But I did read somewhere, I forgot where, that if a crash/problem/stall happens early enough in JavaScript files then it can still appear in the DevTools that nothing was received. Just a 200 OK on the response of the index.html, no other files, the request actually never finishing. I could either misremember or just be completely wrong.
When asking ChatGPT about it (not that we should trust it) it does indeed say that if script loading is not deferred and if it is synchronous it can “crash” in such a way that appears similar to what I’m seeing. It could of course be something that ChatGPT just makes up.
what could perhaps do is to build a local engine, but add some logging to it to see if the early login triggers. It might show us that the js starts executing.
Not sure exactly how it would help, perhaps point to some JS parsing issue in Chrome or something.
