Jump to content

Auto Smush


matjazp
 Share

Recommended Posts

2 hours ago, PWaddict said:

Is the bellow error referring to the resmush.it server?

Yes, this is the response from the server.

8 hours ago, Tom. said:

I never knew it didn't do this already?! I haven't been optimising me images when I thought they were optimised haha! I noticed the module had been updated today, however it doesn't seem to be this version. I'm happy to help test it.

Yeah... It never crossed my mind that I should mention this somewhere, sorry. I don't like to update on github when I'm not sure it works and this change was just a quick fix...

9 hours ago, adrian said:

One other thought - I am not sure I actually want it to optimize on "add" via the API - that suggests to me that  it would optimize the uploaded image which I don't want. I only want resized / cropped images optimized. I think there should be an option to prevent optimizing on API add if desired.

Make sense. Give me some time to think about possible solutions. Probably the best option would be separate list of options for admin (backend?), what we have now, and for API (frontened?). 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Hi matjazp!

You and tpr created a really great modul, I have installed 10+ sites, now, and Page Speed loves, too. ?

But. Now, one of hosting provider, I use, sent me an email (Linux based):

 

Quote

 

Scanning /home/abcd:

'/home/abcd/public_html/site/modules/.AutoSmush/windows_binaries/svgo.exe' # ClamAV detected virus = [Win.Malware.Jaik-6917323-0] (md5sum:da85160658dca08df050f2075ae54f29)

I have deleted the binaries, aren't need for Linux, so, it's only an information for you..

Regards,
Tamas

  • Like 1
Link to comment
Share on other sites

@tthom_pw thanks for the report, I'm aware of this. The problem is that there is no svgo binary for windows. So I had to take svgop library, but there are problems too: it's 35 MB binary that takes different parameters. I had to convert/pack svgop to svgo using a batch file and the result is a UPX binary that is always treated as suspicious by antivirus software. I'll most likely remove support for svg on windows in the next release.

Link to comment
Share on other sites

1 hour ago, matjazp said:

UPX binary that is always treated as suspicious by antivirus software

This is not always true, my portable launcher called yaP is not treated as suspicious when upxed, otherwise it is. Interestingly about 5 yrs ago the case was the opposite, I skipped upxing the main binary because virustotal reported several threats. So... you just never know ?

Link to comment
Share on other sites

  • 1 month later...
  • 3 weeks later...

Hey there! I've been using this module on several sites and it's great! I did notice, however, that it didn't seem to compress as much as the comparable plugin for WordPress. After doing some digging, I realized it's because it's set to retain exif data. For small images, this can increase size considerably, up to double (what would normally compress down to 40KB might be ~80KB with exif maintained).

In my site installations, I'm just manually changing line 48 in AutoSmush.module from 

const WEBSERVICE = 'http://api.resmush.it/ws.php?exif=true&img=';

to

const WEBSERVICE = 'http://api.resmush.it/ws.php?img=';

Would it be possible to add this as an option in the plugin?

  • Like 2
Link to comment
Share on other sites

I usually decide if I want to keep exif or not when the image is prepared for upload. But I see your point. It's possible to add an option, but I'm quite busy these days and then I'm off to a vacation... I'm not sure if this module has a potential now that we have webp?

Link to comment
Share on other sites

9 hours ago, matjazp said:

I usually decide if I want to keep exif or not when the image is prepared for upload. But I see your point. It's possible to add an option, but I'm quite busy these days and then I'm off to a vacation... I'm not sure if this module has a potential now that we have webp?

Definitely not a big deal - I can just hold onto my slightly modified version of the module, especially if you're not planning to make any updates anytime soon (no need to maintain updatability).

Link to comment
Share on other sites

  • 7 months later...

@matjazp - I think this is a relatively new thing - I have noticed that the autosmush.txt file is getting a LOT of "Unsupported extension svg" entries. I have an SVG logo in the header of the site, so every page load is triggering this. Just wondering if there could be an easy way to prevent these from being logged? Thanks.

Link to comment
Share on other sites

Can't look at the source right now, but I don't think there is any customizable way of suppressing other then commenting the line that produces it. I haven't been working on this module lately but are you using experimental feature? I don't think this is the way to go now that we have webp support? 

Link to comment
Share on other sites

1 minute ago, matjazp said:

Can't look at the source right now, but I don't think there is any customizable way of suppressing other then commenting the line that produces it. I haven't been working on this module lately but are you using experimental feature? I don't think this is the way to go now that we have webp support? 

Yes, I am using the "Optimize on Pageimage->url() [EXPERIMENTAL]" option - it's the only way that makes sense to me to actually use this module because I don't want to resize the original and I don't always do a size() or crop() call on images.

I've commented that log line for now, but I am curious about your thoughts with webp - are you suggesting that if webp is implemented, then there is really no point using this module at all, or just don't use the experimental feature? 

Link to comment
Share on other sites

1 hour ago, adrian said:

are you suggesting that if webp is implemented, then there is really no point using this module at all

Yes. I think you should go with webp using strategy 3 (using <picture>). Be aware that, based on my testing, webp image is not always smaller so I had to set quality to 80. 

On my sites, I don't use Autosmush because my editors prepare/optimize images before uploading them to PW and I serve them as original, I don't resize/optimize them. I consider myself very lucky in that regard as I know it can't be that easy with other clients.

My opinion on optimizing assets (js/css/images/html) has changed lately. I used to be very pedantic on every byte I could shave off. But now? Do I care much if my css is 30% larger/smaller (in term of download speed)? Not really. Do I care if my image is 500k or 300k? No. We are in 2020. Free WiFi everywhere (at least here in Slovenia) and fast enough. WiFi 6 on the way. LTE/4G everywhere and fast enough (and practically free). 5G on the go. Web servers gzip content. Browsers use cache. What I do hate is javascript slowing down my web browsing experience, making the content reflow, serving me ads. So I browse with no js most of the time. I went off topic, sorry... 

  • Like 2
Link to comment
Share on other sites

Thanks for your thoughts - I must admit I am a little behind in adopting webp, but it's time to get up to speed for sure. I would love to say that I could get clients to optimize before uploading, but it's just not going to happen for all of them and unfortunately they often upload images in the MBs in size, not KBs, so I definitely need to do compression of some sort. I see some sites where they are displaying thumbnails of images which are well over 1MB and even on my 150 Mbps connection, they still visibly load quite slowly so I think it's still important to consider this. Please also consider that in some countries (especially here in Canada), mobile data is stupidly expensive, so even if it's fast enough, it's eating into valuable monthly bandwidth if you're not on WiFi.

Thanks for the suggestion of going with Strategy 3 for WebP - I am curious about images inserted into an RTE - do you use DOMDocument (or preg_replace) to scan for <img> tags and automatically wrap them in <picture> tags and add the <source srcset> tag or do you have another strategy for this?

Thanks again!

 

 

  • Like 1
Link to comment
Share on other sites

3 minutes ago, adrian said:

I would love to say that I could get clients to optimize before uploading, but it's just not going to happen for all of them and unfortunately they often upload images in the MBs in size, not KBs, so I definitely need to do compression of some sort.

That's why I said I'm lucky. All my PW sites are "in the house" and my "clients" are my colleagues at work and they do what I say :-)

5 minutes ago, adrian said:

Please also consider that in some countries (especially here in Canada), mobile data is stupidly expensive, so even if it's fast enough, it's eating into valuable monthly bandwidth if you're not on WiFi.

I see. My "customers" are 95% from Slovenia so I don't have to worry about that, luckily.

6 minutes ago, adrian said:

Thanks for the suggestion of going with Strategy 3 for WebP - I am curious about images inserted into an RTE - do you use DOMDocument (or preg_replace) to scan for <img> tags and automatically wrap them in <picture> tags and add the <source srcset> tag or do you have another strategy for this?

I haven't implemented webp on my sites so I didn't think about that because I just recently upgraded to PW that has webp support. On my sites images are rarely inserted into RTE. If this is the case then you may be better of using .htaccess strategy.

  • Like 1
Link to comment
Share on other sites

Ok, so I decided to play around with writing a DOMDocument based approach which hooks into Page::render and replaces all:

 <img src="/site/assets/files/1234/image.png" alt="my image" class="my_image_classes">

 with:

<picture class="my_image_classes">
  <source srcset="/site/assets/files/1234/image.png.webp" type="image/webp">
  <img src="/site/assets/files/1234/image.png" alt="my image" class="my_image_classes">
</picture>

Because it happens on page render, this approach works with images embedded into RTE fields, as well as those added via regular <img> tags in template files. It automatically copies classes from the original <img> tag to the picture tag.

I still don't know whether this is the best approach or not, but so far so good ?

  • Like 2
Link to comment
Share on other sites

Would you mind sharing your code? I'm thinking that maybe a textformatter on RTE field would be better fit in some cases as generally images in header/footer are most likely already optimized? I would also be interested in how it goes in long term, what are the savings with webp comparing to optimized images.

I wasn't testing with <picture> but I used this approach:

$config->hasWebpSupport = (strpos($_SERVER['HTTP_ACCEPT'], 'image/webp') !== false); //this is in /site/config.php

$url = $config->hasWebpSupport ? "webpUrl" : "url";
foreach($page->images as $img) {
    echo "<img src='{$img->$url}'> ";
}

But I think Horst commented that this would kill caching (don't remember exactly...). Also, some browsers don't support webp, but I wouldn't bother too much.

Link to comment
Share on other sites

  • 8 months later...

Hi! 

So..

If I follow this https://processwire.com/blog/posts/webp-images-and-more/  Strategy 2:

Spoiler

 

Delivering WEBP and automatically falling back to JPG/PNG


# Output WEBP image URLs from ProcessWire, but redirect them to the
# JPEG or PNG when the browser does not support WEBP.

RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.jpg -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.jpg [R=307,L]

RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.png -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.png [R=307,L]

site/ready.php:


if($page->template != 'admin') {
  $wire->addHookAfter('Pageimage::url', function($event) {
    static $n = 0;
    if(++$n === 1) $event->return = $event->object->webp()->url();
    $n--;
  });
}

Then all images where I call them using:

img->width(x)->url

I get a fine working .webp version.

But on all images that I call using

img->url

It doesn't work. I get a 404 saying: https://mydomain.com/site/assets/files/xxxx/image-file-name.-autosmush.webp doesn't exist. And that's true. The automatic webp generation seems to generate a .webp verison for every size version of the image, except the one called image-file-name.-autosmush.png, meaning it looks like this in my versions overview of an image file:

Spoiler

image-file-name.png                              Original 
image-file-name.webp                           WEBP of above (67%)

image-file-name.260x0.png                  API-generated variation    
image-file-name.260x0.webp               WEBP of above (56%)
 
image-file-name.300x0.png                  API-generated variation   
image-file-name.300x0.webp               WEBP of above (63%)

image-file-name.-autosmush.png        API-generated variation
(no webp version of this!)

I guess it's supposed to still work even though I'm not calling a specific size trough the API? right?

I tried this:

Spoiler

RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.-autosmush.png -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.-autosmush.png [R=307,L]

– But that doesn't seem to do anything...

 

Best,
Jonatan.

Link to comment
Share on other sites

Update in regards to webp if anyone should be interested: 

If you're using Cloudflare free plan, it doesn't matter anyway. Cloudflare free plan doesn't support HTTP vary header so this :

 

Spoiler

 


RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.jpg -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.jpg [R=307,L]

RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.png -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.png [R=307,L]

RewriteCond %{HTTP_ACCEPT} !image/webp [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.-autosmush.png -f
RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.-autosmush.png [R=307,L]

and 

 


if($page->template != 'admin') {
  $wire->addHookAfter('Pageimage::url', function($event) {
    static $n = 0;
    if(++$n === 1) $event->return = $event->object->webp()->url();
    $n--;
  });
}

 

– Will NOT do anything useful. Because Cloudflare will serve your webp version NO MATTER WHAT. Which means that Safari on Mac and all iOS devices will not show any pictures... ? 

Source: https://community.cloudflare.com/t/cloudflare-cdn-cache-to-support-http-vary-header/160802 , https://community.cloudflare.com/t/cloudflare-displays-broken-images-on-my-website/183212/13

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
  • 2 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...