Full editor JavaScript loaded upon initial page load for guests

[Kirby]

If a forum does have writing before registering enable and a guest reads a thread, the editor does get initialized upon initial page load although the editor is usually way below the fold.

This is a significant waste of resources in both bandwidth and JavaScript processing time as most of the time it will not be used at all.

This should be done in a way so the editor does only get initialized if it is really being used.

 

[Mike]

This isn't really a "bug" per se, though it is something we're aware of and something we have some thoughts on. Roughly, this would seem to fit better as a suggestion.

 

[Kirby]

Honestly, to me this is a bug as it severely affects performance by adding over 145 kB of JavaScript for every first threadview by a guest - that's a 100% increase if I got the math right.

I'd rather not enable this feature (which I expected to not be used that often anyway) if it stays this way then to make the already slow JS even slower

 

[PaulB]

Honestly, to me this is a bug as it severly affects performance by adding over 145 kB of JavaScript for every first threadview by a guest - that's a 100% increase if I got the math right.

I'd rather not enable this feature (which I expected to not be used that often anyway) if it stays this way then to make the already slow JS even slower

At 145 KiB, it's likely that the round-trip time is going to have a greater impact for most users than the size itself. You can likely mitigate that for most users with HTTP/2 server push.

 

[Anatoliy]

Honestly, to me this is a bug as it severly affects performance by adding over 145

300k of unused font awesome icons, 300k of unused css... who cares about extra 145k and execution time of js that will be used once out of million visits?

 

[PaulB]

300k of unused font awesome icons, 300k of unused css... who cares about extra 145k and execution time of js that will be used once out of million visits?

I think you can set FA to load from a popular CDN, in which case the visitor will probably already have it cached before they visit your site, right? I'm actually surprised that isn't the default.

Also, keep in mind that CSS and JS normally compress quite well.

Edit: Interestingly, despite using Cloudflare, xenforo.com seems to be using GZIP instead of Brotli. I'm seeing significantly smaller transfers when using Brotli instead--about 64 KiB CSS and about 108 KiB JS.

 

[Anatoliy]

I think you can set FA to load from a popular CDN

where is it? I know about such an option for jQuery only.

 

[eva2000]

I think you can set FA to load from a popular CDN, in which case the visitor will probably already have it cached before they visit your site, right?

won't work in future, google chrome is isolating and partitioning the HTTP cache in their browser so you can't share the cache in future so 3rd party CDN cache will end up useless. Future is having CDN served from your own domain i.e. Cloudflare CDN reverse proxy.

 

[PaulB]

where is it? I know about such an option for jQuery only.

Set @fa-font-path in setup_fa.less and update the preload links on font_awesome_setup accordingly.

won't work in future, google chrome is isolating and partitioning the HTTP cache in their browser so you can't share the cache in future

It's probably going to be a while before that goes live, so using a CDN is a viable stop-gap--although that does come with some minor security and privacy concerns.

References for anyone else who's interested:

• Chrome status: https://www.chromestatus.com/feature/5730772021411840
• Chromium meta bug: https://bugs.chromium.org/p/chromium/issues/detail?id=910708
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1536058
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=110269

 

[eva2000]

It's probably going to be a while before that goes live, so using a CDN is a viable stop-gap--although that does come with some minor security and privacy concerns.

Yeah true though starting on Cloudflare now if you're new to it, will take some time to get everything right for Xenforo so might as well start now

 

[Masetrix]

I think you can set FA to load from a popular CDN, in which case the visitor will probably already have it cached before they visit your site, right? I'm actually surprised that isn't the default.

It doesn't matter if more and more overhead is loaded from a CDN or your own server, you have to see this from the receiver, not everyone has a gigabyte connection, especially with the cell phone.

If there are long loading times on mobile phones, the users are gone before the page is fully loaded - Google (and others) is absolutely right.

 

[PaulB]

It doesn't matter if more and more overhead is loaded from a CDN or your own server, you have to see this from the receiver, not everyone has a gigabyte connection, especially with the cell phone.

I'm not talking about a CDN like Cloudflare; I'm talking about a CDN for static resources that are used by a large number of sites, such as cdnjs. If you're using the same CDN as other sites, the data won't be loaded when a user visits your site, even if it's for the first time--it's already cached from other sites they've visited, and the URL is exactly the same. There are efforts to phase this out due to security concerns, but it'll be a while before that happens.

 

[Kirby]

Pseudo-Code

displayEditorPlaceholderLikeProfilePostComment(['loadJsAndInitUponClick' => true]);

if (isLoggedIn() || $requestGovernedByServiceWorker)
{
    if (browserSupportsIntersectionObserver())
    {
        insersectEditorPlaceholder(['loadJsAndInitUponIntersection' => true]);
    }
    else
    {
        fireEditorInitOnPoorBrowser();
    }
}

At 145 KiB, it's likely that the round-trip time is going to have a greater impact for most users than the size itself. You can likely mitigate that for most users with HTTP/2 server push.

Server Push is not a silver bullet to solve all issues.

Pushing resources that are required in critical rendering path is great, but you really do not want to push resources that are only needed below the fold on bandwidth limited devices as that could in fact decrease performance.

 

[Karelke]

A better solution would be using ES6 modules and load the JavaScript when the editor scrolls into view.

 

[Chromaniac]

not a developer. invision seems to load the editor on clicking. i am not really a fan of that (as a logged in user). but for guest view, something like that might have some utility?

 

[nrep]

Has anyone got a workaround for this in the meantime? It's an amazing feature, but I wonder if there's a way to minimise the loading/seo impact for guests.

 

[Chromaniac]

i disabled rich text editor and it works out fine imo. not sure if the option for that was added at a later stage? it just loads a text box now. i really hate the click on editor to load full version component. not sure why i even suggested that above.

 

[PaulB]

Server Push is not a silver bullet to solve all issues.

Chrome is dropping support for push anyway, and it’s already removed from their HTTP/3 implementation. I noticed a significant drop in Core Web Vitals after enabling HTTP/3. So much for that idea.

 

[nrep]

i disabled rich text editor and it works out fine imo. not sure if the option for that was added at a later stage? it just loads a text box now. i really hate the click on editor to load full version component. not sure why i even suggested that above.

Oh I hadn't seen the "Allow guests to use the rich text editor" box, that's great! Thank you.