Denis Ryabov

Would taking a look at our other plugins help?

Could you send the list of active plugins to [email protected]? I’ll try to check which ones might be interfering with PageSpeed Ninja.

Also, could you check the container logs for possible errors (maybe an error in the PHP file, or execution timeout, etc.)?

Unfortunately, my experiments with Docker and the debug build of the PageSpeed Ninja plugin didn’t reveal any issues with the page cache. The cache cleaner script correctly removes the internal cache and related files in the /s directory.

I used a standard docker-compose.yml from https://hub.docker.com/_/wordpress. Could you provide more details about your specific Docker settings or any additional plugins that might be affecting caching?

Right now I see an inconsistency on your site (some /s/*.css files don’t exist) between the page cache and the internal cache that synchronizes the time-to-live of files in the /s directory (it turns out that there is a page cache file, there is an internal cache file, but there are no files referenced by the internal cache). In such a situation, you need to Clear All the Cache and the Page Cache in the Troubleshooting section (see Advanced Settings).

I’ll try to run some more tests with the Docker container and a short time-to-live value, maybe I’ll be able to reproduce this bug eventually. Tell me, do you mount additional directories or volumes when you start docker? If so, how do you mount them (volume or bind)? And are there any symbolic links at the root of the site (or higher in the directory hierarchy)?

Also, could you tell, what your value is for the “Caching Time-to-live” parameter (see Advanced Settings)? It is also possible that you manually cleared the cache earlier, but did not clear the page cache in the Troubleshooting section. This can also cause inconsistencies, but most likely the problem is somewhere else.

Is this issue still present in the recently released version 1.4? There have been many changes and optimizations related to caching, CSS and other things that may be related.

Thank you for bug report, the issue is fixed in version 1.4.1.

“1?request(s)/week” is related to external Critical CSS generation service. The plugin does as much as possible locally (including merging of CSS). Could you post URL of your website (or send it to [email protected])?

Are you logged in to the site? In this case optimization is disabled (unless the “Enable for Logged Users” option is enabled, but I wouldn’t recommend doing that).

Do you have the “Avoids enormous network payloads” section enabled? The plugin should merge CSS if both this section is enabled and the “Merge CSS” option within it (see Advanced settings) is enabled.

The link is completely optional. The plugin asks for this link during the initial setup (a popup window where you select the optimization preset contains the “Support badge” option), and it can be changed at any time in the Advanced settings.

If the problems only occur on the front page, then there is most likely a conflict with the Critical CSS setting somewhere, and the solution is to disable it.

If not, then the problem may be that the pages are cached somewhere else (not in the PageSpeed Ninja plugin), so that when PageSpeed Ninja considers that certain optimized style and script files are outdated and can be safely deleted, the pages that use them are still available through some other cache (webserver’s cache, another caching plugin, caching frontend proxy, etc.). As far as I can remember, the wordpress:apache container itself does not use caching. So, do you have any other optimization or caching-related plugins installed?

1. What web server are you using (Apache/Nginx/whatever)?
2. Do you have error messages in PHP’s error_log file?
3. Do you have “Critical CSS” enabled in the “Eliminate render-blocking resources” section of the Advanced settings?

I’m closing this issue as resolved. On the one hand, an additional check has been added to the plugin to eliminate the main source of this issue. On the other hand, I’ve sent a patch to PHP so that reading WebP images does not result in a Fatal Error: https://github.com/php/php-src/pull/13774

This issue is fixed in version 1.3.12 by disabling lazy video loading for video shortcuts. Maybe we will later develop a lazy loading method for the “mediaelement” library used in WordPress, but until then it will be so.

This is most likely due to lazy loading of the video. I’ll try to reproduce the bug and release an update. In the meantime, I recommend temporarily disabling lazy loading videos in the Advanced -> Defer offscreen images -> Lazy load videos.

Try version 1.3.4, the issue should be fixed there.

PS. Currently, any error in the WebP processor in PHP results in a Fatal Error. I’ll try to prepare a patch for PHP so that in future versions of PHP it will simply issue a Warning instead of a Fatal Error (because there are other types of Fatal Errors in WebP processor that are very difficult to detect in advance).