If you launch Archive Utility directly from /System/Library/CoreServices/, you can create gzip-compressed .cpgz archives, which can have a higher compression rate than zip compression. However if you're compressing already compressed files (like most music and video files), you likely won't get much space savings, if any.
If you want to try however, open up Archive Utility, open the preferences, then change the Use archive format: setting to compressed archive, and create a new archive from the file menu (⌘K). This setting only affects archives created when you open the Archive Utility app. Ones created with the Compress option in the Finder's context menu will still be zip archives.
A full-on image compression explanation is probably better suited for StackOverflow, but since you related it to Apple, I'll give an overview here.
The image itself actually determines the size of its file to an extent. With that, one can compress some images more than others without losing much apparent quality. For example, the JPEG image compression algorithm handles reds poorly. Consequently, if you have a photo with more red, you will likely need to keep the JPEG quality higher in order to not notice a difference. There are other quirks with different image compression formats that can impact the size of the file as well.
Second is how you save the file. Photoshop has a Save for Web feature that allows you to have more granular control over the save quality of the image. You can adjust the quality percentage (of original) and immediately see the affects on the photograph. A commenter noticed that it was 58% image quality. That doesn't mean it's 58% of the original file size, but is the number associated with the algorithm. It is likely that just that is less than 58% of the original size of the photo. You can easily see what they described by saving a photo in Photoshop using Save for Web and then setting it to the JPEG format and setting the quality to 58%.
After the photo has been saved, there is still another level of compression that can be done - in fact, there is more than one. The simplest, perhaps, is to run it through an image compressor. There are many out there and the one stand-alone app that comes to mind is JPEG-Mini. These can reduce file size significantly in some cases (though not all). You can also configure the server to provide a gzipped version of the image which further reduces the size. (You can determine if that photo was gzipped by looking at the headers for that image request/response.)
Image compression is extremely important, but is unfortunately overlooked all too often. I appreciate sites that show that their developers have done what they could to reduce image size so that all of their users can enjoy a faster load time. On that topic, responsive images are rapidly becoming supported and are sure to bring an even better UX as we serve browsers more specific content.
Best Answer
The standard Mojave setup does have APFS compression implemented, but there's no user visible tools that allows you yourself to select files/folders for compression.
It seems that the "ditto" command supplied with macOS is supposed to be able to employ compression on APFS, but it only actually works with HFS+ file systems.
However, even though no user visible tools comes with Mojave - the developer level APIs are actually there. A third party utility exists that uses these APIs to provide a user tool for compressing files/folders:
https://github.com/RJVB/afsctool
You refer to the wikipedia page for your statement that APFS compression is supported. The wikipedia page actually refers to the above mentioned tool for that support.
You can install
afsctoolfrom Homebrew by this command:And you can install
afsctoolfrom MacPorts by this command:You can compress a file or folder like this:
where filename can be the name of a file or a folder.
You can check if a file is compressed, and how much, by this command:
The built-in compression feature of APFS is implemented in the same way as it was on HFS+. That support was introduced with OS X 10.6. Even though it has thus been a part of the macOS system for almost 10 years, it is not really widely used.
In my own experience it just works (HFS+ or APFS - doesn't matter). However, you might run into an edge case where some program reports the file size incorrectly or something like that. I haven't seen any such misbehavior yet. The whole idea with transparent compression is that user programs do not need to know that compression is used at all.