Fix Issue 15449 - CSS and JS files should be minified #2311
Conversation
wilzbach
requested review from
andralex,
CyberShadow and
MartinNowak
as code owners
|
What do you think about doing the same thing as DFeed? https://github.com/CyberShadow/DFeed/blob/master/GNUmakefile#L4 It would give us control over the exact version of the tool. It seems likely that the output will change between versions, so that will help us avoid unexpected changes. |
posix.mak
Outdated
| @@ -74,7 +74,7 @@ | |||
| # | |||
| # DIFFABLE=1 Removes inclusion of all dynamic content and timestamps | |||
| # RELEASE=1 Release build (needs to be set for the `release` target) | |||
| # CSS_MINIFY=1 Minify the CSS via an online service | |||
| # MINIFY=1 Minify the CSS and JS (requires) | |||
wilzbach
force-pushed
the
yui-compressor
branch
from
2c8240d
to
eb36b54
Compare
The last update has been in 2013 ... |
wilzbach
force-pushed
the
yui-compressor
branch
3 times, most recently
from
d38ac47
to
8fca0e1
Compare
|
BTW while I was at it, I added the HTML_COMPRESSOR too. Before: After: It's not much, but it's a consistent ~10% decrease for almost for "free". |
|
There is little benefit from minifying HTML. It just strips whitespace, which compresses well anyway. It also makes inspecting HTML harder on the live website. Same with CSS, though we have more comments there. Only JS generally minifies well. |
wilzbach
force-pushed
the
yui-compressor
branch
from
8fca0e1
to
7118f31
Compare
So I tried Now an individual, randomly picked file: And now the same file compressed: It's still 10% (even with compression)
Good point, but the developer tools use an auto-formated AST anyways and we could add |
wilzbach
force-pushed
the
yui-compressor
branch
from
7118f31
to
9c75365
Compare
|
I don't like minifying anything. It makes the live site a black box - you can't hit "view source" of something you see there and get an idea of where to edit for a PR, and complicates the build process (so making that PR is more fragile...) for, like you showed there, at best about a 10% difference (heck your example is even less than that! It is like 400 bytes.). I can see where that's sometimes worthwhile... but I don't think we're in that category. I doubt the 10% change is going to bump us into the next hosting tier or something like that, and the site isn't huge so in real numbers, that 10% means a download time difference of... a quarter of a second... on dial up. Totally negligible on today's internet. gzip makes a big difference and is virtually free. But minify is a tiny difference that doesn't justify its own cost. |
That's a suspiciously large difference. Where is the 40% reduction coming from? The filenames in the command line and output are different. Was there an experiment error? |
|
Yes, sorry - the updated numbers for this experiment: |
|
Thanks. I agree with @adamdruppe then, I don't think we win enough to compress HTML. There are more performance metrics to consider than file size. |
Hmm, can we at least compress CSS + JS files? |
A start anyhow:
(the biggest chunks are jQuery + CodeMirror, but the other scripts are reduced by half.)
CC @JackStouffer
@CyberShadow would it be possible to install YUI on DAutoTest and set
MINIFY=1?(I picked YUI because it was the only compressor that is available in Debian stable.)