You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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
changed the title
Enable compression / ETag support for static files
Fix compression / ETag support for static files
Jan 7, 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.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.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.The text was updated successfully, but these errors were encountered: