I'm accessing s.umeyashiki.org via QUIC.
Uncategorized
9
Posts
2
Posters
0
Views
-
-
@yuka
mine is using quic, except just using caddy reverse proxy (it supports it)
-
@yuka mine is using quic, except just using caddy reverse proxy (it supports it)@yonle nginx 1.29.6 also supports QUIC, but I don't enable it because it runs behind Cloudflare. Cloudflare uses H2 to communicate with the origin server, sadly no QUIC in transit, only the CF's frontend part uses QUIC.
-
@yonle nginx 1.29.6 also supports QUIC, but I don't enable it because it runs behind Cloudflare. Cloudflare uses H2 to communicate with the origin server, sadly no QUIC in transit, only the CF's frontend part uses QUIC.@yuka by the way, you might want to use this patch, which should speed up loading speed the next time you reopen stuffs: https://akkoma.dev/AkkomaGang/akkoma/pulls/1068
-
@yuka by the way, you might want to use this patch, which should speed up loading speed the next time you reopen stuffs: https://akkoma.dev/AkkomaGang/akkoma/pulls/1068@yonle Wooaah... smart optimization. I wouldn't have thought about something like that.
It took me some time to understand the pull request as there is no provided description in the PR. I can understand it now. That makes sense for local media uploads because the file name must be unique for that file, and it never changes forever.
FWIW, I've applied the immutable cache-control hdr for static-s.umeyashiki.org. I didn't change the Akkoma sources because it's purely served by nginx (except for the media proxy, I left it as is for the time being).
After adding the following directive in the nginx conf:
`add_header Cache-Control "public, max-age=1209600, immutable" always;`
And then after purging the Cloudflare cache, I verified it with curl that the header now contains "immutable". I hope it speeds up the load on my browser. Though I don't actually understand how it works behind the scenes.
Arigatou gozaimas -
R relay@relay.publicsquare.global shared this topic
-
@yonle Wooaah... smart optimization. I wouldn't have thought about something like that.
It took me some time to understand the pull request as there is no provided description in the PR. I can understand it now. That makes sense for local media uploads because the file name must be unique for that file, and it never changes forever.
FWIW, I've applied the immutable cache-control hdr for static-s.umeyashiki.org. I didn't change the Akkoma sources because it's purely served by nginx (except for the media proxy, I left it as is for the time being).
After adding the following directive in the nginx conf:
`add_header Cache-Control "public, max-age=1209600, immutable" always;`
And then after purging the Cloudflare cache, I verified it with curl that the header now contains "immutable". I hope it speeds up the load on my browser. Though I don't actually understand how it works behind the scenes.
Arigatou gozaimas@yuka you can simply cherry pick it, though.
but either way, you need to put it only on these endpoints:
/media/*/proxy/*/emoji/*(on ur akkoma fe endpoint)/static/js/*(akkoma fe endpoint)/static/css/*(akkoma fe endpoint)
-
@yuka you can simply cherry pick it, though.
but either way, you need to put it only on these endpoints:
/media/*/proxy/*/emoji/*(on ur akkoma fe endpoint)/static/js/*(akkoma fe endpoint)/static/css/*(akkoma fe endpoint)
-
@yuka I basically run a somewhat custom akkoma setup, optimized for roaming, slow internet, monitored bandwidth.
-
@yuka I basically run a somewhat custom akkoma setup, optimized for roaming, slow internet, monitored bandwidth.@yonle You're so cool. I wish my brain could understand that kind of complexity. Even today, I still can't configure my VPS correctly. My ability is still far away from configuring Akkoma to that level
