Normally, there is no reason to uncheck this option. This option allows you to cache requests that are made by WordPress REST API calls. Regardless of how you set this option, all non-commenting visitors will still be served the cached version of the page until the comment is approved and the page is purged. The page will be generated from scratch, and the user will see their under-moderation comment. If you turn the option OFF, the user will not be served from cache.It is ON by default, meaning the user will see the previously cached version of the page (and their comment will not appear).It determines how the user leaving the comment will see the page, after they've submitted their comment. The Cache Commenters option is useful in that second scenario. If moderation is enabled, then the comment is not published immediately, the page is not purged, and users will continue to be served the cached version of the page, without the moderated comment. Everyone (the commenter, and all future visitors to the page) will see the newly-published comment when the page reloads. When a comment is submitted on a post, if moderation is not enabled, the comment is published immediately, and the page is purged from cache. Pages will be stored in private cache by IP and session ID. This setting allows content to be cached for logged-in users. If you are seeing a warning that LSCache is disabled, and you can't make it go away, please see our troubleshooting instructions. LiteSpeed Memcached LiteSpeed Memcached.LSCache Developers Guide LSCache Developers Guide.LSCache Without a Plugin LSCache Without a Plugin.WHM LiteSpeed Plugin WHM LiteSpeed Plugin.External Applications External Applications.LiteSpeed Web Server LiteSpeed Web Server.None of the issues seems to be linked to Hummingbird at this point. In this case we suggest to possibly trying the WAF option on the hosting: Slow_log tries to catch scripts that are increase loading times of pages and may be considered a good clue in debugging performance issues. There are also multiple entries related to WordFence in the slow_log: Large autoload options add a lot of delay to each page load as WP needs to request that data from the database each time a page is loaded. Safest solution would be to disable autoload and see if that helped. I’m not able to tell just by looking at them where they come from (definitely none of those is from our plugins) and if we can delete them or disable autoload for them. SELECT option_name, length(option_value) AS option_value_length FROM wp_01options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 200

I’ve ran additional checks and found the following results that seem to be increasing loading times in the case of your site:Īutoloaded options size (2.26mb) exceeds threshold (900kb)Īfter running the following query I was able to find the largest autoloaded options are as shared on the screenshot: I haven’t noticed any increased resource usage on the site in the last 6 hours – analytics data is showing stable operation with plenty of resources available. Would there be anything WPMUDEV could do to check for problems? Could these performance issues be related to insufficient resources while hosting with WPMU? Our website () performance has degraded to the point that we are losing customers. We’re still not sure what caused the assets to be stuck in this case – this would have to be checked more thoroughly. Normally, just clearing the caches in Hummingbird should be enough to make visitors’ browsers to load new assets. Looks like we’ll need to find an alternative caching plugin that works across all devices. We have disabled the Hummingbird plugin for now. We won’t expect our end users to use this procedure when displaying our website.

Backing up to debug only private cache