perf(web): optimize response sizes for initial page load

[mertalev]

Description

This PR tries to optimize the initial page load and generally reduce response sizes.

• Making the AssetViewer a dynamic import since it's bulky and doesn't need to be loaded immediately
• Enabling compression at the fastest setting (even the fastest dramatically reduces response size, and slower settings see diminishing returns)
• Using webp instead of jpeg for Memory Lane

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	5b8cbf0
Status:	✅  Deploy successful!
Preview URL:	https://ac3f94b0.immich.pages.dev
Branch Preview URL:	https://perf-web-minify.immich.pages.dev

View logs

[jrasm91]

LGTM

[benmccann]

I just found this old SvelteKit issue: sveltejs/kit#5431. We used to have compression built-in, but had to remove it because it was regularly causing the server to hang. Unfortunately the fix still hasn't been merged: expressjs/compression#183. And you can't provide the answer to the question that the PR is blocked on as the repository has blocked all outside contributors from commenting 😕

The precompress option might be safer. Ideally we'd be able to use precompress to aggressively precompress the assets in brotli and then do a quicker gzip compression with compress here for dynamic responses. But I don't know how much we want to chance the server randomly hanging. Maybe we should read through that old issue and see if there were certain circumstances that would cause it to trigger. I don't remember all the details. I'm guessing precompress would cover most requests though and should get us an even larger gain.

[mertalev]

Oof, that sucks. I'll remove the compression for now until we take a closer look

[aviv926]

I just found this old SvelteKit issue: sveltejs/kit#5431. We used to have compression built-in, but had to remove it because it was regularly causing the server to hang. Unfortunately the fix still hasn't been merged: expressjs/compression#183. And you can't provide the answer to the question that the PR is blocked on as the repository has blocked all outside contributors from commenting 😕

The precompress option might be safer. Ideally we'd be able to use precompress to aggressively precompress the assets in brotli and then do a quicker gzip compression with compress here for dynamic responses. But I don't know how much we want to chance the server randomly hanging. Maybe we should read through that old issue and see if there were certain circumstances that would cause it to trigger. I don't remember all the details. I'm guessing precompress would cover most requests though and should get us an even larger gain.

It seems that this project is not going to receive a commitment soon, there is this project that received a commitment 3 days ago and a year ago and he is the one who offered the PR
which is not merged into main

Maybe you should keep an eye on it?
https://github.com/fernandolguevara/compression/tree/master

[benmccann]

That's the fork that the fix (expressjs/compression#183) is coming from. It was called too hacky to merge as it relies on brittle Node internals, so I don't think we want to use it. The author of the PR wants to keep support for ancient versions of Node rather than address that, which means it will probably never be merged.

Unfortunately, all outside users are blocked from sending fixes, so it is likely to remain broken forever.

Perhaps we should build our own compression middleware into SvelteKit or polka or something.

[benmccann]

There was a PR to polka that Vite copied and has been using the past couple of years. I'll see if we can't get that merged to use. See here: sveltejs/kit#9593 (comment)

[mertalev]

That'd be awesome!