interpreting image compression result

Web Performance Optimization Discussions
1

For our site, page load testing identified compression issues such as this for about 10 images (.jpg, .png, and a .gif or two) :

Compressing and resizing http://www.burstschocolates.com/var/theme/images/September-Image.jpg could save 31.7KiB (80% reduction).

I’ve pushed a couple trial images through smush it but the resulting image appears to be the same size. Does that make sense? Am I not interpreting the compression issue correctly?

Also, most of the realizable gains shown in the results are <4kb per image. Unless there are many images, is that really much of a drag on load time?

Thanks for any advice.

2

Do you have a link to the test results by any chance? That sounds like a Page Speed check and it’s probably flagging images that are larger (dimensions) that the spot they take on the page (a 20x20 image in a 15x15 spot for example). That’s not something that smushit would help with.

3

At the moment I can’t. It looks like the vendor is interfering with our site. The main problem was a 10 sec to first byte lag (subject of another thread). After asking the vendor about it now I find that the web page load statistics are disabled, generating server error 500, internal error on url request. I’ll be asking the hosting service if they can tell what happened from audit info, and if they can reload the site from a historic copy.

I also need to talk to the vendor. They keep trying to sell us things. Now, after this latest change, they say we need to upgrade the site to fix speed issues. To me that makes no sense. The cause of the issue just seems to keep changing, and none of it seems right. Thanks for any advise.

4

Going back in the test history to 11/8, it looks like this is the last result that worked: http://www.webpagetest.org/result/141108_RJ_JQ2/

I don’t see any png’s flagged and there are only 3 JPEG’s that could be slightly smaller using lossy compressing (saving at quality level 75-85): http://www.webpagetest.org/result/141108_RJ_JQ2/1/performance_optimization/#compress_images

Lossy compression isn’t something that smushit does but to be honest, that isn’t where you should be spending you time. The 10 seconds TTFB is where all of your time should be going. There are a few static images from that same test that also took > 3 seconds which is pretty much a smoking gun that the web server is either not configured/tuned properly or that the host is WAY overloaded (I don’t see requests that slow very often, even on shared hosting).

If they can’t figure it out and try to charge you to solve it I’d HIGHLY recommend moving the site to another hosting provider.

5

Yes, I know the 10 sec to first byte is the priority. I asked this forum about it last week and we’re working on it, first asking the vendor what they had to say as they should have been aware of this. Ok, we’ll look further into the configuration.