ProcessImageMinimize - Image compression service (commercial)

[Philipp]

Update 09.05.2014: new version of minimize.pw released. I've updated this post and you can read more here.

ProcessImageMinimize
A service and module to make images lightweight: minimize.pw 
Our new commercial service for ProcessWire: minimize.pw  With minimize.pw, you can shrink your images (JPG and PNG) without noticeable visible differences up to 80%. This makes pages load faster and helps you to work with people not familiar with command line image compression. You can try it for free.

Learn more
Download the module
Github Page

Module features

• Hooks into any Pageimage with ->minimize() (short ->mz() )
• Automatic compression with a 1-click-setup (new)
• Overwrites original files or keeps both versions (new)
• Image compression with minimize.pw
• Fail-safe mode so that your visitors won't notice any problems if we're offline or you have no volume left.

Usage with templates
First, download and install the module. You have to enter a license key.

• Get a free license key here

To embed a minimized image into your web page, simply call the method mz() or minimize() on your Pageimage-object. Please note, that is has to be a single Pageimage. We also support apeisa Thumbnails module.
 

$img = $page->image;
$img->minimize();

 Or put in context

$img = $page->image;
echo "<img alt='A minimized image' src='{$img->minimize()->url}'>";

 You can also use it combined with other Pageimage methods:

$image->size(300,400)->mz()->url;

 
Read more at Github

 
Pricing
While the module is free, our service is fee-based. We have to pay for servers and traffic  With this version we've dropped our year-based pricing structure and introduce a new volume-based pricing. Everyone gets 2000 images for free and you can buy additional volume anytime.

• Free: 1000 images once 
• 5000 images / 19€
• 15000 images / 39€
• 50000 images / 89€

Buying more volume will also drop the site limit of three.

 
Questions
Feel free to ask any question you might have. 

Edited May 9, 2014 by Philipp

[ryan]

Tested out here and works very well, good results, and was easy to implement. Nice work Philipp! 

[apeisa]

This is cool idea and hopefully it will be successful!

Does it minimize images right after uploading or when first viewed? If the latter, does it do it on background and serve original image for first viewer - or does it make roundtrip to minimize.pw servers first?

[Philipp]

It minimizes the images the same way thumbnails (e.g. ->size(120,60)) are generated. The image takes the trip to minimize.pw and returns. So the first time, your page loads you will notice the longer page loading speeds. After that, the minimized image is served from your disc. It takes around 15seconds to compress 5MB PNGs to 1.3MB PNG or to compress two 6MB JPGs to 3MB JPGs.

The next milestone for the module is a feature where it will replace the image directly after upload - so the minimized version will be the only version on your disc and the performance should be better. Another plan includes an async method to send the images back "behind" the scenes - but only if there is a need for such a function.

[Nico Knoll]

Really, really lovely website!! https://minimize.pw/

[Philipp]

Thanks Nico.
 
After three weeks, we want to share our experience and some informations about the module and service. We think that an open and honest approach on this topic might help others to develop great commercial (and free) modules. 
 
minimize.pw started as an internal solution for a problem. Working with an agency with large PNGs, we searched for a way to compress them with PNGQuant. We thought that other developers would be interested in this kind of a service and that lead us to the decision to make it a commercial service. We have to pay for the servers and maintenance.
 
The whole developement took around 3 days with some additional hours in writing backend jobs like backups and payment management. 
 
As today, 21 days after launch, we've only got a single "Free" signup and zero licences sold. We got some E-mails and questions but nothing more. Beside our internal usage on three client sites not much happened. We didn't expect much, but we thought there would at least be more free signups.
 
So what went wrong? Well, we made some assumptions:

• There is no interest in this kind of service. 
• The pricing is to high and the free plan isn't worth a look.
• Our website could't convince visitors to use the service
• To many open questions because there isn't a FAQ or something similar
• We just have to wait longer
• The module missed some important features

We hope that the first point isn't true. With some feedback from twitter, we think that there is a market for some developers to use this service. The same applies to the last point - at least we should have some more signups. So we might have to improve the remaining 4 assumptions.
 
In the next week, we will update our service/site:

• An improved and better free plan: You will get 1000 images per year and you don't have to renew after a month.
• More images on new paid plans (replacing the old monthly model):
  • Standard with 30 000 images / year and up to three sites for 39€
  • Large with 100 000 images / year and ten sites, 99€
• A new webpage with better examples and a FAQ. We will later add a case study with a larger site.
• Planned features for the module itself:
  • Compression while uploading images
  • Replace images instead of making variants (as an option)
  • Usage with the Thumbnails module (CropImage)
  • (An Async performance modus)

But before doing this, we would be glad to hear what the community thinks about this. We would appreciate some feedback and/or your thoughts on the service and the module.

P.S. Here is a special key with unlimited images and sites, valid for the next four weeks: zE1DptpPYN

[apeisa]

thanks for the honest post. Your service definitely got me interested right from beginning. I think main reason for only one free account - there is not much to test. Your service is super helpful, but I have no rush to test it before I have need for it. I already know how it works and what it does.

Also - pw community is pretty small compared to many others. I think you should offer rest api and plugins for other platforms too, if you really want to focus on your service.

About your site - it definitely promotes the service well... but maybe you should focus on why page speed matters and how much images affect on that?

Finally - I think service that does it on runtime (when uploaded) would be preferable, since no need for any custom template code then.

[adrian]

Phillip - thanks for a great writeup of your experience.

To be honest, I am starting the get the feeling that too many clients/developers don't know/care about image file sizes. It amazes me the number of sites that I visit these days that have images of 500Kb to 1MB, sometimes bigger. I think some have gotten caught up in fabulous full page images, but don't realize that they can be made smaller and still look good.

Also, I have to say that I think I would have a hard time getting clients to fork out an annual subscription for an image compression service when with a little care they can make sure the images are properly compressed before uploading. Of course this will depend greatly on the client - I am sure some will love the ability to not have to worry about anything when uploading images and would be happy to pay for your service. 

I hope your new pricing model works out for you - best of luck!

[teppo]

I'll have to agree with Adrian: many clients won't see the benefit and many ProcessWire developers aren't hosting client sites themselves so that they could really benefit from this themselves.

Problem with large images doesn't seem huge when you're visiting a site often enough for cache to kick in (which is true for many clients, I'm afraid). Unless you use analytics to see how the site is doing for wider audience you might not even notice that anything is wrong. Most of the sites we build also have couple of API calls to images tops and a ton of images included within page content (Tiny / CK fields). Benefits of minimize.pw for sites like that would be less dramatic.

Then there are people like me. I've been minimising static images with tools like OptiPNG and also had plans to develop something similar to this module for local use. Your prices aren't high, but if I can do same thing locally without any costs (other than the work required) and without any image limits and so on.. well, it does sound tempting. (People like me are probably not your target audience.)

Long post in a nutshell:

I'd try to make the benefit of this service as clear as possible and consider what @apeisa said about minimising images during upload. Latter is what I see as the biggest flaw in your current product, actually: if the service would automagically start working after one-click install I believe it would be a lot more beneficial than current solution.

Ease of use combined with very clear explanation about what happens when your free quota is gone (does the service still work, does it prevent using the site normally etc.) and easy way to upgrade your plan and you've got a winner.. probably

.. and, of course, if you want to make big bucks with this, add native support for more platforms.

[apeisa]

if we have 5000 active developers/agencies working with pw and 10% are interested in image sizes, then your current audience is 500 people. No clue about usual conversion rates, but to really make money you do need superb product and marketing. And most importantly: time.

Disclaimer: I don't have any clue about how many devs actually use pw or how big percentage really cares about image optimization.

[Martijn Geerts]

You share with us your experience with this service I really appreciate this, next it shows us your and your companies straightness.

Great comments here are given. And I do think your service is wonderful. Teppo pointed out that this service could work if it is a one click, put it on/off service.

One given thing is that we rely on services to build our websites. We rely on jQuery, we rely on the plug-ins we rely on ProcessWire on the Modules and on YouTube. We all have experience with failing services. I remember a using jQuery: //ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js which gave me problems because Google served me an updated jQuery (I asked for), but the new update was not compatible with some parts of the site.

Without services we could not compete with all other web building companies, but depending on a service is tricky. I think we're all getting "smarter" & don't want to rely on some services what potentially can give problems or disappear. It's never fun to fix an old website because some of the services fails.

[Joss]

apeisa is right - to have a chance of an audience you need to expand the service to other platforms using plugins.

That opens two markets really - professional developers and designers and the non professional market; Wordpress users particularly.

Now, obviously there are competitive services out there that are offering both lossy (TinyPNG) and Lossless. But I suspect this is a growing market, particularly on the lossless side as people want to make their offering more and more media rich, need to keep speed up but don't want to lose visual quality.

It is a numbers game though. It will always be a small percentage of users that would even think of using such a service, and it is always a small percentage of those that are interested that will actually sign up.

It may be that once the service is a bit more developed and broader based, you need to sell it directly into some companies (especially agencies) so you can boast a few names on your website. Once you are in that position, then you will probably need to advertise.

When it comes to the two market areas, they will need to be treated very differently with different package offerings (the pro side needing more flexibility) and different looks. At the moment, the market does seem very complicated, from command line options and download systems like FileOptimize using a lot of open source plugins, to more domestically orientated system like TinyPNG and others like Riot and the developer orientated Kraken.

What you will need to do is decide where the line is between the two markets and then develop the two offerings to meet those markets, making sure one feeds into the other, of course.

[Philipp]

Thanks for the feedback. Great thoughts.

And I do think your service is wonderful. Teppo pointed out that this service could work if it is a one click, put it on/off service.

I think this should be our priority No. 1 for the next module update. Select the image-fields you want to minimize and done. We just have to decide what happens to image variants and how we can "catch" them.
 
 

I'd try to make the benefit of this service as clear as possible and consider what @apeisa said about minimising images during upload. Latter is what I see as the biggest flaw in your current product, actually: if the service would automagically start working after one-click install I believe it would be a lot more beneficial than current solution.
 
Ease of use combined with very clear explanation about what happens when your free quota is gone (does the service still work, does it prevent using the site normally etc.) and easy way to upgrade your plan and you've got a winner.. probably

That was on my mind when writing the assumptions above. We couldn't clearly communicate the benefits of the module/service. That you will get faster page speeds because a webpage nowadays contains mostly (large)images. Question: Target more the developers or our "customers" (clients).

As of today, the module will still work if our servers go down or your licence key expire. You just won't get minimized images because the module hands through the original PageImage. If you want to update your plan, buy another licence key... ?

And again, the 1-click-solution as mentioned before. Got this one

if we have 5000 active developers/agencies working with pw and 10% are interested in image sizes, then your current audience is 500 people. No clue about usual conversion rates, but to really make money you do need superb product and marketing. And most importantly: time.

Our intention was never about "big money". The dev community here is small (compared to other plattforms) and we knew this. We could reach out to other CMS like Typo3 or Wordpress but thats not the plan and there are already other solutions out there.  We just thought, that we would have more than a single "Free signup" after three weeks and maybe even a sale(!). 

We made the service commercial, to cover our server costs (currently a single instance for 20$/m) and maybe to get a little bit more to cover the costs for e.g. Ryans ProCache and FormBuilder for our own use. It's not for everyone to setup the scripts and a server to compress images. It should be as easy as possible and you should just have to focus on using the service rather than running it. 

It's hard to find prices and the right way to market your product. I think we still have to figure this out and see, where we will go. We will invest some more time but this might result in a better outcome for everyone (even other developers who might try to make a commercial service/module for ProcessWire).

[horst]

... We got some E-mails and questions but nothing more. Beside our internal usage on three client sites not much happened. We didn't expect much, but we thought there would at least be more free signups.

Hi Philipp,

I was interested in the service since the first day, and I'm interested in the service today. - But there were some concerns I have asked for via email:

• does the service keep IPTC? This one is mandatory for my colleagues photo-archive with 35.000+ images.
• You advice to use a default quality setting of 100% with PW in the config.php for all images. That makes sense, but if the service is down for any reason, including expired licence key, you pass through uncompressed images (100% quality == 0% compression). You have no fallback in the service / system. (And if you add a fallback, please don't try to guess which quality-setting they may like for their images, ask them. - Means: make it configurable!)
• I don't want only one potential client who visits the site have to wait. Not only one. Instead of sending images to the service and back and let the visitor wait until all is finished, you better pass through the local fallback and trigger the service in the background. This is much faster at first request and equal at second request. But much better is to create the images when uploading new images to the site. This way only the owner and or coworkers have to wait, but no vistitors / potential clients.
• To find potential clients you need some reputation: which sites already use the service?
• What's about the feedback of some satisfied customers?

I really would use your service together with that colleagues site, but actually the service is in an early beta state. There is need for optimizations.

PS: I'm still waiting for emails about progress. Got only one directly after mine, (IPTC = ok maybe we can do; fallback = oh, we haven't thought of that) but nothing more then.

[Philipp]

Thanks Horst for the honest feedback. You're right, I didn't handle this situation and our conversation the right way.

• does the service keep IPTC? This one is mandatory for my colleagues photo-archive with 35.000+ images.
• You advice to use a default quality setting of 100% with PW in the config.php for all images. That makes sense, but if the service is down for any reason, including expired licence key, you pass through uncompressed images (100% quality == 0% compression). You have no fallback in the service / system. (And if you add a fallback, please don't try to guess which quality-setting they may like for their images, ask them. - Means: make it configurable!)
• I don't want only one potential client who visits the site have to wait. Not only one. Instead of sending images to the service and back and let the visitor wait until all is finished, you better pass through the local fallback and trigger the service in the background. This is much faster at first request and equal at second request. But much better is to create the images when uploading new images to the site. This way only the owner and or coworkers have to wait, but no vistitors / potential clients.
• To find potential clients you need some reputation: which sites already use the service?
• What's about the feedback of some satisfied customers?

1. Yes, we keep the IPTC information. But please keep in mind, that we do some sort of compression that's not completely lossless. 
2. That's right and its already on the list for the next update.
3. Like normal image variations in ProcessWire, the first time you load the page takes longer. The person uploading the images needs to open the page once. That's not perfect but was the fastest working method. See below.
4. We only have one live site and some sites in developement. That's a problem, I know.
5. Same thing as 4. Or should I be quoting myself?

_

We sat down today and based on your feedback wrote down some features for the next module version. They should increase performance, make it more configurable and the integration will be easier. We also thought about developers like Horst that have thousands of images.

• Alternative hook after the image upload (based on selected fields). No need to call the mz() method or changing templates.
• Option to overwrite original files or to keep a variation.
• A pseudo "async" upload method. Images will be sent to our servers and then the site will render without the minimized images. If you open the site again, your PW will check if the minimized images are ready for download and replace/create the minimized files. No need to wait for our servers but results may take another page load before they appear. We don't want to open a "pipe" (e.g POST /receiveimages/) to write them back to the file system once compressed. 
• Fallback to PW compressed images.

On the server side we will then build a complete queue system for better scaling across multplie server instances. It also allows use to use the slower but better options of PNGQuant or JPEGOptim. 

The goal is to release this in the last february/first march week.

[muzzer]

Hey Philipp

Tested this just now and the results are good, eg 150k files down to 110k etc with almost no effort on my part, other than adding ->mz() to the image resize code - easy to setup and use. Beautiful.

Big issue was page speed - which is ironic as speeding this pageload is the purpose of the module. A small image gallery page took 27 seconds to load the first time - I know, this is an extreme case, minimizing all the images on the page at once - so time-lag this is to be expected,  but it does reinforce the need for the minimizing to be performed on upload (or perhaps asyc), not on pageload.

I can see the use for this module - I would use it on more image-heavy sites, especially image galleries, but the minimizing on pageload is a major gotcha for me.

Cheers

[Philipp]

Thanks for the feedback muzzer. Good timing!

As some people already noticed on twitter some hours ago, we're working on the next version of minimize.pw. 

https://twitter.com/minimizepw/status/462298387878907906

We've listen to all your feedback and have rewritten the whole service. It now features an async way of minimizing images that takes some more time(a minute) until changes are visible but it works much smoother without any noticable increase in loading times. We just did a live test on a site with 2000 images and around 800 visitors/day and we couldn't measure any drawbacks.

Beside, the basic new features of the module will be an option to override original files and a one-click solution where we minimize every uploaded image.

I've invited some people to test this and I hope we can go public around next week. We will also inform all existing customers and transfer the accounts to the new system. If you can't wait and want to beta-test, write me a message

[muzzer]

Hey Phillip,

Now that's starting to sounds like a seriously useful module.

Yes, I'm happy to help beta-test if you need more testers, otherwise I'm in no rush and will wait for the release, I've got other jobs on for the next few weeks so no biggie.

One click solution sounds sweet, will there be options to turn this on/off per image field?

[Philipp]

There is no option to use minimize.pw on a configured field-based selection. In this case, you can use the API method to select the fields you want via template code. We've added this to the list of features implemented later.

Currently we're working on the new website and nicer dashboard with more statistics. We also found a way to optimize JPGs more, but we will use this gain in file size to compensate for a higher JPG quality level.(85 instead of 80). On a side note, PNGs are even smaller and we will implement an option for (animated) gif files. 

[Philipp]

We're proud to release our next and new version of ProcessImageMinimize (1.0) and the minimize.pw service. As mentioned here and on Twitter we've worked hard the last two weeks. The whole service has been rebuilt from the ground to support all the wanted features of the community. It's faster and more reliable, it works out-of-the box and has a new pricing structure.

• Images are processed async. behind the scenes
• The service works on a queue now.
• The service has new compressions scripts with higher quality output, especially for jpg files
• Build to scale: We can scale the servers in under a minute and handle thousands of images without any problems
• The module uploads the image and waits until the image is minimized. 
• If activated, the module is now able to replace the original image file instead of creating a .mz variation
• If activated, the module automatically sends every new image to the service
• The module also works with apeisa Thumbnails module (CropImage), adding an getMzThumb($name) method
• While the image is beeing minimized, the module creates a temporary image. You can now set a quality of 100 on your image config without problems
• Direct link to the new dashboard at the module settings page
• The module now tells you if you have no volume left.
• The module also features the "classic" way of using the minimize()/mz() API method on PageImages.
• A new dashboard for customers features statistics and a quick overview
• You can see traffic, compression rates, saved bandwidth and more for each website using your license key.
• You can browse old invoices.
• New pricing structure
• The pricing is now based on a volume-based point system. Buy more volume(=images) for your license if you need them.
• No yearly price, no auto-renewal. And  1000 2000 images for free.
• A new website with an overhauled design and more feature information
• A new little minigame to compare minimized JPGs.
• All the old features like secured https connections, the fail-safe module and our image size reductions.
• The few existing customers are migrated with some extra volume

You can read about the features at our new website.

Ready to start?

Download the module and read the documentation at Github

For the first week, we will give all new users 2000 instead of 1000 images for free. So signup and try the service. This should be enough for alle small- to mid sized projects.

If you need more than those two thousand images, you can buy another 5000 for around 19€ or 15000 for 39€. You don't have to update your license key on your module configuration after buying more volume. Paying for the service also removes the three site limit.

Attached is a screenshot of our development dashboard and the new homepage.

Please note, that we currently don't support a full ProCache installation. At least one PHP call on any site has to be made in order to activate the module. We have a plan to solve this problem but it's not implemented in this release. Also the stats don't display the correct amount of images sent for old customers, because we haven't tracked them before.

Thanks for your previous feedback. Thanks to all the developers using our beta. You really helped us. We hope that we can provide a valuable service to the (growing) ProcessWire community.

Feel free to ask any questions. Submit your first impressions of the service, the website or any other aspect. As mentioned before, we want to be open and honest.

[Marvin Scharle]

Important note: Please remove the older version of the ProcessImageMinimize module before installing the new version.

If you experience database problems after updating the older version, please run the following SQL query on your database:

CREATE TABLE process_image_minimize (image_id VARCHAR(255) NOT NULL PRIMARY KEY, reference VARCHAR(24), state INT(2) NOT NULL, processed VARCHAR(255), force_replace INT(1), created_at INT(11) UNSIGNED NOT NULL, updated_at INT(11) UNSIGNED NOT NULL);
CREATE UNIQUE INDEX minimize_api_reference ON process_image_minimize (reference) USING BTREE; 
CREATE INDEX minimize_api_state ON process_image_minimize (state) USING BTREE;

This will manually create the necessary database table. 

[Ralf]

Thumbs up - that works 

Thank you Marvin

[horst]

We're proud to release our next and new version of ProcessImageMinimize (1.0) and the minimize.pw service. As mentioned here and on Twitter we've worked hard the last two weeks. The whole service has been rebuilt from the ground to support all the wanted features of the community. It's faster and more reliable, it works out-of-the box and has a new pricing structure.

...

Philipp this is great news.

The service really has expanded. Many improvements are in.

[Marvin Scharle]

We have updated ProcessImageMinimize to version 1.0.1

The update includes a fix for a bug which prevented uploading non-image files in some configuration scenarios. Please install this patch on your site if you have similar issues.

Additionally, if you have found any bug, please open a ticket. 

Thank you in advance for your help!

[bytesource]

Hi Phillip, 

I have a question regarding the support of the ProCache module. 

You wrote:

Please note, that we currently don't support a full ProCache installation.

At least one PHP call on any site has to be made in order to activate the module. 

I have to admit I don't quite understand the limitation of this one PHP call you mention. Does it in any way affect the performance or effectiveness of either of the two modules? 

 

Cheers, 

 

Stefan