Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix compression / ETag support for static files #4272

Closed
EZForever opened this issue Jan 5, 2025 · 2 comments
Closed

Fix compression / ETag support for static files #4272

EZForever opened this issue Jan 5, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@EZForever
Copy link

EZForever commented Jan 5, 2025

Describe the solution you'd like

As mentioned in title, enable server-side gzip/zstd compression for at least static files, and add proper ETag support to allow clients to cache static files (or, at least, base your HTTP Date header on file modification time, not request time).

Type of feature

User Experience (UX)

Additional context

Currently (as of v0.23.0), all frontend Javascript code are served as a single app.XXX.js file, which can be several MBs in size. Loading it on a weak Internet connection could easily take seconds.

An example of opening Memos front page. The app.DVfXlyve.js file takes ~6s to load on my connection.
image

This alone is not a problem (at least when comparing with that 17MB WASM versions ago); however, this file is being served as is, as in, whenever a client requests this file, its contents are responded directly, with no compression or even ETag in headers. HTTP Date header, the last chance for the client to cache this file, even varies for each request.

Requesting the file manually shows only a minimal set of HTTP headers are responded, with Content-Length set to the full size of the file, indicating no compression is done. The Date header varies for each request, making client-side caching impossible.
image

All of this basically means clients cannot properly cache any static file served by Memos. Whenever a client opens Memos page, or just hitting Refresh, all static files must be re-downloaded from Memos server. Let me repeat it again if that doesn't sound important to you: Every time you open Memos or hit refresh button, the same set of static files are re-downloaded, severely wasting both server and client bandwidth; and, if on a weak connection, opening Memos EVERY SINGLE TIME would take SECONDS. This is really bad UX, and a disrespect to the ones paying actual money for server resources to host Memos.

The simplest way to solve this issue is to add ETag headers, or at least fix your Date header so it does not vary for every single request. And, for good measure, please enable server-side compression for static files, too, as that would save at least 50% of bandwidth (based on measurements done by myself) for every page load.

@EZForever EZForever added the enhancement New feature or request label Jan 5, 2025
@EZForever
Copy link
Author

P.S. Please do not go and tell me that CDNs solves this issue; for one, not everyone on the world got that spare money to waste on CDNs for a single site that only a single person will ever access; and more importantly, CDNs won't help since Memos is the one who's not cooperating. Without proper indication that a file can be cached, any RP/CDN would have to serve the server response as is. I personally runs a Nginx RP in front of Memos and several other services, and caching works all other services, except Memos.

@EZForever EZForever changed the title Enable compression / ETag support for static files Fix compression / ETag support for static files Jan 7, 2025
@EZForever
Copy link
Author

nvm, confirmed that this is a bug now. Will open a new issue.

@EZForever EZForever closed this as not planned Won't fix, can't repro, duplicate, stale Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant