htmlcompressor
htmlcompressor copied to clipboard
serg472
Add image compression to lib
I'd love to see image compression added to your already excellent lib. You
already compress html, css, and js, so why not images as well? Images are some
of the biggest resource hogs on a website, so they're a good candidate for
inclusion. I'm thinking it could be as simple as adding support for tools like
pngcrush (or any other PNG optimizer tool) and/or jpegtran for JPEGs. You
already include external dependencies for yuicompressor, so adding these other
tools shouldn't be that much of a stretch. Or, am I wrong? I've been looking
for an all around solution for quite some time now... and you're lib is the
only one that even comes close (besides google's mod_pagespeed which I can't
use).
Original issue reported on code.google.com by [email protected] on 28 Mar 2011 at 8:34
Sorry, I don't think it is a good idea. It seems like a completely independent
task from compressing html, so it can be just done separately. Bundling it with
htmlcompressor won't provide any benefits besides packing everything into one
zip file.
Original comment by [email protected] on 28 Mar 2011 at 9:14
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
While I don't agree with your reasons completely, I do respect them. After
all, this is your baby and I don't want to tell you how to run it. You're
doing a good job of that already. Anyway, if you want to add a new site to the
list of those already using your lib then feel free to add www.spafinder.com
(we also use it on our sister EMEA sites).
Original comment by [email protected] on 29 Mar 2011 at 1:15
I am not taking it as if you are telling me what to do, you are just providing
ideas for improvement, and I appreciate it. I will leave this issue open so
others who find it interesting can vote on it and discuss it further.
I will add your site to the list, thanks.
Original comment by [email protected] on 29 Mar 2011 at 3:39
While image compression is certainly out of scope of this...
I could imagine inlining via data URIs could potentially be in scope. (but I
would only want it for files <5k that are referenced via <img src=...> So
that's already pretty limited.
Original comment by [email protected] on 30 Mar 2011 at 11:49
Converting images into inline base64 seems like a pretty exotic task. The
popular (and proper perhaps) way of storing layout images is css sprites,
nobody has images right in html as img tags nowadays. There are pretty nice css
sprite compilers and optimizers out there, that's what I would look into for
optimizing images. But again it is a completely independent process from html
compression.
Original comment by [email protected] on 31 Mar 2011 at 1:45
Agreed,
See also: https://github.com/remy/inliner
and http://jbueza.github.com/cid/
Original comment by [email protected] on 31 Mar 2011 at 1:51