Hi @bcvcbhqyxcgakhh
Imagify will handle the fallback control automatically, that is one of the reasons we keep original format images on the server.
Tools like Pingdom should not count duplicated requests in this case as the server will not load both images, although there are both in the source. Simply, the code is written that way to call one type of image, depending on the browser that is requesting the page.
Let me know if you need any further assistance, I am happy to help.
Best Regards
Marko
I kindly ask you to inform us which line and file/folder executes due to browser detection and validation:
Your quote: to call one type of image, depending on the browser that is requesting the page.
Hi @bcvcbhqyxcgakhh,
Can you please tell us the use case you’re trying to achieve to be able to help better?
Best Regards,
We try to control browser support. So, which file and folder controls fallback support as website will break in this case and bad user experience due to browser detection and validation.
Hi,
Please allow me some time to get back to you with relevant information.
Best Regards,
HTML5’s element supports fallback support for users from WebP, but is it fallback support for the particular browsers?
<picture>
Hello @bcvcbhqyxcgakhh,
We implement fallback mechanisms in two ways, depending on the “Display images in Next-Gen format on the site” setting:
- Rewrite Rules: If rewrite rules are being used, the browser detection and validation are handled by these rules. You can check the
.htaccess rules or Nginx configuration for the specific rewrite rules in place.
- Picture Tags: When using the picture tag method, we add a
<source> tag for each format (WebP or AVIF), with the <img> tag serving as the fallback for browsers that do not support these formats.
This ensures that the appropriate image format is served based on the browser’s capabilities.
Best Regards,
