Frontend Caching and Optimization

[pyrox0]

What would you like Grimmory to do?

Currently, the frontend CSS and JS is re-fetched on every page load. This blocks loading thumbnails and heavily decreases the percieved performance of the frontend.

What problem does this solve for you?

Since the static assets for the angular frontend(*.css, *.js) are uncached, sending a Cache-Control header with the value no-cache, no-store, max-age=0, must-revalidate, which means that they are always refetched. This could be improved to at least a 1 day lifetime, if not longer. In general, Spring Boot's example for static resource handling(https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html) uses a 365-day cache lifetime, which would be appropriate.

Caching is fine here because Angular already hashes the files during build, so long cache lifetimes are fine, if there are new JS/CSS files, they will be re-fetched only when they are needed(i.e when a page is loaded with a new index.html containing a new root main-<HASH>.js file.

I'd also like to mention the possiblity of pre-compressing some or all of the static assets, which reduces their size on-wire, which again helps latency and bandwidth usage, as it's generally suggested to use at least gzip, but preferably brotli compression.

Anything else?

Currently, doing a Lighthouse test against my personal grimmory instance reports a Performance score of 64:

With roughly 4MB of javascript and CSS delivered to the frontend on every reload, the page score drops drastically. The Largest Contentful Paint(LCP) metrics appear to be because of thumbnails, so I'm not sure of a way to improve that, but additionally setting font-display: swap on the root CSS font-family should help reduce the amount of layout movement and thus increase the feel of the UX since the layout will not have to be reflowed as heavily.

Lighthouse also mentions a very long maximum network dependency path of over 2 seconds, which could be alleviated somewhat with the above static asset caching, since half of the requests in that chain are static assets.

Also, I did not use AI at all when writing this, I'm a web performance nerd personally so this kinda stuff is what I do for fun lol.

Want to help out?

I'm happy to help test and give feedback

Before submitting

• I've searched existing discussions and this hasn't been suggested yet
• I've reviewed this report and have completed it as fully as I can

[balazs-szucs]

Hi,

apologies for missing this, this is a very cool write-up. I have merged a rather large amount of cacheing related stuff, so not how up-to-date this write up going to be after release, but from quick glance i think it is still going to be relevant.

I think we should defo take a deeper look into this, would be a very large win for UX.

[balazs-szucs]

I think, some of the caching frontend stuff can be also better achieved via migrating from Tomcat towards rootles nginx, right? I think that has much easier to implement and better fine-tuned caching config. Anyways, i made issue out of this, I am generally very open to this, if you have more to share, please feel free to do so.

[pyrox0]

In general, what I've written up is what I consider the largest wins for UX, but I can certainly look into this more once more fixes have been merged into grimmory.

Nginx does support on-the-fly compression of assets, but I would highly recommend pre-compressing them as that allows for higher compression levels to be applied(since you aren't limited by request latency) and reduces CPU usage at runtime.(nginx also has built-in support for using gzip, though not brotli, which requires a module such as google's ngx_brotli) It can also do caching well, yes, but any web server can apply the proper cache-control header to set expiration dates for assets.

[pyrox0]

Honestly, I would more highly recommend the caddy webserver over nginx, since it provides better defaults and also supports all compression algorithms without needing an external addon like nginx does. While its auto-https feature may not be as useful here since i assume this may be behind some other reverse proxy, i still find that caddy itself has been a lot better for me than anything else. Also i find its configuration syntax much more readable and understandable.

[balazs-szucs]

Sounds great, yeah, i am afraid i probably have a bit less experience in this as you. From what i can tell after a quick search Caddy seems to be a hot-tip, many thanks!

In the meantime I downloaded lighthouse too, some of stuff in insights seems to be rather trivial to implement so I'll take a more closer look at that, and put Caddy as a ticket after I could read up on it a bit more.

Sadly we seem to have not really progressed since 2.3.0 i can see almost same info as you posted:

But; this just means we can improve :)

Thank you again!

[obviouslyallie]

Created in #744