[Hummingbird] Pages not being cached

Live chatting support is great, but I've been disconnected twice already and can't seem to move forward with my issue. I hope opening a ticket is faster and more effetive.
So I can't seem to cache my pages:
- I tried disabling all of my plugins, except for the WPMUDEV plugins, and activated the twentynineteen default wordpress theme...pages are still not being cached.
- when browsing the website on a different browser, onyl blog post are getting cached, pages aren't.
- if the number of cached pages increases (by pages, in my case I mean blog posts), it goes back down to 0 randomly, without any intervention from my end, just by refreshing the page (even if the "empty cache when new blog post or page is updated" option is enabled.)
- ever since I've activated the WPMUDEV plugin, I can't seem to check my pages scores on Google Page Speed Insight, neither on gtmetrix.com. I keep getting errors...
Your help and assistance is much appreciated,

  • Adam Czajczyk
    • Support Gorilla

    Hello Mandy

    I hope you're well today and thank you for your questions!

    I have visited the site that you assigned to this ticket and "wandered around" a bit. On all the pages (pages and blog posts) I could see this comment in the source code:

    <!-- This page is cached by the Hummingbird Performance plugin v1.9.3 - https://wordpress.org/plugins/hummingbird-performance/. --><!DOCTYPE html>

    which means that the given page (page, blog post etc that is currently viewed) is served from Hummingbird's Page Cache. However, I didn't visit each and every "corner" of your site, just some of the pages and posts. I can see in the back-end that it currently shows that only 28 of 217 detected pages (where page means page, blog post etc) are currently in cache.

    That doesn't mean that other pages will not be cached: the cache is not "created upfront", instead it's created upon "first" visit on a not-cached-yet page and only after that the page is served from cache during next visits.

    For example:

    - there are 3 pages on the site
    - one 2 were already visited by some visitor(s) and one was never visited
    - only these 2 will be cached
    - 3rd one, when somebody visits it, will be served without cache and the cache will be created
    - then the "counter" in back-end will show that 3 out of 3 pages are cached and next visitors will get all of these pages from cache.

    There's a way to speed the caching up by simply crawling them. Here's example service that would crawl your site, speeding up cache creation (no need to download the sitemap from there, just let the crawler scan the site):


    That being said, the fact that you see some pages as not cached, might be related to this but also there might indeed be some issue. What bothers me is that, as you say, the cache is "randomly dropping to 0" and I'd like to check it.

    I see that Page Cache has currently cache debugging enabled so let's keep it this way and please keep an eye on this "cached pages number" and let me know right away when it drops again so I'll access the site again and check the log as it might give some clue on what's happening.

    Could you also please find out (you might need to get in touch with your host for this) if there is any cache (of any type) for the site currently active on the server? if yes, that might explain the symptoms that you're experiencing because server-side cache can "overtake" the "page-level" cache. Briefly speaking: cache created by Page Cache would actually be cached by the server-side cache (sound's a bit like an inception, isn't it?) and this might cause issues/conflicts. That's why I'd like to know of there is any.

    Best regards,

  • Mandy
    • New Recruit

    Hello Adam,

    Thank you for your prompt response, much appreciated!

    There is indeed a caching system going on in my hosting since it's a shared hosting (GoDaddy)...
    Anyway...I'm able from time to time to check my website's score on Google Speed Test Insight tool,
    to be honest i'm a bit disappointed, my score is almost the same as when I dont have any WPMUDEV plugin installed,

    Maybe I'm missing something or doing something wrong, this is my first time using your plugin...

    I would much appreciate if you could have a look and double check my settings,

    Thank you for your understanding,

  • Adam Czajczyk
    • Support Gorilla

    Hello Mandy

    Thank you for your response.

    The server-side cache explains why your Page Cache in Hummingbird "drops to 0" from time to time. To explain it better: let's assume for the moment that there is no server-side cache. What happens is that

    - the user visits a page on your site
    - Hummingbird checks if the cached version of this page exists
    - if not, it lets WordPress generate and serve the page and also saves that generated page as a file on the server
    - if the cached version of the page exists - this one is served.

    The "cached version of the page" is literally a single, plain file on the server.

    Now if you add a server-side cache to that, it means that this "cached version of the page" - so that plain file - is in fact saved "in yet another cache". So it becomes "temporary" and not permanent. Now if the server-side cache is flushed, that file is gone so it means that Hummingbird's Page Cache was also "flushed" as a consequence. That's simplified explanation but should give you an idea on what happens.

    There are two ways to proceed with this at the moment: either flush and disable server-side cache and let Hummingbird do all the work for now or just "embrace" that and accept that from time to time this will be happening. We've got some improvement already planned to make Hummingbird "integrate" with various server-side cache solutions so it would be aware of such cache and could "interact/react" accodingly. That's, however, something that's going to be added in future.

    As for performance tests. Our tools such as Hummingbird and Smush can give a great "boost" to the site performance (though whether it directly affects the score itself is a different story) but it's important to remember that it's always an individual thing: on some sites the performance increase will be really impressive, on some just slight, on some - even though these are very rare cases - it might be barely noticeable. It all depends on server and its configuration and on the site and its setup. Unfortunately, there are so many possible "combinations" of these aspects that it's not really possible to fully automate configuration of performance optimization.

    I checked the site and - its configuration and PageSpeed score (note please: I'm referring to "Desktop" PageSpeed test here) - and there's still something that could be done. First thing would be to "fine tune" Asset Optimization in Hummingbird.

    I'd strongly recommend switching off (at least temporarily) server-side cache for the configuration time as it can severely affect the way the optimization works. Once it's disabled, please go to the "Hummingbird -> Asset Optimization" page and look run "re-check files" option.

    After it completes, look at the 3 buttons next to each file (ignore first button on the left and last on the right). The goal is to get as many of them switched on (they are currently mostly switched off) as possible without breaking the site. The way to do it is a bit daunting task of "trial and error" procedure but that's the only reasonable way:

    - enable these options (buttons) for one or two files from the top of the list
    - publish changes
    - reload the front-end of the site and wait a short moment
    - check the site to see if everything works fine

    If site breaks after that, get back to these buttons and "experiment" with switching some of them on/off until the site is working fine again. Then move on to the next 1 or 2 files on the list and so on repeating the procedure until you reach the end of the list.

    This will let you optimize site assets as much as possible without breaking the site and that should increase both performance and score.

    Additionally, I'd recommend increasing WP memory a bit. The server allows currently up to 368M of memory to be used for PHP scripts while your WP install is still limiting it to its default 40M which is rather a small amount for anything but a default WP install.

    I'd recommend adding following line to the "wp-config.php" file of the site, right above the "/* That's all, stop editing */" line:

    define( 'WP_MEMORY_LIMIT', '256M');

    In order to allow WP use up to 256M of memory. While this most likely will not speed up the site, it should give it a bit more "stability" and might prevent some memory/resource issues in a long run.

    Give it a go please and let's see results, then we'll see what could possibly done next.

    Best regards,

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.