Static assets in Argo CD UI (extensions.js, fonts, images, etc.) lack caching headers and ETags

[sherifabdlnaby]

Summary

Some static assets in the Argo CD UI (such as extensions.js, fonts, CSS, images, etc.) are served without proper Cache-Control or ETag headers. This causes browsers to re-download these assets on every page load. In our case the extensions.js file is over 1.5MB in size, and it blocks the page loading. Especially on a slow network this can render the Argo CD UI unusable.

Motivation

Make ArgoCD UI Snappier!

Proposal

Well, ideally ArgoCD server can calculate hash and serve hashed file names with indefinite caching headers. I haven't done my homework myself to explore the feasibility of this though. Alternatively, we can support ETags to respond with 304 Not Modified. Or add a short-term cache control header that the user can customize.

Mitigation

Users can use their Ingress controller to set Cache-Control on Argo's behalf. But it's better if this work out of the box.

[pks2906]

Hi! I’d like to work on this.

From a quick look, this seems like it could be addressed by:

• Adding Cache-Control headers for static assets
• Possibly enabling ETag support for conditional requests

Before I start, I wanted to confirm:

• Should this be handled at the ArgoCD server level?
• Or via UI build (e.g., hashed filenames)?

Happy to explore both approaches.