Takis Bouyouris

Once again, thank you for your kind words!

🙂

Thank you for your kind words, my friend!

The Adaptive Images plugin chooses the closest possible dimension always checking upwards (so that in the process it won’t produce worse quality images than what is required).

Of course this is only meaningful when the images themselves are already big enough so that they can be downsized. If an image is already small enough for a specific request from a specific device then it will not be downsized at all (the original image will be sent).

So, you should set your breakpoints thinking in final pixels. In the case of the iPhone of 375px width then, when the HiDPI support is checked, it will be regarded as a 1125px screen. So if the breakpoints are set as “320, 480, 1024, 1280” then the 1280 size should be used (that is if the original image itself is already bigger than that).

As you may have already understood, this can easily lead to no downsizing at all, if one wants to serve very good quality images even to the smallest devices. But this, in a way, goes contrary to the initial concept of the Adaptive Images plugin.

Personally, I would not really mind even having the HiDPI support disabled, because I would prefer to give priority to speed! But I let my users have the option.

Cheers,
Takis

Hello, my friend,

Thank you also for your time and your kind words!

Indeed this is the case and during the course of the years I have come to realise that not all users use the same technique to achieve this and this has been the cause for these minor discrepancies.

One can put WordPress in its own subdirectory and either make all urls (including the static ones in the /wp-content directory) appear as if they originate from the root url or one can let the static ones appear originating from their actual directory.

So in case 1 you have: http://www.domain.com for the domain and http://www.domain.com/wp-content for the /wp-content, whilst in case 2 you still have http://www.domain.com for the domain but you have http://www.domain.com/subdir/wp-content for the /wp-content (and of course same for /wp-admin and /wp-includes).

(These cases are explained here https://wordpress.org/support/article/giving-wordpress-its-own-directory/!)

We have properly taken care of case 1 but it seems that we missed case 2! What you are describing for your installation is actually case 2.

Although I am not particularly a big fan of this technique at all (it mostly creates causes for edge cases without much enhancement in security) this case is now under my radar and I will work on fixing it in future versions!

Cheers,
Takis

Hello, there,

Normally WPRocket should not have compatibility issues with Adaptive Images. There a number of other possible reasons for problems. Most of them we try to address in the plugin description page, but it does require some reading! 🙂

As a starting point could you possibly send us the results of the Print debug and Print diagnostics buttons in the Adaptive Images settings page?

Cheers,
Takis

Hello, my friend,

First of all, the Adaptive Images plugin only creates images in the cache when it is necessary to do so, in order to reduce the possible server load. This means that, if an image is not requested by a device small enough (ie small enough relative to the original image size and the breakpoints one has set in the plugin settings page), then the image will not be created in the cache (the original image will be delivered).

However, something else might also be relevant to your case. I see that your requests are served via an NginX server which probably acts as a proxy (or a caching server). Is that correct?

If this is correct, then the NginX server is acting like a small scale CDN. This is an exceptional case for our plugin and it is described in the plugin description page under “CDN/Varnish/external caching services”. Basically, this is a case we do not fully support, due to the way caching servers work: they deliver your images directly, thus your WordPress installation (and our plugin) does not have the opportunity to handle (and resize) your images. Thankfully this does not pose a problem, but it reduces the effectiveness of the plugin.

Now, for these cases we have created a special mode, called “CDN support”, in the plugin settings page, which you are welcome to enable and test. Unfortunately, this mode is still a bit experimental as it cannot detect CSS background images.

Let me know if I can help any further with this!

Cheers,
Takis

Hello, again,

Actually it works for all devices, not only mobile devices and tablets. But in desktop devices you usually do not need it that much because they are connected to the internet via fast connections and they have more space to show all the details of bigger images. But it still works there, too!

What image size will eventually be shown depends on the combination of a) the device size, b) the image size and c) the breakpoints that you have set in the plugin settings page.

But note that the plugin checks the device size and not the size of the HTML container element in which the image is placed. The latter would be almost impossible to achieve!

Hope this helps.

Cheers,
Takis