Rewrite background images

[A Boston]

Have you planned on supporting resize_image (or insert_image_size)

for those provided in CSS, as such

 

div
{
background:url(img_flwr.gif);
background-size:80px 60px;
background-repeat:no-repeat;
}

[Joshua Marantz]

Yes this should work now.  Can you point us to a site where it is not working?

[Jan-Willem Maessen]

On Wed, Feb 8, 2012 at 9:01 AM, Joshua Marantz <jmar...@google.com> wrote:

Yes this should work now.  Can you point us to a site where it is not working?

Actually, I think there may be a misunderstanding here.  Are you looking to have mod_pagespeed automatically resize a background image when you specify background-size, if the original image size is different?  Or do you just want us to insert a background size if one is missing?  Or, as a third option, do you want us to trim away the unused part of the image?

We don't do this at the moment, and we'd have to think it over carefully: it can easily undo any image spriting that might have occurred in the original site, so it's not at all safe.  We've also avoided building a CSS rule engine thus far, as applying rules to the DOM is among the most expensive parts of page rendering, and is non-portable among browsers one you throw in things like IE-specific CSS hacks.

That said, I'd welcome a clearer description of what you're looking for here; what you're asking for might well be easier than what I'm imagining.

-Jan

[A Boston]

latent response here. sorry about that.

it seems the image is resized (given the pagespeed.ic.hash.png ) but not trimmed. whatever the case, its still very large and costing a lot of wasted bandwidth.

in my case, the background image is inlined, as such.

style="background:url(wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png) center no-repeat">

but the enclosing class is considerably smaller than the actual image size. the desired display size is specified in an adjoining css file

.slide {
    width:230px;
    height:410px;
    overflow:hidden;
}

this case seems tricky.

might pagespeed resize and,or trim if a background-size was added to the inline style.

style="background:url(wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png) center no-repeat background-size: 230px 410px;">

a

[Jan-Willem Maessen]

On Wed, Feb 8, 2012 at 11:03 PM, A Boston <adrian...@gmail.com> wrote:

latent response here. sorry about that.

it seems the image is resized (given the pagespeed.ic.hash.png ) but not trimmed. whatever the case, its still very large and costing a lot of wasted bandwidth.

in my case, the background image is inlined, as such.

style="background:url(wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png) center no-repeat">

but the enclosing class is considerably smaller than the actual image size. the desired display size is specified in an adjoining css file

Ah, OK, so you are in fact looking to trim away the unused portion of the background image.  As I noted earlier, that's currently not a priority -- it actually undermines image spriting, which relies specifically on using CSS width and height attributes to select a portion of a larger background image.  For example, if we ran this "optimization" on www.google.com it would dramatically slow down the loading of the page!

-Jan

[A Boston]

in fact, i dont care whether its trimmed or scaled. its just too big and slow.

i'll gladly settle for scale, which doesnt seem to be happening.

here is a background images with and without pagespeed. note the same size. same compression. 92%

http://loudspring.com/wp-content/uploads/2012/01/SungGoldshot4.png

http://loudspring.com/wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png

what is pagespeed doing to this image? how can we debug it.  'ic' have any significance. how about adding codes for each transform.


the issue could be a combo of inline css and adjoining css file.

style="background:url(wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png) center no-repeat">

thus, one though was adding the background-size to the inlined css. im guess that matching up classes in various files is tricky.

style="background:url(wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png) center no-repeat background-size: 230px 410px;">

thanks for your help.

adrian

[Jan-Willem Maessen]

On Fri, Feb 10, 2012 at 1:45 PM, A Boston <adrian...@gmail.com> wrote:

in fact, i dont care whether its trimmed or scaled. its just too big and slow.

i'll gladly settle for scale, which doesnt seem to be happening.

here is a background images with and without pagespeed. note the same size. same compression. 92%

http://loudspring.com/wp-content/uploads/2012/01/SungGoldshot4.png

http://loudspring.com/wp-content/uploads/2012/01/xSungGoldshot4.png.pagespeed.ic.qyuxum5Juk.png 

what is pagespeed doing to this image? how can we debug it.  'ic' have any significance. how about adding codes for each transform.

The ".ic." is the code corresponding to image recompression, and the absence of image dimensions at the front means mod_pagespeed couldn't resize it (as I described earlier in this conversation, we simply can't tell for certain if it's safe or not).

That said, I downloaded the images, and mod_pagespeed has indeed recompressed the latter image, from 58K to 38K.  I expect further improvement is possible, not just by trimming / resizing the image, but also by transforming to 8-bit color (should cut image size by approximately 4x).  Given the small color space I'm not sure why this isn't happening already, and will do a bit of investigation.

-Jan