perf: compress static files

[SebastianKohler]

During the build step, static files of type html, xml, txt, css, js, svg, ico, json, ttf and otf in dist/app/browser/ are precompressed using gzip. Files smaller than 1300 B are not compressed. If there is a compressed version of a static file, nginx is configured to serve it instead of the uncompressed file. The necessary configuration commands for compressing dynamically generated html on-the-fly have also been added to the nginx configuration (nginx.conf), however, the commands have been left commented out because of the increased server load associated with on-the-fly compression.

[SebastianKohler]

@rasek-sls I have tested locally that nginx sends the gzipped version of files with this – even on-the-fly compression of dynamically generated html works if you uncomment those lines–, but is there something else required for this to work in the production environment?

I added gzip_proxied no-cache no-store private expired auth; since it is used in many examples. Is it needed with a reverse proxy like HAProxy?

[rasek-sls]

It may be worthwhile doing some testing to see how much load is added from simply setting gzip on at the server level - that would simply compress everything on the fly without need for an additional compression step in the node build process.

At present, our HAProxy does not use gzip compression itself, responses from servers are simply passed as-is (in other words, if the server uses gzip the gzipped response will be sent to the client, and if the server does not use gzip, the uncompressed response will be sent to the client)

We could enable on-the-fly gzip compression in HAProxy, but that would impact all our sites, which may have a greater CPU impact.

In other words, this looks fine and should work great in production, but I'm not sure it's necessary over simply enabling on-the-fly gzip compression in nginx at the server level of the config and letting it compress everything. Gzip is pretty lightweight these days.

Have you tested the level of added CPU load locally? You could use something like https://blog.projectdiscovery.io/introducing-katana-the-best-cli-web-crawler/ and monitor the CPU load using docker stats.