HTML5 export for Godot 4.x takes 1-2 minutes to load on macOS

Luzzotica commented 1 year ago

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further. Bugsquad note2: Also, please avoid asking when this will be fixed. The issue is confirmed to be with the version of ANGLE used by Chromium, so we are all waiting for Google to ship the fix.

Godot version

4.0.beta10

System information

MacOS Monterey 12.2.1

Issue description

Godot games block the main thread (And potentially crashes it) on MacOS.

Untested for Windows or Linux.

This happens from both a generic build and when you run the project in a browser from the engine.

Steps to reproduce

Create a new project for Godot Beta 10.

Add a UI Button to the screen.

Have it print things out, whatever you wish.

Add an HTML5 export, install the HTML5 export library if necessary.

Click the run on HTML5 button on the top right.

Proceed to wait for 1-2 minutes before the game will fully load.

Minimal reproduction project

TestGodot4Web.zip

Calinou commented 1 year ago

Duplicate of https://github.com/godotengine/godot/issues/41118 and/or https://github.com/godotengine/godot/issues/68647 (same cause – large size causes slow initialization times).

Luzzotica commented 1 year ago

@Calinou I feel like this isn't the same as those. I don't believe it's a size issue.

Running locally on MacOS on both Brave and Chrome: Took about ~2 minutes and 30 seconds for the game to load. Both Brave and Chrome wanted to kill the tab. It had locked up the entire browser for (Couldn't go to any other tab).

Running this on Windows, and the game loads in ~10 seconds.

If this is a size issue, then MacOS Chrome and Brave are just INSANELY slow to load things. Which doesn't seem right. Also, since I'm running it locally, I assume the web assembly can load faster... This might be untrue, but I doubt that it is.

Zireael07 commented 1 year ago

In that case, it might be shader loading and/or conversion (correct me if I'm wrong, but MacOS converts stuff to ANGLE behind the scenes, doesn't it?)

clayjohn commented 1 year ago

In that case, it might be shader loading and/or conversion (correct me if I'm wrong, but MacOS converts stuff to ANGLE behind the scenes, doesn't it?)

I also think may be a shader compilation issue. Chrome definitely uses ANGLE, but I am not sure about Brave. macOS doesn't use ANGLE when running on desktop though.

While attempting to fix the gl_compatibility renderer on macOS I experimented with using ANGLE, but found that the shader compilation times ended up increasing by over 100X. In https://github.com/godotengine/godot/pull/70065 I was able to speed up shader compilation times and get gl_compatibility working on macOS without ANGLE. However, since chrome uses ANGLE, my guess is we are hitting those pathological shader compilation issues anyway. I am not sure what exactly in the shader is causing the issue (it may even be a bug in ANGLE).

bergice commented 1 year ago

thomasbergersen commented 1 year ago

The issue of Chrome crashing on MacOS 13 does indeed exist, and Firefox takes over 2 minutes to load.

shinspiegel commented 1 year ago

I'm completely new to C++ dev, but I would like to help with this issue. What can I do to help?

Luzzotica commented 1 year ago

Can confirm, 4.0 RC2 is still taking minutes to load on Brave on MacOS.. Causes my entire browser to lock down completely.

dhnm commented 1 year ago

The issue still persists in rc4, rc5, rc6. In Forward+, Mobile, and Compability mode. Chrome hangs, Firefox takes a while but loads, and Safari has a infinitely loading spinner and reports the following in the console:

[Error] Unhandled Promise Rejection: CompileError: WebAssembly.Module doesn't parse at byte 1155: can't get 1th argument Type
    promiseEmptyOnRejected
    promiseReactionJob
> Selected Element
< <html lang="en">…</html>
[Error] still waiting on run dependencies:
    onPrintError (tmp_js_export.js:14008)
    (anonymous function) (tmp_js_export.js:737)
[Error] dependency: wasm-instantiate
    onPrintError (tmp_js_export.js:14008)
    (anonymous function) (tmp_js_export.js:739)
[Error] (end of list)
    onPrintError (tmp_js_export.js:14008)
    (anonymous function) (tmp_js_export.js:742)

michaldev commented 1 year ago

In the latest version of Godot Engine 4 (RC 6), the game still completely freeze internet browsers (tested on Chrome and Firefox and MacOS 13.2.1). Will a stable version of Godot really be released today with such a bug?

max-vogler commented 1 year ago

Just to confirm - this issue does occur on Godot 4.0 stable, viewing the web export in Chrome 110 on macOS 13.2 on a MacBook Pro 2023 M2. A project containing only a very simple 2D pixel art scene takes 70s to load initially. Is it possible to find a workaround until this is fixed, e.g. strip shaders from the web export?

Calinou commented 1 year ago

Is it possible to find a workaround until this is fixed, e.g. strip shaders from the web export?

No, other than staying on Godot 3.x.

(PS: Modern OpenGL/WebGL rendering always uses shaders, no matter how much your custom build is stripped. This is also the case in Godot 3.x.)

greggman commented 1 year ago

I extracted the shaders from godot 4.0 from the sample linked above and filed a bug. Only 19 shaders are compiled at startup but for some reason (didn't look into why) several shaders, 5 shaders take ~15 seconds each for a total of 1 minute at 15 seconds (on an M1 mac)

https://bugs.chromium.org/p/angleproject/issues/detail?id=8068

greggman commented 1 year ago

If you're curious I wrote this code

// extract-shader.js
(function() {
  const programs = [];

  function dumpPrograms(label) {
    if (programs.length) {
      if (label) {
        console.log('//', label);
      }
      console.log(JSON.stringify(programs));
      programs.length = 0;
    }
  }

  globalThis.dumpPrograms = dumpPrograms;

  for (const RenderingContext of [WebGL2RenderingContext, WebGLRenderingContext]) {
    RenderingContext.prototype.linkProgram = function(origFn) {
      return function(prg) {
        console.log('// link', programs.length);
        const shaders = this.getAttachedShaders(prg);
        programs.push(shaders.map(sh => {
          return {
            type: this.getShaderParameter(sh, this.SHADER_TYPE),
            src: this.getShaderSource(sh),
          };
        }));
        origFn.call(this, prg);
      };
    }(RenderingContext.prototype.linkProgram);

    for (const name of ['clear', 'drawArray', 'drawElements', 'drawArraysInstanced', 'drawElementsInstanced']) {
      RenderingContext.prototype[name] = function(origFn) {
        return function(...args) {
          dumpPrograms();
          origFn.call(this, ...args);
        };
      }(RenderingContext.prototype[name]);
    }
  }
})();

And then I added <script src="extract-shaders.js'></script> to the top of the html file and I added importScripts('extrac-shaders.js') to the worker (as I wasn't sure which one uses WebGL, the main thread, the worker, or both). I also added a call to dumpShaders in the onmessage code in the worker and in the onPrint function in the main thread JavaScript since the sample above does so little that I wasn't sure WebGL is actually being called.

In any case, you can use code like this to extract shaders and then code like the one in the chromium bug report to make a minimal repo.

greggman commented 1 year ago

So looking into this more, it appears to be an issue with ANGLE running on top of the MacOS OpenGL drivers. Chrome is working to switch over to ANGLE running on top of Metal. You can test that path with

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-cmd-decoder=passthrough --use-angle=metal --user-data-dir=<some-random-folder>

In which case the shaders compile faster. Hopefully that will ship soon.

You can verify which backend ANGLE is running on by going to about:gpu

ANGLE running on OpenGL:

GL_RENDERER: ANGLE (Apple, Apple M1 Max, OpenGL 4.1 Metal - 83)

ANGLE running on Metal:

GL_RENDERER: ANGLE (Apple, ANGLE Metal Renderer: Apple M1 Max, Version 13.2.1 (Build 22D68))

Yes, it's confusing that both strings say 'metal' 😅

max-vogler commented 1 year ago

This is fantastic @greggman -- can confirm the project now loads in seconds instead of minutes.

ANGLE (Apple, ANGLE Metal Renderer: Apple M2 Pro, Version 13.2 (Build 22D49))

Luzzotica commented 1 year ago

So we just gotta wait for chrome/safari/brave to migrate to the new Metal Renderer? Because there's no way I'm gonna get my players to run their browser with that special command haha!

greggman commented 1 year ago

So we just gotta wait for chrome/safari/brave to migrate to the new Metal Renderer?

correct...

Or you can try to adjust the shaders so they don't provoke the issue in the Apple OpenGL drivers, or pray Apple updates their OpenGL drivers.

If you want to update the shaders in the short term, lowering MAX_LIGHTS lowers the compile time. The issue is probably the way Apple's OpenGL driver handles UBOs. Their might be other work arounds, I'm not sure.

evwilliams commented 1 year ago

Is it possible to fallback to the way Godot 3.x handled web exports while we wait for browsers to migrate to Metal?

Calinou commented 1 year ago

If you want to update the shaders in the short term, lowering MAX_LIGHTS lowers the compile time. The issue is probably the way Apple's OpenGL driver handles UBOs. Their might be other work arounds, I'm not sure.

Which value did you test for MAX_LIGHTS, and how much did it speed loading? Looks like it's hardcoded in these 2 places (if you're referring to 2D rendering):

https://github.com/godotengine/godot/blob/1e0f7a12f7c762ee1d73795485b0d00db3cf2ac8/drivers/gles3/rasterizer_canvas_gles3.h#L248

https://github.com/godotengine/godot/blob/1e0f7a12f7c762ee1d73795485b0d00db3cf2ac8/drivers/gles3/rasterizer_canvas_gles3.h#L100

Is there a way we could expose a project setting, then add a web override to decrease it by default in HTML5 exports? This could cause 2D lights to visually break after exporting to HTML5 (depending on the number of lights present in the scene), but it's better than having very long load times.

Is it possible to fallback to the way Godot 3.x handled web exports while we wait for browsers to migrate to Metal?

No, as 3.x featured entirely different and incompatible rendering backends (most notably a GLES2 backend, which is much simpler and more limited).

Given this isn't the only shortcoming of the HTML5 export in 4.x, it may be worth looking into creating a 4to3 project converter. This way, you can downgrade a Godot 4 project to Godot 3 until the HTML5 export matures (and then use 3to4 to convert it back once that happens). This could take a long time to be fixed upstream after all.

tavurth commented 1 year ago

Probably a worse case of this https://github.com/godotengine/godot/issues/56670 (3.x 3D web)

chasem-dev commented 1 year ago

Hi I just wanted to share my frustration with the bug reported on https://github.com/godotengine/godot/issues/72584. In 3.x exporting to Web was a safe way to ensure your game was playable on many platforms.

Web exports for a very minimal 2D game are unable to be played in chrome on a MAC, however interestingly enough Safari seems to work. It's very unfortunate because web exports being cross platform was a huge selling point for me.

I look forward to progress on this.

Calinou commented 1 year ago

@Xwaffle1 Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

(Remember that commenting creates a notification for everyone watching the repository. If you want to subscribe to an issue without commenting, click the Subscribe button in the sidebar.)

There's also the workaround described here which you can try by modifying some values in the engine source code, then compiling a custom HTML5 export template: https://github.com/godotengine/godot/issues/70691#issuecomment-1472914415 Testing this workaround and making sure it works will help this issue be resolved faster.

pbantolas commented 1 year ago

This looks fixed on the latest macOS Ventura (13.3.1) using Safari (16.4). I'm running this on a 2021 M1 Macbook Pro. I tested a variety of scenes both with Godot 4.0.2 and Godot 3.5.2 with the WebGL2 export. Safari uses Metal and not ANGLE for WebGL2 and perhaps that's why the behaviour is different.

The only error I get in the console is [Error] USER WARNING: Project setting: rendering/limits/global_shader_variables/buffer_size exceeds maximum uniform buffer size of: 16384 which is mitigated by changing the project setting to the recommended value.

Firefox still hangs for a bit before loading the scene. Running a CPU Profile reveals that most of the work is stalling on some sort of shader introspection from a GL library. Which means that Firefox is running on a GL layer.

SCR-20230421-ucoh

The recommended Chrome workaround (https://github.com/godotengine/godot/issues/70691#issuecomment-1456888280) works for me.

In general there is quite a bit of variability, but given the majority of people are probably using Chrome this is still dependent on them switching to the Metal backend.

Morpheu5 commented 1 year ago

With 4.1 in RC state, is this receiving any love? Safari seems to do the right thing so one can always point at that, but this may still catch people out by surprise.

AThousandShips commented 1 year ago

Won't get any focus until after 4.1 is released, only high impact bugs and crashes get much focus at that stage, unless this is a trivial fix and someone finds it pretty much immediately

Morpheu5 commented 1 year ago

I guess I meant if this was somehow lost in the changelog that I missed but yeah, thanks for the update anyway :)

AThousandShips commented 1 year ago

If the issue is open it hasn't been fixed :) no PR has been linked to this so no fix seems to be in progress right now, keep looking here for updates like that

mgc8 commented 1 year ago

If the issue is open it hasn't been fixed :) no PR has been linked to this so no fix seems to be in progress right now, keep looking here for updates like that

I guess the confusion comes from the fact that issues such as this leave a strong indication that it would be worked on for 4.1. While that is now clearly not the case, perhaps a better indication of a timeline for investigation/fix could be added to the documentation, just so people embarking on potential new projects can plan accordingly?

AThousandShips commented 1 year ago

How does an issue on a separate repository indicate anything about the priorities in this one? This issue is clearly marked "4.x", and no PR has been opened for this so no solution is clear.

perhaps a better indication of a timeline for investigation/fix could be added to the documentation

We don't track these things in the documentation, that's what the issues here are for

clayjohn commented 1 year ago

If the issue is open it hasn't been fixed :) no PR has been linked to this so no fix seems to be in progress right now, keep looking here for updates like that

I guess the confusion comes from the fact that issues such as this leave a strong indication that it would be worked on for 4.1. While that is now clearly not the case, perhaps a better indication of a timeline for investigation/fix could be added to the documentation, just so people embarking on potential new projects can plan accordingly?

It might be helpful for you to circle back on previous comments in this thread. The issue here is with Chrome's implementation of ANGLE on MacOS. We are waiting for them to resolve the issue upstream. The Godot Project has no influence over Google's release cycles, nor do we have special insight into them. So we unfortunately can't give you a timeline when Google will be shipping a fix, nor can we speed up the timeline.

akien-mga commented 1 year ago

I would suggest for someone affected by this issue to make a clear MRP (both a ready-to-test demo available online, and the source with instructions on how to export using Godot) and report the bug upstream to Chromium: https://bugs.chromium.org/p/chromium/issues/list

It would be important to include information from that comment: https://github.com/godotengine/godot/issues/70691#issuecomment-1456888280 i.e. that --use-angle=metal solves the issue, but is sadly not the default behavior as of current Chrome releases on macOS.

They hopefully track this internally, but some user reports confirming that the current status quo is not satisfactory can help them prioritize. I see some existing upstream issues about slow WebGL performance on Chrome macOS, but not specific to Godot, so it could be good to add one.

Another option is the more "end user bug report" pipeline with https://support.google.com/chrome/answer/95315?hl=en&co=GENIE.Platform%3DDesktop - a bunch of users each reporting that a readily accessible online project runs terribly on Chrome while it runs well on Safari and Firefox will likely help prioritize further.

mgc8 commented 1 year ago

How does an issue on a separate repository indicate anything about the priorities in this one? This issue is clearly marked "4.x", and no PR has been opened for this so no solution is clear.

Apologies for the confusion, that was more on the path of arriving here from discussions on various platforms; it was all about setting the right expectations, since posts on Twitter and the documentation itself leave the impression that this is either a temporary issue or something being worked on.

If that is not the case and it's all dependent on Google fixing Chrome and Mozilla fixing Firefox, then that's all fine and good to know, but it needs to me made clear so we go and fill the right bugs and follow-ups for those platforms as necessary (as well pointed out below by @akien-mga). For example, the documentation currently mentions "Safari has several issues with WebGL 2.0 support that other browsers don't have, so we recommend using a Chromium-based browser or Firefox if possible", which is exactly opposite at the moment, with Safari being the only functional browser in macOS. Perhaps a note there that Safari works and Chrome/Firefox need upstream fixes would help point people in the right direction?

Thank you and sorry again for any confusion.

soundgnome commented 1 year ago

If that is not the case and it's all dependent on Google fixing Chrome and Mozilla fixing Firefox

It isn't though, because web builds made with Godot 3.5.2 don't have this problem. Maybe at some point changes to Firefox and Chrome will make the issue go away, but I rather doubt developers working on those projects consider addressing Godot regressions to be their job.

akien-mga commented 1 year ago

@soundgnome Try GLES3 on Godot 3, you should have the same issue. It's a WebGL 2 support issue in Chromium, which relies on deprecated OpenGL drivers for ANGLE instead of the modern Metal backend that Apple developed and contributed to Google for ANGLE.

mgc8 commented 1 year ago

I would suggest for someone affected by this issue to make a clear MRP (both a ready-to-test demo available online, and the source with instructions on how to export using Godot) and report the bug upstream to Chromium: https://bugs.chromium.org/p/chromium/issues/list

Thank you for the suggestion, there appear to be actually two issues there that reference this problem:

One opened by @greggman from the above comments in March -- https://bugs.chromium.org/p/angleproject/issues/detail?id=8068
An older one referencing issues with Godot and WASM specifically (but having to do with WebGL); rather than creating a new issue, I've added a test project and steps for reproducing to that second issue -- https://bugs.chromium.org/p/chromium/issues/detail?id=1324296

Hopefully, this will attract the attention of the right people who can either fix the problem or work on switching to the Metal renderer.

Morpheu5 commented 1 year ago

I stirred up a wasps nest – sorry! But at least we have pointers to go poke Google in the right places so thank you! :)

EDIT: Nice of them to comment on the issue just a few hours ago confirming the intention of shipping the Metal backend very soon! 🎉

kevzettler commented 1 year ago

I don't understand why this issue is being deferred to the Google and the browser vendors. Obviously this is a breaking change on the Godot project. If web exports work in 3.5.2 this is a breaking change. The Godot project scrapped the stable WebGL1.0 export pipeline in favor of broken WebGL2.0. Its fairly well known that WebGL2.0 is not yet stable or widely adopted with browser vendors.

Ideally I would assume here that Godot would offer a stable WebGL1.0 exporter from the 3.5.2 line and then introduce a new unstable WebGL2.0 exporter. Is it possible to restore the WebGL1.0 pipeline? I'm assuming this not trivial because during the 3 -> 4 major version change some architectural changes.

Calinou commented 1 year ago

I don't understand why this issue is being deferred to the Google and the browser vendors.

WebGL 2.0 works nicely on a lot of platforms already, and it has been doing so for years. The other platforms are the ones that need to be fixed :slightly_smiling_face:

Ideally I would assume here that Godot would offer a stable WebGL1.0 exporter from the 3.5.2 line and then introduce a new unstable WebGL2.0 exporter. Is it possible to restore the WebGL1.0 pipeline?

This would mean recreating a GLES2 renderer from scratch and maintaining it separately from the existing GLES3 and Vulkan renderers (no code can be reused across GLES2 and modern renderers). We don't have enough rendering contributors to be able to maintain that – the existing 3 rendering methods are already proving challenging to maintain.

If you absolutely need WebGL 1.0, Godot 3.x will remain supported for a while.

SephReed commented 1 year ago

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-cmd-decoder=passthrough --use-angle=metal --user-data-dir=<some-random-folder>

every <some-random-folder> I've tried hasn't worked. Does somebody have a more specific example?

rteijeiro commented 1 year ago

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-cmd-decoder=passthrough --use-angle=metal --user-data-dir=<some-random-folder>
every <some-random-folder> I've tried hasn't worked. Does somebody have a more specific example?

That's a permissions issue in your Mac configuration. This works fine at least in my computer.

hunky-dory commented 1 year ago

Respectfully, this isn't simply an issue of the game taking a while to load — running a Godot 4 web game causes my entire browser to become unresponsive until I manage to kill the tab, which is hard to do when it causes simple tasks like changing tabs, opening right click menus or closing tabs to take 8-12 seconds.

If solving the issue is reliant on fixes over which you have no control, might it be possible to warn OSX Chrome users before starting the loading process?

Calinou commented 1 year ago

If solving the issue is reliant on fixes over which you have no control, might it be possible to warn OSX Chrome users before starting the loading process?

Given Chrome user agents are now frozen, there's no longer a way to warn users of a specific browser version without also impacting users with a newer browser version that has the bug fixed. This means that the warning would be displayed for every Chrome user on macOS, even if it's not relevant for them in the future. (We could make the warning only display once using localStorage, but it can still be an annoyance for those in private browsing mode.)

In short: you can detect that someone is using Chrome and macOS, but you can't distinguish between the current version (say, 114) and a future version with the bug resolved (say, 120).

nickarora commented 1 year ago

For what it's worth, you can use javascript to identify whether the browser is running Angle on OPEN GL

const gl = document.createElement("canvas").getContext("webgl");
const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

// => 'ANGLE (Apple, Apple M1 Pro, OpenGL 4.1)'

It's not a great solution, but you could potentially prevent your application from loading if it detects an incompatibility. I haven't tested this in practice.

mgc8 commented 1 year ago

For what it's worth, you can use javascript to identify whether the browser is running Angle on OPEN GL

Unfortunately, it's not enough to test for ANGLE, but for the specific case of using the Metal renderer -- a @greggman notes above:

ANGLE running on OpenGL: GL_RENDERER: ANGLE (Apple, Apple M1 Max, OpenGL 4.1 Metal - 83) ANGLE running on Metal: GL_RENDERER: ANGLE (Apple, ANGLE Metal Renderer: Apple M1 Max, Version 13.2.1 (Build 22D68)) Yes, it's confusing that both strings say 'metal' 😅

But this might be useful to look for "ANGLE Metal Renderer" specifically, and perhaps show an alert or some red warning text? It's not about incompatibility, but slowness in loading (i.e. 1-2 minutes even, depending on shaders used), which causes the browser to "lock".

fguillen commented 1 year ago

So, for mac users, we can open Godot web games by opening Chrome with this command:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-cmd-decoder=passthrough --use-angle=metal

Note that you must make sure Chrome is completely 100% quit before running it this way or you can pass in another profile

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-cmd-decoder=passthrough --use-angle=metal --user-data-dir=<some-random-folder>

Source

mgc8 commented 1 year ago

So, for mac users, we can open Godot web games by opening Chrome with this command: (...)

Yes, this was taken from a comment higher up here. However, in the meantime it has become less relevant, since developers on macOS can easily test using Safari -- which works fine and comes included with the OS.

The problem remains for end-users, who are not going to switch browsers or run arcane Terminal invocations in order to test a game or demo on e.g. itch.io, and that can only be solved by Chrome itself...

azjgard commented 1 year ago

However, in the meantime it has become less relevant, since developers on macOS can easily test using Safari -- which works fine and comes included with the OS.

@mgc8 It seems like there's still a high degree of relevance to opening an alternative Chrome profile since opening in Safari suffers from the issue described here (which in turn links to this comment from higher up in this thread).

I'm not able to test the build of my simple game in normal Chrome or Safari; Chrome with the --use-profile=metal flag is the only way that I've been able to play an HTML5 export (alt: waiting several minutes for the FF build to load).

mgc8 commented 1 year ago

@mgc8 It seems like there's still a high degree of relevance to opening an alternative Chrome profile since opening in Safari suffers from the issue described here (which in turn links to this comment from higher up in this thread).

The comment and bug referenced there are very old and pertain to macOS 13.2, while the current version is 13.4. Latest Safari (16.5) has no issues whatsoever playing the "MinimalProject.zip" included in report #74512:

I'm not able to test the build of my simple game in normal Chrome or Safari; Chrome with the --use-profile=metal flag is the only way that I've been able to play an HTML5 export (alt: waiting several minutes for the FF build to load).

I can run my own projects as well as official demos without issues or delays in the current version of Safari. Do you have a build/demo of your game that fails we could test with?

As a side-note, new versions of Firefox (at least since around 112+) have also improved considerably in playing Godot games, the delay on load is only about 30 seconds now (with additional few seconds every time new shaders need to be compiled). The only big problem remains with Chrome, which indeed locks up and takes many minutes in the default (non-Metal) pathway.

fguillen commented 1 year ago

As a side-note, new versions of Firefox (at least since around 112+) have also improved considerably

In my case:

macOS: 13.1 (22C65) Intel Core i5
Firefox: 115.0.3 (64-bit)

This project with just a few images takes 1:20 minutes to load

https://arturitoproductions.itch.io/testingimageissue (password: godot)

In Safari (16.2 (18614.3.7.1.5)), the same project above doesn't show any signal to load. I waited 2:00 minutes.

In iPad Chrome or Safari Godot4 web exported projects also don't load. I assume it is the same for iPhone

A bigger project like this (with shaders):

https://arturitoproductions.itch.io/coco-and-frogy

In the above Firefox took ... don't know, I waited 3:00 minutes still loading

godotengine / godot