foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
foxfirefey ([personal profile] foxfirefey) wrote in [site community profile] dw_dev2013-01-29 11:39 am
Entry tags:

Possible low hanging optimization fruit

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?
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2013-01-30 11:26 pm (UTC)(link)
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.