Some images not served as WebP on nginx

  • Resolved Mr. W

    (@gabriel-winnberg)


    8 years, 4 months ago

    Hello,

    The test image is green with the text WEBP. This is in nginx.cof:

    map $http_accept $webp_ext {
        default "";
        "~*webp" ".webp";
}

    This is in the server block:

    location ~* ^/wp-content/.+\.(png|jpe?g)$ {
        add_header Vary Accept;
        try_files $uri$webp_ext $uri/ =404;
}

    Should it matter if I put ‘jpg’ or ‘jpg|jpeg’ or like above ‘png|jpe?g’?
    In any case, it has to be before this to work:

    location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
        access_log off;
        log_not_found off;
        expires max;
}

    But does that mean that it won’t set ‘expires max’ to jpeg and png at all?

    The problem is that some jpegs are served as text/html and generates 404. What could be the of cause this?

    Cheers,
    Gabriel

    https://www.ads-software.com/plugins/ewww-image-optimizer/

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    That probably means a .webp file does not exist for some of your JPGs. You need to have some logic in there that checks to see if the webp file exists first, since EWWW only keeps a webp file if it saves space. You also need to check that the browser supports webp, and I don’t see that anywhere in your config (I could be missing it though).

    Thread Starter Mr. W

    (@gabriel-winnberg)

    Well I did say that your little test image is green, plus at least one of my jpgs on the front-end are served as WebP.

    How do you mean that .webp files don’t exist for some of my jpgs, do I have to create them? I thought EWWW would do that on the fly or do I have to re-optimize or even force re-optimization?

    And why are they served as mime type text/html? And if it can’t find them then why aren’t they served as jpeg?

    Thread Starter Mr. W

    (@gabriel-winnberg)

    URL:

    https://dev.konsttorget.se/om-oss/test/

    Plugin Author nosilver4u

    (@nosilver4u)

    No, it absolutely does not do that on the fly (it could slow your pages WAY down). They must be generated during optimization. If you already optimized everything without WebP, then yes, you’d need a force re-opt.
    If you are using lossless, no big deal, if you are using lossy, temporarily swap it back to lossless during the forced re-opt.

    Thread Starter Mr. W

    (@gabriel-winnberg)

    Of course, I didn’t think that one through. ?? I just force optimization. Still the same result – test image is green and one front-end jpg is served as webp.

    Are the webp files supposed to show in the optimization output, they do not:

    Optimized 2016/07/nature_4k_wallpaper_high_quality_pictures_206l.jpg
Full size – No savings
nature_4k_wallpaper_high_quality_pictures_206l-150x150.jpg – Reduced by 7.4% (675.0 B) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-300x169.jpg – Reduced by 6.4% (1.2 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-768x432.jpg – Reduced by 5.9% (5.8 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-1024x576.jpg – Reduced by 5.4% (8.8 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-180x180.jpg – Reduced by 6.9% (873.0 B) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-300x300.jpg – Reduced by 6.3% (1.9 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-600x600.jpg – Reduced by 5.6% (5.6 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-100x56.jpg – Reduced by 12.2% (376.0 B) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-862x485.jpg – Reduced by 5.7% (6.9 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-862x482.jpg – Reduced by 5.6% (6.7 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-1200x675.jpg – Reduced by 5.2% (11.4 kB) - Previously Optimized
nature_4k_wallpaper_high_quality_pictures_206l-1200x671.jpg – Reduced by 5.3% (11.4 kB) - Previously Optimized
Elapsed: 15.949 seconds
    Plugin Author nosilver4u

    (@nosilver4u)

    nope, they get ignored in the process that parses the metadata. Best bet is to try manually loading the url with a .webp appended to see if it exists, or browse the folder on your server to see if the file was generated.

    Thread Starter Mr. W

    (@gabriel-winnberg)

    Odd, the full size version is there:

    https://dev.konsttorget.se/wp-content/uploads/2016/07/nature_4k_wallpaper_high_quality_pictures_206l.jpg.webp

    But not some of the others:

    https://dev.konsttorget.se/wp-content/uploads/2016/07/nature_4k_wallpaper_high_quality_pictures_206l-1200×671.jpg.webp

    Plugin Author nosilver4u

    (@nosilver4u)

    Again, it all depends on if the webp file was smaller than the jpg. If not, it deletes the webp. That applies to every individual image file, so resizes may not exist when the full size does, and vice versa.

    Probably even more so that WP dropped the default quality for resizes to 82 (from 90).

    Thread Starter Mr. W

    (@gabriel-winnberg)

    I see, but why doesn’t it serve the jpg instead, any idea why it gets mime type text/html?

    Thread Starter Mr. W

    (@gabriel-winnberg)

    You’re right, only a few images were converted:

    [email protected]
nature_4k_wallpaper_high_quality_pictures_206l-100x56.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-1024x576.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-1200x671@2x.jpg.webp
nature_4k_wallpaper_high_quality_pictures_206l-1200x671.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-1200x675@2x.jpg.webp
nature_4k_wallpaper_high_quality_pictures_206l-1200x675.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-150x150.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-180x180.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-300x169.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-300x300.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-600x600.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-768x432.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-862x482.jpg
[email protected]
nature_4k_wallpaper_high_quality_pictures_206l-862x485.jpg
nature_4k_wallpaper_high_quality_pictures_206l.jpg
nature_4k_wallpaper_high_quality_pictures_206l.jpg.webp
[email protected]
[email protected]
Standardprodukten-100x100.jpg
Standardprodukten-100x100.jpg.webp
[email protected]
[email protected]
Standardprodukten-150x150.jpg
Standardprodukten-150x150.jpg.webp
[email protected]
[email protected]
Standardprodukten-180x180.jpg
Standardprodukten-180x180.jpg.webp
Standardprodukten-300x300.jpg
Standardprodukten-300x300.jpg.webp
Standardprodukten.jpg
Standardprodukten.jpg.webp

    But perhaps it’s an nginx question. Now that I’ve edited the nginx.conf I’m also seeing missing images in the admin interface.

    Plugin Author nosilver4u

    (@nosilver4u)

    I think because your config is telling it to serve webp regardless, and when it can’t find it, it actually is serving a 404 response, would be my guess.

    Try something more like this:
    https://www.ads-software.com/support/topic/rewrite-rules-for-nginx-1?replies=6

    There are a couple other threads, a search for ‘ewww webp nginx’ finds a couple others.

    Thread Starter Mr. W

    (@gabriel-winnberg)

    Slam dunk! Thanks for pointing my thoughts in the right direction. The problem was this line:

    try_files $uri$webp_ext $uri/ =404;

    First it tries by adding the webp extension ($uri$webp_ext). If the file doesn’t exist it looks for a directory ($uri/) of the same name. If I remove the slash / from $uri/ or adds an extra $uir without slash, then it’ll find the original jpeg. I guess there’s little point in looking for a directory, so why include that?

    Solution:

    try_files $uri$webp_ext $uri =404;

    Janiosarmento’s solution in the post you linked to is unnecessarily heavy, and Matteth’s was actually without the slash. I simply missed it.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Some images not served as WebP on nginx’ is closed to new replies.