garmoth.com has very long load times

[andikay]

Garmoth.com is a website with guides etc. for an online multiplayer game. When loading the site I noticed that it takes very long to load, according to the network analysis the domains s1.pearlcdn.com and assets.garmoth.com take 10-15 seconds to load in the assets, it seems like something is delaying the retrieval and while this is happening opening a new tab with a different website causes that tab to not load as well.

I tested this with my normal PM profile as well as a fresh one; with the fresh profile the site basically hangs the browser because of all the additional crap that is loaded in, with my normal profile with uBOL+eMatrix the browser does not hang, but it's still just as slow to load assets. This does not happen with Firefox, the entire site is loaded within half a second there.

The only relevant error that sometimes shows up is this one:

Code: Select all

Error: ReferenceError: event is not defined
Source File: https://garmoth.com/_nuxt/Bup4_JUX.js
Line: 7

[Moonchild]

It doesn't load for me at all so there might be an issue with the server.

[Night Wing]

It loaded for me and it took about a half second of time.

What I did was open up a "new window" which took me to my home page. Then I right clicked on my home page's address to highlight the address, then left clicked on "paste and go" with the link below and the site rendered properly.

https://garmoth.com/

At this time, I am using 64 bit linux Pale Moon 33.0.2 running in 64 bit linux Mint 21.3 (Virginia) Xfce. This also includes the "old" uBlock Origin 1.16.4.30 version which was enabled for Garmoth.

[suzyne]

I can confirm that the site does finish loading for me, but it takes a long time, it's like minutes. I am using Windows 33.0.2 (64 bit) with uBlock Origin installed but no other plug-ins or filters that change what Pale Moon is fetching.

[Moonchild]

I tried again and it loaded in about 10 seconds total for me.

[andikay]

Yeah in like one out of 10 times the site either loads actually quickly or not at all, but usually it takes at least 10-20 seconds, which is a lot slower than it should be, so I am curious what's happening there since I do not have this behavior with Firefox.

[Moonchild]

The site makes over 200 individual requests to the server for its home page, including some websocket stuff (and that's with me having my adblocker enabled, might even be more without that), so there's a lot of moving parts. Can't really make much of a guess why there's intermittent slowness.

[tristan9]

Works fine enough on 33.1.0 here, as far as client-side-rendered SPAs go on PM tbh.

---

Off-topic:
But this caught my eye:

The site makes over 200 individual requests to the server for its home page [...]

It is stupid, yes. And it is due to an issue (design flaw, imo) with Nuxt, which we ran into as well in the past: https://github.com/nuxt/nuxt/issues/14584 (and a few more of similar type).
For some reason, they decided that to bundle the final client files, each visual component would go into its own JS file, and then *all* get preloaded 1-by-1 in the SPA's HTML template. And thus any entrypoint gets to download every single bit of the website all at once, instead of doing the sane thing, ie building a dependency graph of entrypoints and components, extracting common components, then loading these as-needed from there on JS-driven imports or similar.

The end result being this hundreds-of-js-files-and-images-etc mess. Dead-giveaway being those 100+ /_nuxt/[hash].js files.

To add insult to injury, it also insists on preloading all files in a certain class of applications assets (details are irrelevant), so you get many extra image files preloaded needlessly on top of it.

And there's only very limited solutions for either of these issues atm... In our case, forcing it to bundle per-page instead of per-component (in a really hacky way: https://github.com/nuxt/nuxt/issues/145 ... 1837436340) got us from 400+ JS files to... 16.
Still more than we'd like, but yeah. My guess is they have PTSD from early JS days where a single 8MB app.js file was also a bit stupid of an approach. But I wonder what is the point of all these dynamic import specs if they never get used in practice... sigh...

[Moonchild]

Off-topic:

But I wonder what is the point of all these dynamic import specs if they never get used in practice... sigh...

Half of the js specs out there at the moment (and I'm being very generous here) are either change for the sake of change, adding sugar for developers who will never use it because they don't touch raw JS, or to promote browsers who were the first to implement them (you know of whom I speak).

[tristan9]

Off-topic:

Half of the js specs out there at the moment (and I'm being very generous here) are either change for the sake of change, adding sugar for developers who will never use it because they don't touch raw JS, or to promote browsers who were the first to implement them (you know of whom I speak).

The spec changes being at times frivolous don't irk me so much. You see them as first pain point as a browser author, which is understandable, but what I don't use doesn't really affect me so /eh in a way (though I sympathize).
But what I don't get is that these complex extra specs to enable fancier content loading (again, thinking of async dynamic imports as poster-child of "god why" here), which can be used in clever ways since it's client-side initiated with all info needed on what agent it is and what it wants as layout etc, just seem to go unused.
For example, we have a few PWA-specific components on our site. Like a fixed-bottom-of-screen nav bar, and a few pages with a layout to account better for the lack of browser tabs etc. How the hell are we in a state where this gets preloaded for all agents with all this technology is what puzzles me.
Our choice is degrading the end-user experience by making the site heavier (and it is already many times heavier than we'd like), or cutting back on features widely used. (the whole ServiceWorker thing, that PWAs essentially require, is also one of the most unthinkably awful and developer-unfriendly spec designs that I've ever seen in programming as a whole, but that's an off-topic of an off-topic)

I'm sure if I were to sink months of full-time work on our frontend alone, I could figure it all out but this is realistically never happening. Yet that's supposed to be what these widely-used frameworks figure out for you. And to be fair they do a lot of figuring out, but man... Sigh...

[Moonchild]

Off-topic:

Yet that's supposed to be what these widely-used frameworks figure out for you. And to be fair they do a lot of figuring out, but man... Sigh...

It's been the problem with framework developers. Frameworks providing abstraction layers is awesome, but if you then in the framework stop being broadly compatible, it immediately impacts many, many sites using the framework. And the icing on that particular cake is that (as I hinted at already) the "new" spec stuff is never touched by anyone directly, and it is very often just a matter of deciding to "build for a specific level of ecmascript" (literally one line of configuration) to determine what it spits out and how compatible it is. And often the consideration there tends to be "oh it shaves a few kb off of our 10 MB script blob" and not much else. You could do just about anything you want with ES5 as a target, even if it'd be less efficient. But more realistically, frameworks could target a very complete set of specs like ES2017 or so and be fully compatible with everything under the sun right now with no real drawbacks. But the arbitrary choice is made to not be.

Framework devs seem to be particularly stricken by the "must use new shinies" attitude, while that is literally the last thing they should be doing since their frameworks are used by many sites in many environments with many different clients. I've complained about this before, several times. But they do what they do.