1

I was looking at http://marcjschmidt.de/blog/2013/10/25/php-imagepng-performance-slow.html and towards the end of the document, I learned something from the chart at the end.

If I use a very high compression on an image, the processing time (including TTFB) will be higher and the download time will be smaller.

The opposite is true if I use low compression.

The problem here is if I pick too low of compression, then it will take substantially longer for people to load images on my site. If I pick too high of compression, then I believe the TTFB (time to first byte) value will be high. If that value is too high, then google might see my image loading speed as slow.

Currently for the desktop version of my site, I'm using full-sized images at 80% JPEG quality, and for mobile site, I'm using 66% quality.

I'm afraid if I raise the quality of the image (aka reduce compression) on either site, then there will be more data to download and some people might be billed high for data usage. My other option is to adjust the image size some more, but then if I go too small, visitors might complain.

So whats the best thing to do? adjust JPEG image quality to different values (more optimal values)? or do I shrink the images and pray for no complaints?

Improve this question
5
  • Are you generating images on the fly? If no, then that article doesn't apply to you. If yes, then you want to avoid that if possible.
    – Tim Fountain
    Mar 10, 2016 at 17:31
  • Using 66% compression jpeg is definitely going to have artifacts for the majority of your users. The compression ratio should be exactly the same on mobile than it is on the desktop because the MAJORITY of users have high resolution phones! with good DPI, especially on iPhones & Samsung. Additionally ones bandwidth allowance each month shouldn't even be a consideration, that's there problem not yours. Additionally, a huge percentage of people use free hotspots. Finally TTFB has nothing to do with the downloading of page resources.
    – Simon Hayter
    Mar 10, 2016 at 17:38
  • TTFB, just like a ping, when Google or someone visits your site the browser sends a few packets and waits for a response from the server, it is this what is considered TTFB, everything thereafter unless from an external resources for the first time such as a sub domain or CDN is not considered anything to do with the TTFB.
    – Simon Hayter
    Mar 10, 2016 at 17:44
  • If you do want to cater for the few (low resolution) then you can use interchangable content i.e something like this: foundation.zurb.com/sites/docs/interchange.html that way you can supply multiple resolutions and serve the most ideal resolution fit for that device, that way everyone gets a better experience.
    – Simon Hayter
    Mar 10, 2016 at 17:58
  • Tim, I like your idea, but that involves using an additional 30%ish of disk space from a generation of another 600k files. I'm not sure the co-server-admin is ready to order additional disk space (yet).
    – Mike -- No longer here
    Mar 11, 2016 at 3:10

1 Answer 1

Reset to default
1

The article is misleading because it suggests that the server must compress content on the fly for every client and it must compress it each time. That is a waste of cycles.

Use the best of both worlds:

You compress your images one time as good as possible (pngout, zopflipng, irfanview webjpg plugin) and then you switch off server-side compression for images and serve those precompressed images. If you generate images so you cannot precompress them, stop that.

Step 1: Compress your images as good as possible. Quench down the last byte even if it lasts several minutes for one image.

Step 2: Tell your server with .htaccess that you do not need server compression for images

RewriteRule "\.jpg$" "-" [T=image/jpeg,E=no-gzip:1]
RewriteRule "\.gif$" "-" [T=image/gif,E=no-gzip:1]
RewriteRule "\.png$" "-" [T=image/png,E=no-gzip:1]

or globally (then you need to precompress everything)

SetEnv no-gzip 1

(If you have other endings like jpeg instead of jpg, add that, too).

The decompression time on the client side is neglible, in fact the better the compression, the faster the decompression.

Improve this answer
2
  • Step 2 really shouldn't be necessary. You shouldn't ever be compressing images server-side, as they are already compressed.
    – Tim Fountain
    Mar 11, 2016 at 12:19
  • @TimFountain If you get your webserver package, in many cases compression is per default on for all files (May depend on where your country is, how expensive your package is, the experience of the admin and/or how much the admin cares). So it may be necessary need to tell the server to stop that. Also vector-based SVG images are text-files and not compressed (On the other side, they are mostly very small so compression has not much effect).
    – Thorsten S.
    Mar 11, 2016 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.