I am working on a site that I've inherited, and I'm looking at the .htaccess file. Truth be told I'm really NOT familiar with writing custom .htaccess rules, so I was wondering if someone can explain to me what is going on in this code snippet?
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
</IfModule>
After doing some googling, I'm pretty sure its taking any image that's served up and returning with webp on the end instead of its original extension?
I believe the intent of the code is to fool pagespeed insights so that it doesn't complain about serving next gen image formats.
I was just wondering if someone can give me a full break down on exactly what is going on and how it works?
Also, I've noticed that when I do change image sizes on the site (for optimisation purposes), pagespeed doesn't register the changes whilst this code is present in the htaccess, like its contributing to some sort of image cache? If I remove this snippet, pagespeed detects the new optimised images?
i'm pretty sure its taking any image thats served up and returning with webp on the end instead of its original extension?
Basically, yes. (Although, it's not a "redirect".)
More specifically... (providing mod_rewrite is enabled - checked by the outer <IfModule mod_rewrite.c> container):
RewriteRule (.+)\.(jpe?g|png)$ - For every URL-path that matches the regex (.+)\.(jpe?g|png)$. In other words, any URL that ends in .jpg, .jpeg or .png.RewriteCond %{HTTP_ACCEPT} image/webp - And the Accept HTTP request header contains the string image/webp. In other words the user-agent accepts webp images.RewriteCond %{DOCUMENT_ROOT}/$1.webp -f - And the corresponding .webp image exists in the same place as the requested file. eg. Request /foo/bar/baz.jpg and /foo/bar/baz.webp exists.RewriteRule -------- $1.webp - Then internally rewrite the request to the .webp image (eg. foo/bar/baz.webp). Note that this is not a "redirect", the user-agent still sees the original .jpg (or .png) filename. Also...
T=image/webp - Sets the Content-Type header to image/webp. (Overriding the image/jpeg or image/png value that would otherwise be sent.)E=accept:1 - Sets the environment variable accept to 1. (This can then be used by your application.)I believe the intent of the code is to fool pagespeed insights so that it doesnt complain about serving next gen image formats.
I don't think the intent is to necessarily "fool pagespeed insights". (That's a lot of work just to fool a tool!)
However, it does allow graceful degradation... a .jpg is served by default and .webp is served if the user-agent supports it (and it exists!).
Also, i've noticed that when I do change image sizes on the site (for optimisation purposes), pagespeed doesn't register the changes whilst this code is present in the htaccess, like its contributing to some sort of image cache? If I remove this snippet, pagespeed detects the new optimised images?
Are you regenerating the .webp image?
This code only applies when requesting .jpg (or .png) images and the corresponding .webp image exists. Unless you also update the .webp image (or it didn't exist in the first place) then any compliant user-agent will not see a change in your image.
In the future... when everything and everybody supports .webp images then you could safely remove the two RewriteCond directives (and the relatively expensive filesystem check). And save all your images as .webp (no .jpg images exist on your site). The image URL would still be .jpg. These directives allow you to upgrade your images without having to change the URL.
In which case you should also remove the <IfModule mod_rewrite.c> wrapper as your site is now dependent on mod_rewrite doing its thing. The <IfModule> wrapper should only be used if mod_rewrite is optional to your site working "normally".