I thought image files were already in a compressed format and the gains would only be seen for extremely large files (think MB in size.) Is this really needed for mobile first design? Honest question.
There's compressed and there's compressed. Two PNG-8 images may be perceptually identical (or at least close enough that youd need to overlay and switch between them to see the differences) but one has a 16-color palette and occupies less than 1K (and may be neatly tucked into a stylesheet as a data URI, saving a request) while the other is over 20K. Some JPEGs can barely take 4:1 compression, while others can stand 20:1 without artifacting. It depends on the amount of detail and local contrast. (Oh, and killing any extraneous EXIF data can save huge amounts of space without affecting compression.)
Is this really needed for mobile first design? I'd be inclined to say that it's more important for mobile-first since data transfer tends to be slower and more expensive. Remember data caps, whether hard or soft, and overage fees. Every byte you can save is worthwhile to a mobile user. Think of them as the modern equivalent to a dial-up user whose host connection is a long-distance number.
The main thing being discussed on the page is optimisation of compression (http://learn.shayhowe.com/advanced-html-css/performance-orga...). They mention gzip, and yes it's not going to gain you much (and can lose) for small files or particularly gifs (that already use similar compression AFAIR).
Optimised compression is re-compression of the images, e.g. applications like pngcrush or optipng take a brute force approach and try several different compressions of PNG (all lossless) and give you the best one. Same approach can be taken for JPEG, see eg smush.it, re-compressions here as I understand it provide the same final image data and so this approach differs (and is complementary) with using a Save-for-Web tool in your graphics program.
Best thing IMO is to try something like Google's Pagespeed / Yslow / showslow / webpagespeed / gtmetrix / ... and see if it will give a worthwhile gain on paper - then test with some actual web clients.
I'd say mobile-first is going to be more focussed on bytes than those sites targeting primarily desktop users. I've never seen any metrics on rendering speed of different compression regimes though - small files that are doubly compressed seem like they might take longer decompressing than any saving you'd make in downloading.
Is this really needed for mobile first design? I'd be inclined to say that it's more important for mobile-first since data transfer tends to be slower and more expensive. Remember data caps, whether hard or soft, and overage fees. Every byte you can save is worthwhile to a mobile user. Think of them as the modern equivalent to a dial-up user whose host connection is a long-distance number.