Possible low hanging optimization fruit

[foxfirefey]

So, I've been doing some heavy web page optimization at my day job and on a whim I ran an analyzer on some DW pages and found what I think could be a very easy-to-make-happen optimization: we're not gzipping the JS/CSS static files when we serve them.

Examples:

* The new entry page: 221.2KiB (70% reduction) -- quite the savings when the entire bundle is 349.9 KB
* My reading page: 149.3KiB (68% reduction) -- when the total page is 541.5 K, so decent

Would this be as easy to set up as I think it would, or are there other reasons not to do it?

Comments

[exor674]

If we add it, would it be worth it to add gzipping to the build-static.pl script, that way we don't have to gzip the static files on the fly?

[pauamma]

What are you doing in my brain? :-)

[mark]

I expect that would be hard to do because of CONCAT_RES. We'd have to know what concatenations we're using (there are several, depends on the pages) and that'd be a hard list to maintain. We'd inevitably forget one.

Doing the compression on the fly is fine since we cache the results in varnish. We wouldn't be compressing them very often, just when they change or when they fall out of the cache.

Since doing it at build time doesn't save us much, I'd be disinclined to take the effort of doing that.