I do apologize if this has been raised before, but it's
4 5 6 o'clock in the morning and my freaking brain just won't let me go back to sleep until I've put my thoughts to paper, so to speak... so here goes.
I'd rate the severity of the problem as "mild, but annoying" and "100% OCD-unfriendly".
The issue is the following,
in human-friendly terms:
The resetera editor component wastes bandwidth.
The Resetera editor for the Text Input area above the "post reply" button at the bottom of the page is a javascript giant with a whopping 400+ Kilobyte file size, even minified (made smaller with some coding/formatting tricks). While a pared down "mobile" version of the page without avatars and whatnot still easily goes above 1 Megabyte, that's nonetheless a hefty chunk of the bandwidth wasted on useless stuff.
It's a teensy bit on the obese side for a friggen BBTAG editor anyway, if you ask me, but at least there's caching to save us - meaning we only need to grab that fat bastard during the first time we visit resetera. Future requests will just keep using the already downloaded monster, right? Well... yes... but there's some issues.
- The server (/cloudflare?) intentionally(?) does not support resuming of this file, so even if you grab 399999 of the total 400000 delicious bytes of javascript goodness before the cheap Hotel Wifi disconnects you for a fraction of a nanosecond, you have to download the entire thing again. Even though only a single byte is missing. Heck, tell it you already have the file and it'll send it over anyway, just in case.
- Plus, it doesn't report the file size so your Browser has to guess how much longer it has to slurp the entire page. This makes the progress bar unreliable whenever the editor has to be downloaded, among other things. Small issue, but hey.
- The server (/cloudflare) also advises the Browser that the editor can be considered usable for only exactly four hours via cache control headers (which are sent along as you download the file). If you load a resetera thread and wait four hours and one second before pressing reload, the entire nigh-half-megabyte monstrosity will be downloaded again. Every four hours, the Browser has to grab it again, regardless of whether it has been changed since. Now... I dunno about you folks, but I have slight doubts that the xenforo post editor is such a hot&fresh item that we absolutely need three updates a day in case a new feature pops up. It has a version tag at the end anyway (the ?_v bit in its address if you scroll down), so newer versions would likely have a distinct URL anyway, thereby negating the sole advantage of a short cache lifetime.
So that means that mobile users, even with the forum account set to "cellular", will have to expect at least one Megabyte of rather needless bandwidth wastage per day if they browse Resetera during their commute to/from work. Probably more, in case the download gets interrupted. Which isn't exactly unlikely, with mobile connectivity on public transport being spotty at times (tunnels and cell handovers). It's a rather odd design decision, if it is one.
The nitty gritty:
How to check/reproduce using wget:
To illustrate the inability to resume downloads, run this command twice.
You may opt to omgwtfbbq the download during the first run by pressing CTRL&C quickly enough to get a "properly truncated" copy of the editor.js file. Then run again to attempt to resume the download.
Don't worry though, even if it's completely downloaded, Resetera's server doesn't give a fuck and just shovels out the entire thing anyway.
Bash:
wget "https://www.resetera.com/js/xf/editor-compiled.js?_v=4839d74b" -O editor.js -o editorlog.txt -S -d -c
This will attempt to grab the full file or at least the remaining bits of the current version of the editor, and dump it together with a suuuuper wordy logfile in your current working directory. For less wall-of-text-iness try -v instead of -d, but you'll lose out on some info.
The theory:
This is what the average browser would send in case of a resume attempt (I've stripped out most headers since they're not relevant to the issues):
(in this case, requesting to resume from a fully downloaded file)
And this is the similarly vastly truncated response from the cloudflare-proxy'd server:
I've taken the liberty to highlight the bits that cause some of the issues.
The server replies that the file has been located on its end (
200) and will be sent in its entirety, pretending to never have gotten the Range request from the Browser - the correct response for a partial file would be
206, or
304 if the file has been unchanged/complete.
It furthermore doesn't report file size, so the Browser can't compare that to the file it has and go "oh, same size, I must have it already", while also denying it the ability to accurately predict how much of the page has been downloaded already.
Last but not least, it recommends a lifetime of
14400 seconds in the cache, which is exactly four hours. By the way, the reply also reveals that the current editor is roughly
5 days old. The more you know.jpg
This is all kind of weird. Seems like it's intentional, maybe? But why?
The external bla:
https://www.codebyamir.com/blog/a-web-developers-guide-to-browser-caching - a very quick and easy summary of the HTTP caching headers/mechanism for those with passing interest.
https://developers.google.com/web/f...ce/optimizing-content-efficiency/http-caching - a bit more in-depth.
Now, why is this "noteworthy"?
First, it's a waste of everyone's time and bandwidth.
Second, the huge editor component not loading reliably causes usage issues: The entire post editor text entry area does not show up, you have no way to create or edit a post unless you reload the page. Basically, there's just the Post Reply and Preview buttons and nothing else down at the bottom of the page. Read-only Resetera. 'tis annoying and has happened to me on occasion.
Edit: Improved readability. Now off to sl... why is it half past seven already ajvduasjdfiajvcibadcijdk
