Feature Request: JPEGMini and TinyPNG

Definitely two very impressive services. I’m still brainstorming the possibilities here, but here’s my initial reactions…

The optimized images from both services are intended to be visually identical to the originals (and by all appearances, they do a fantastic job of this). However, the optimizations are not lossless, as the images undergo lossy compression techniques to achieve the savings that are seen. Based on that, I am inclined to deny it for inclusion in the plugin, since our focus is on lossless optimizations, and I tend to steer people towards other plugins that already do lossy image optimization (Imsanity among others).

Additionally, this plugin started with a focus on running optimizations locally, which has a variety of benefits. The cloud service I launched a few months ago was done only to serve those who cannot (or don’t want to) run the optimizers on their own servers for whatever reason.

If there is enough interest, I may approach either company to see if they would be willing to sponsor development of a separate plugin that would integrate with EWWW Image Optimizer.

I’ll stick this topic so that others can add their opinion or vote for this feature request.

+1

Also, what about WebP? Can that too be implemented?

Hey Nos,

Thanks for taking the time to reply. I can appreciate that your goal has been lossless compression and I think it’s a good idea to continue giving people that option. Your principles are sound.

With that said, we’re talking about 60%+ additional file compression with almost undetectable visual changes to the naked eye. When we’re dealing with clients who flock like sheep to DreamHost, BlueHost, and other metered providers – we’re suddenly talking about an enormous difference in page load time.

Perhaps the best solution is a compromise. Might I suggest that you always save original using lossless optimization, but allow the thumbnail images to be processed through more aggressive means? This would allow us to significantly compress the data transmitted on most page loads without sacrificing quality where it is expected.

Your solution is better than any other on the plugin market but, at this point, I’m still downloading the monthly uploads folder for 30+ clients during the first week of each month and compressing every thumbnail manually (originals too in many cases, where quality is less important than efficiency). It’s a back breaking task.

The other thing that I’d love to see supported is an automatic conversion to progressive JPG before processing. It’s like… a 3 line change in the WP core. I haven’t yet explored the best way to enable it with a plugin but if WP first makes all thumbnails progressive, then converts non-animated GIF to PNG, then aggressively compresses the reduced sizes.

Boy, that would be amazing.

Sorry, one last thought before I go back to doing real work ??

“Additionally, this plugin started with a focus on running optimizations locally, which has a variety of benefits. The cloud service I launched a few months ago was done only to serve those who cannot (or don’t want to) run the optimizers on their own servers for whatever reason.”

When you’re on a WiredTree or Liquidweb VPS, it makes sense to do everything you can locally, since you’ve got the resources for it. When you’re freelancing and a client is on a metered host (80% of all cases in my experience) then you get as far as you can from memory & CPU intensive processes. The 15 min throttle is a killer.

@shreejee, WebP has already been discussed, see this thread: https://www.ads-software.com/support/topic/feature-request-graphicsmagick-webp?replies=3

I’ll tackle your last couple posts, because you bring up some interesting possibilities.

Lossy compression does make more sense for thumbs/resizes, since these are probably never expected to be as good as the originals, and most would not care, so long as they were visually identical to what WP generates natively.

Then your next post, I think we are 2/3 of the way there already (correct me if I’m missing something):
1. EWWW IO already attempts progressive and non-progressive optimizations, and chooses the smallest of the two.
2. EWWW IO can already convert GIF to PNG (but you probably already knew that).
3. implementing TinyPNG and JPGMini will effectively enable ‘aggressive compression’, without any noticable loss in quality.

We’ll still need sufficient interest to implement either of these services, since it will take a decent amount of work to make it happen.

Anyone who has made it this far, feel free to add your +1 to this thread.

And regarding your last post: Yes, I’ve definitely seen some who are technically capable of running the optimizers locally, but choose not to. I’ve even had some contact me directly who are in a similar place as you; they have lots of clients on minimal hosting platforms and it doesn’t make sense to run optimizers locally. That’s partially why I didn’t limit the cloud api keys to a single website. You could use a single key on 1000 websites, so long as you don’t exceed your quota, it will keep right on going.

It sounds like we’re in agreement on the best solution. Now it’s up the community to rally behind the concept, or shrug and shuffle along ??

sounds good. the more we can reduce the file size the better the result for the browser and google will be happier. +1

BTW: TinyPNG seem to use the free PNGquant library – they′re listed on PNGquant′s homepage as one of their GUI tools. Not sure if they use it in conjunction with anything else. – https://pngquant.org/

My understanding was that TinyPNG uses some of their own techniques that are proprietary, but they probably use free tools as well. I’ll do some digging on that front and see what I come up with.
There are some excellent resources on the pngquant webpage as well, so Thank You for the tip.

After doing some testing, I suspected the used pngquant in conjunction with something like zopfli compression. I can mostly replicate their results, but I still get some surprising savings on a few images. It’s possible they are just using a lower max value for pngquant, and I’ll toy with that more tomorrow.

I’m so psyched that you are going forward with a lossy compression option on the thumbnails. It’s going to make this far and away the best plugin on the market.

Another quick aside – P3 has a pretty damming view of the plugin:
https://screencast.com/t/plsQkFljeee

We should run though the source and make sure Ewwww is only ever being called conditionally when the media gallery is active. Otherwise, it’s going to be a real CPU hog. Please bear in mind that I haven’t really investigated things yet. If I had, I’d have made a new OP about it.

My concern here is, generally, that once you get a lossy option in for thumbnails the plugin will become very, very, very popular. At that point, we’ll want to make sure it’s as slim as possible – to the point of being invisible unless it’s compressing stuff.

(Yes, that’s Ewwww – I know the two purples are confusing)

Yes, that concern has been raised before, and mostly addressed. The next release moves even more code out of the initial load (not that the code being moved was actually doing anything, but every ms counts), so that will be even better yet. EWWW is pretty heavy on the admin side, but it barely does anything on the front-side unless it is called for.