compression pr #8
No Assignees
clashofclanselixircollector
clashofclanselixircollector
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: EaglercraftX-Client-Collections/EaglercraftX-Site#8
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "(deleted):main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When I cloned this repository on my personal computer, I discovered that the WebAssembly files could be compressed downwards by almost 3 times, and the JavaScript files could, with exceptional minification and compression, be simplified with tsup by hundreds, if not thousands, of bytes.
To start this off, I'd recommend merging this into a separate branch and deploying it to somewhere on the "eaglercraft.win" origin (because of the JSPI thing that you guys seemingly already solved).
I didn't mess up any CSS, and yes, I did add a package.json file, but I am not planning on making this with an HTTP framework; the file is there merely for efficiency.
That being said, the package.json file is there for you if it seems you need to compress the JavaScript and WebAssembly files even more than I already did.
NOTE: Compressing the WebAssembly files takes time, and yes, it does complete after around 4-9 minutes.
There's also one very last side note: I simplified the logic for checking if the page is running under the strict file protocol from
document.location.href.startsWith('file:')tolocation.protocol === 'file:'in the large client HTML files.aw hell naw jasper found the gitea
do we need to compress it, its only 1gb, just send 1 cmd to config git and done
yes, it may help decrease sudden kickoffs from servers and will generally increase our traffic
@Sevi i was fully aware about this a while ago lmao
we can easily get much better speed-ups by just uploading all the eagler files to cloudflare (which ive been planning on doing), and this pr will also make it harder for people to config eagler to add default servers and stuff like that, because the config is part of the js. i don't really see a point in merging this.
@qwertychomp, well, the wasm files are the second priority, but bundling the javascript files that power the clients and then changing the
<script src="..."></script>to reference the corresponding files in the distribution folder will certainly make this even faster. that being said, i highly support the uploading of the eagler files to cloudflare as it will, combined with the mass optimizing by tsup (which uses esbuild) most likely decrease sudden kickoffs from clients and increase the overall performance. think of the original non-minified eagler javascript files as ultraviolet script files. i think (but i'm not entirely certain) that all the eagler javascript files were bundled by webpack or something, which is already infamous for being complex and not being as fast (in both the bundling time and the javascript file initiation speed in the browser) as esbuild. that being said, the wasm files were compressed by brotli (which is already well-known for being a web compression algorithm that results in faster load times), so i believe they will load faster than they previously did. if not, i'll try using wasm-opt to optimize the files reliably.with that out of the way, i can also tweak the package.json file to have a script that is accountable for letting the user edit the config in the minified files directly in the terminal with some javascript vim/nvim opener, if that makes more sense, or even on the website if that would be easier for users.
idk about priority, most people use wasm its faster but all of them are wanted
also @qwertychomp wdym upload to cloudflare, we are not using pages
@quartinal you could try doing this on your fork then we will see when u got it and working
@PrestonT500, visit https://eaglercraft-xi.vercel.app and check out my fork for yourself
preston i mean upload the eagler files to cloudflare cdn
@PrestonT500
@quartinal the discord popup is on purpose so people know about our server. Also they can just click cancel or our don't show again checkbox that does work. clashofclanselixircollector might deny cuz of this, they are assigned
The repo is the same size, I meant try it compressed.
Edit: Actually your repo is bigger than ours
@PrestonT500 why do we need the discord popup when there is a discord join button right below it that users will see on page load? but if it's actually needed for more attention or something, i can just add a
prompt(...)yes/no/dsa (don't show again) function (much easier to reliably develop than an html/css/js popup) that executes on page load unless otherwise specified in a localstorage key.also a potential reason why my repo is bigger is because of the added files. and even if that's not the case, that doesn't mean the files won't run faster. but even that's not the overall point of this pr. the main point was just to simplify the code.
i still have some work to do on the css files.
@quartinal we already made it so "easier" doesnt matter, anyway its up to @clashofclanselixircollector
@quartinal did you try it compressed yet
yes, i'm also trying to use
@espcom/esbuild-plugin-compresswith tsup to compress the .js files to .js.br files which ultimately are faster with brotli compression and smaller.@quartinal ok when you're done push it so i can see it
@quartinal how much do you think this could compress our repository. Also you might want to fix the conflicting changes. And we are using LFS now if that matters.
it definitely could compress our repository by many kilobytes, as esbuild not only compresses, but simplifies long functions and statements, which ultimately improves the overall load time and contentful paint. but that's not all I was aiming for with this pr. I was also aiming for simplifying the code and adding some features that will generally improve the overall user experience both on the homepage and playing the game.
also, by lfs do you mean large file storage? because that doesn't really matter in my opinion and in the context of what I was aiming for with this pr.
also, could you resolve the merge conflicts in a separate branch and then merge this pr into that instead of the main?
nvm, i'm just gonna create a new pull request lol.
Pull request closed