Hummingbird Gets Full Caching (and You Won’t Believe How It Compares to WP Super Cache…)

Over the past year, we’ve really pushed the boat out on Hummingbird, our site optimization plugin, by adding pretty much every single thing you could need to boost your page speed… But there was one thing left.

Caching!

Updated: 08/16/2018 Hummingbird includes page, browser, RSS and Gravatar caching, full Multisite support, all new developer tools and a new streamlined interface.

Well, as of last week, that’s no longer the cache (see what I did there ;) because Hummingbird will now not only minify, enqueue, gzip, browser cache, monitor and report on your site speed… it will now also take complete care of your page caching, just like WP Super Cache, W3 Total Cache and WP Rocket.

So, I figured I’d take it for a spin on my hobby site (which previously used WP Super Cache) and see what the experience (and the results) were like. So without further ado, let’s jump in!

Setting Up Hummingbird Caching vs WP Super Cache

My WP Super Cache Setup

First up, here’s my WP Super Cache config and settings. Super simple, I know, but then again I figure I’m the same as most of you in that I just want a caching product that I can turn on and that does the job for me. So here’s the basics.

Here I’ve got caching turned on (about as basic as it gets!):

WP Super Cache settings
Pretty basic stuff so far.

And here are the preload settings:

WP Super Cache preload settings
More settings…

Lastly, a look at the advanced settings screen:

Here’s what I had set up in the advanced settings.

And here are the results (along with other speedy uppy things, like Smush Pro) that I was getting as a result:

Pagespeed desktop score
Here’s my desktop score…
Pagespeed mobile score
And here’s my mobile score. Not great :/

Yes, I know they are not outstanding scores, but I did mention before that it’s a hobby site, yeh?

And I’m trying to be like a regular Joe on it rather than the tech ninja I actually am [Ed: Ahem, you said this was going to be an entirely honest article James…] so I’m OK with that – I’m definitely not going to get penalized at the very least.

Now… Let’s take a look at how Hummingbird’s new caching feature works and see what kinda results we get.

Setting Up Hummingbird Caching

First up, we’ve worked really, really hard to make caching as simple as possible for you – no more super complex tabs (although advanced functionality is still available), just a simple turn on and leave (if you wish) experience.

Humming caching activation
All you need to do is click “Activate”. Too easy!

And, naturally, we’ve filed it alongside our existing browser caching and Gravatar caching functionality:

Hummingbird caching section
It doesn’t get any easier than this.

And automatically turned it on for all of your usually cached pages:

Hummingbird caching options
Caching is automatically activated and you can choose which types (if any) you want to disable.

As well as, if your require them, adding in extra configurations options like logged-in users, URL queries, updates and, of course, exclusions.

Hummingbird caching settings
Hummingbird’s caching settings are pretty straightforward…

But me being me, I naturally didn’t bother with any of them. I simply cleared and turned off WP Super Cache, clicked “Activate” on Hummingbird Cache, refreshed that (just to be sure), visited my homepage a few times, waited 30 minutes and then did the page speed tests again (I also did them again just now, just to be sure).

My desktop score with Hummingbird caching enable…
And my mobile score with Hummingbird caching.

Aaaaaand….. (drumroll)

The results were… exactly the same :)

Which, in my book, is absolutely fantastic as means that, at least in this case, the new Hummingbird Cache setup is performing as well as the absolute leading (and run by Automattic) caching plugin out there!

Happy Caching (with Hummingbird!)

So now you can, if you choose, have pretty much every single page optimization trick that you could possibly want in one plugin, which, naturally, comes with the level of support and ongoing improvements that you can expect from a WPMU DEV project.

So, am I right? Why not go give Hummingbird a go today (if you’re not a member already you can try out a free 30 day membership, after which you get to keep the plugin even if you cancel!) and let us know whether it does the same for you (or not? or better?).

Also, let us know if there are any other features that you’d like to see in Hummingbird to speed up your WordPress site… Or, are we, just possibly, the first cache of it’s time ever [Ed – groan…], actually done?

Happy caching :)

James Farmer
Let us know what you think of Hummingbird's new caching feature! And if you have any feature requests, drop them in the comments below.

54 Responses

  • friend of Bill. W.

    just wait for it Mr. Farmer :-)
    u know u gonna hear “same score ?”, “what about lazy load ?”, “where is preloading ?”
    “where is ….. ” etc etc.

    but your point is absolutely valid ….
    compared to WP Super Cache that has been developed for years HummingBird is very impressive and deserves great credit !!!
    Congrats WPMUDEV !!!
    consolidating features & plugins into one subscription is priceless !!!

    now i cant wait for other features like lazy load, CDN integration, etc. :-)
    “(see what I did there ;) ”
    :-)

  • Fake Russian Bot

    Very pleased so far with the cache performance. I ditched Comet Cache on a couple of sites in favour of trying Hummingbird’s page cache and it’s pretty much as fast as or faster than Comet Cache, so great job!

    There are a couple of things I can think of right now that would be great to have as well:
    – An AJAX powered clear cache button in the admin bar, not just on Hummingbird pages. With the ability to specify which users/user roles can use that button
    – 404 request caching
    – Manually clear the cache of a specific page
    – RSS feed cache
    – Cache preloading
    – Server load monitoring, don’t regenerate the cache when the server is under heavy load
    – Cache statistics, how many files are in the cache, total filesize of cache, etc.
    – Remove HTML cache comment in front end output (white label it)
    – Optionally disable admin notice for cleared cache message
    – Lazy loading images
    – Serve images from WPMU DEV CDN (Cloudfront)
    – Database optimizations (on a schedule)

    Phew :)

    Still some work to do, James :P But for now you can be proud you’ve got a very solid performance plugin that rivals the best out there!

  • Flash Drive

    Uh… SuperCache is great because it’s dead simple and just works for simple sites. However, it’s far from being the “absolute leading caching plug-in out there”. Pretty much everyone I know will agree WP Rocket is by far the leading solution. I’m not saying Hummingbird is bad, just that above you’ve matched the lowest rung on the ladder, not the top as you seem to be suggesting.

    71 on mobile for a simple site is not very good, on a complicated site perhaps, but I’m guessing your hobby site isn’t that com0lictaed and doesn’t run much that is hard to optimize.

    hHummingbird has potential and I honestly thought it would handily beat supercache out of the box while giving rocket a run for it’s money. Keep the good work, the ui is great and certainly better than W3TC mess at this point.

  • Design Lord, Child of Thor

    Finally! Just 2 days ago I installed a caching plugin to all my sites that already had hummingbird but wasn’t winning the turtle races. The caching plugin was the biggest win ever. Got me thinking why you guys couldn’t do this. Will try this in other sites to compare. May the best one win.

  • Design Lord, Child of Thor

    Congrats guys!! Way to cache up to the competition (see what I did there! ;)).
    But a few questions might arise from our community. For example; Let’s say someone has a website hosted by WP Engine (they have a caching tool found under the “Utilities” settings, simply click and the cache is cleared). However, WP Engine promotes having at least a free CloudFlare account (CloudFlare also has a caching tool) which was also connected to Hummingbird ( an awesome feature, but now we have 3 different tools caching). Most of us speed junkies use and love WPMU Dev’s Hummingbird plugin for all its speed goodies, and now Hummingbird has a cache feature too! Awesome! But now we have 3 caching tools for one website.
    sn’t this gonna cause problems?
    So to recap my question: How does Hummingbird Cache work while having it connected to CloudFlares Caching tool? and some people out there might have a 4th caching plugin such as WP Super cache already installed. Does that mean they should deactivate and delete WP Super Cache plugin and just use Hummingbirds new caching tool? Where does the buck stop?
    Whats the best combo of caching tools?
    1) WP Engine Cache
    2) Hummingbird Cache (connected to ….)
    3) CloudFlare Cache
    4) WP Super Cache (or W3 Total Cache or other)
    All the above running on one website…Will these cause problems when used together?
    What should we use now and what should we get rid of?
    I’m guessing WP Engine cache tool + Hummingbird Cache Tool, deactivate and delete WP Super Cache but what do we do with our connected CloudFlare Account?
    Can anyone shed some light on all this for cache sake?

    • CTO

      I understand it can get a little confusing! Basically there are 3 types of common caching that plugins/hosts refer to:
      1. Browser caching – this is for static files that rarely/never change like media/js/css. Gravatar cache falls under this as well. HB, Cloudflare, do this level.
      2. Object caching – this is a server level layer in front of the db. It’s pretty advanced for the avg user to be able to setup and use, but many managed hosts like WP Engine provide this.
      3. Full page caching – this is the traditional/flagship feature of most caching plugins, and what HB just launched. Cloudflare doesn’t do this (unless you’re an advanced enterprise customer with a custom coded plugin like us), but many managed WP hosts like WP Engine do usually at a more advanced server level using memcached/nginx/varnish. If your host provides this feature, you should use it, and if not enable it in Hummingbird.

      In general you can use multiple caching plugins at the same time, as long as they are designed/configured to only do one of these 3 levels. You can’t have 2 object caches, or 2 full page caches or you’ll have trouble.

  • friend of Bill. W.

    wpengine as far as i know strictly bans caching plugins among other plugins.
    besides its never a good idea to use two or more caching plugins that do the same thing.
    the beauty initially about HummingBird was that it simply gave insight/suggestions etc.
    but now it has become more robust where you can actually choose to have the plugin itself perform page caching, gravatar, browser caching etc etc.
    so the beauty is that it gives you options.
    for example i use hummingbird for everything except CDN because it does not have this and activating “keycdn cdn enabler” will not conflict with hummingbird in any way.
    i did ask about CloudFlare specifically in the forums and was advised to choose either or ;
    https://premium.wpmudev.org/forums/topic/using-cloudflare-with-hummingbird-vs-cloudflare-plugin
    which makes sense !!!

  • New Recruit

    Looks promising. We are looking for a multisite caching solution that can be configured through the Super Admin but not available to site administrators of child sites. I’d like to configure caching, connect it to our Azure CDN and be off and running. We would like to avoid having to configure caching for each child site for the site administrator and then hiding those options with something like the Adminimize plugin. Thank you for your work.

  • New Recruit

    Great news!
    Looking forward for further development of caching options. I’d like to use Hummingbird caching instead of Hyper Cache / WP Super Cache on my Multisite network. One of the most valuable feature would be custom caching settings (page types, urls to reject, clear cache button) for each site.

  • New Recruit

    Hi!
    Ummmm Am I missing something? What version of Hummingbird has the new Caching?
    I have v.1.6.2 on my site and WordPress.org is also 1.6.2 and I see no Page Caching in Hummingbird.
    Is there a new version not yet on wp.org but available elsewhere? (Else how did the folks above try it?) Did this postc ome out before WP was updated? Is it a Premium feature?
    Inquiring minds and all of that!!

  • The Exporter

    James that is exactly the way WPMUDEV should go – combining the power of many plugins in the WP universe into one great plugin available with its full power for members. A great way to drive members here and an even greater way to also reduce the pricing structure in future to enable even more people to join! At least I hope so!

  • Site Builder, Child of Zeus

    Loving it, except for one big thing—when new posts are published, it seems the RSS feed doesn’t freshen! We’re hosting many sites for whom RSS needs to be reliable and up-to-date, and even excluding the /feed or /rss2 permalinks in the Page Cache “exclude” list doesn’t flush the feed. This is also true in situations where we’re using secondary loops/queries—in a page template, for example: a page might have a query for the latest 3 posts, but when a post is published, that page remains statically cached and doesn’t notice that it should be refreshed, as well. To solve this, obviously, I can simply disable caching on ‘pages,’ but then neither it nor any other pages will be cached.

    Hummingbird REALLY showed us great improvements all around. I hope I’m making sense—and I hope I’ll be able to use the plugin soon. Thank you!!

  • Mr. LetsFixTheWorld

    On one hand, having more features in a single product is elegant and convenient. On the other hand, with a single point of potential failure, all eggs in one basket, etc, we also have a potential vulnerability. Assume the off-hand (never happens! *cough*) chance that HB introduces a regression in one of its features. If we turn if off to avoid that one problem we lose all benefits the one plugin provides. More code in a single plugin means more that can go wrong in development, in providing a single product that serves all needs. Whereas modularization reduces the chance of code here breaking something there, and can help to speed the life cycle of each component. This also applies to Defender.

    So, it’s good that HB has caching for sites that are OK with ditching what they have (yeah, that includes me). But it also now has extra code that gets pulled into memory, and some additional limited CPU cycles, even for sites that aren’t using it. What I’m suggesting is that the real test here for any brandx would be to run it with the previous version of HB (minus the caching code).

  • Mr. LetsFixTheWorld

    There are three aspects to performance that I don’t see addressed anywhere and I’m wondering if these might be evaluated for HB.

    The first is related to CSS bulk. When the server send CSS to the browser/client, it includes all possible CSS. The client must then spend processing cycles working out what it does need or not. The server should have a better idea of what CSS isn’t required to render a specific page, or section of the site, and only send up what’s required. I know what we’re doing is providing the client with all the CSS it needs (in a single payload which is then cached), and that adding server-side code to whittle through CSS would impose a per-transaction load that might be even more non-performant. But we do something like this with JavaScript whenever possible – at least I think HB does some of this. This concept is something that’s bothered me for a long time and I recently found it’s a widely discussed topic.

    The second concept is about WP itself. To generate a given page a lot of code is executed as we add more plugins. Plugins exclude themselves from transactions by not hooking into functionality that doesn’t apply to them. But as with CSS and JavaScript, sometimes we only need a part of a plugin, and yet a lot of code will get loaded anyway. We shouldn’t need to load all of the code for a plugin to execute a small function. What’s needed in optimization (*gulp* maybe changing the way plugins are written) is a way to minimize the code that’s loaded to only what’s required in the current context. As an example, consider all of the code that checks to see if a user is an admininistrator before taking one action or another. By the time that code has been reached the test for user role has been made a hundred times – the code for administration should never have been loaded into memory for that check to be a requirement.

    From that … I understand no plugin can evaluate another plugin to decide what code doesn’t need to be loaded, but if we had a feature where we could profile exactly what gets run and called in various transaction contexts, each of us could work with developers to minimize code that doesn’t need to be loaded or executed. Yes, I know there are plugins out there for this, especially one that’s been abandoned for a few years, doesn’t work anymore, and somehow it keeps getting referenced as the go-to tool. But HB is all about performance. It doesn’t need to do this live. It can point us to code bottlenecks so that we can fix issues on our own, and in thus doing, it will continue to be a valued tool for improving performance.

    The third and (is he done yet?!) final concept is on memory management. Maybe I’m describing mem-cached here or another utility. On each transaction it looks like we load a new instance of every plugin. If I have 10 plugins, one user request will consume maybe 50MB in a single transaction. 10 “truly” concurrent users will multiply that factor such that the same code will be loaded 10 times for 500MB. For a site that might have 20 plugins for about 100MB per transaction, this means about 10 “truly” concurrent users per MB of RAM, and in a shared host limited to 120MB per transaction, or a common VPS with a total of 2-4GB, that’s not very scalable. Of course we can support more concurrent users. By “truly” concurrent I mean transactions simultaneously hitting the server within a window of about 50ms to 2 seconds. The faster the server and other details the shorter that window and the more transactions you can put through. But the point here is simply that WP forces a multiplied load of all code. There should be a way to more effectively cache code as well as common objects in server memory to reduce that multiplier effect. Reducing the footprint of WP will allow us to add more functionality, and perhaps change how we approach the common debates on plugin abuse. It’s only abuse because it’s rough on the server, if it’s not as rough on the server, it’s no longer abuse…

    • New Recruit

      Hi Tony,
      If you forage the web enough, you’ll find that some plugins do have ways to not be loaded on pages where they are not used… (Contact Form 7 comes to mind) but it’s still only some and it usually takes some coding to implement.
      However there is a plugin that will allow plugins to be on or off for various pages and conditions. It’s called “Plugin Organizer”
      It’s a little daunting to orchestrate all of a sites’ plugins, especially if there are a lot of them.
      I have no idea how it would interact with Hummingbird’s Minimization and Caching though

      • The Exporter

        Hi Tony

        I agree that a huge multifunctional plugin might be more error-prone.
        One reason in Processwire [https://processwire.com] – another CMS where lots of people gathered who got frustrated by WordPress and Drupal – nearly everything is modular into the smallest parts. It makes it also very fast and very easy to update as only those parts get updated which got updated and not always a huge plugin which has only a tiny little change because a Japanese translation has been added to a subfeature in it.

        On the other hand having one plugin can also be useful, as it will provide you a better overview as a one stop soultion which might even produce redundancies with other plugins.

        Redundancies are mostly avoided in Processwire because of its tiny modular structure so many features can be reused in many different contexts. But the downside is that it is much more difficult to keep an overview of all those tiny parts which work together in Processwire and which depend on each other.

        WordPress is a system which likes to produce a huge overhead of stuff which doesn’t get used, but that s WordPress since its infancy due to the fact that it used only 10 tables at the beginning and even right now – i.e. defender since 1.7 – packs all its log entries (thousands) into the posts table which makes it a mess.

        In Processwire they also use the so-called pages table for a lot of things but usually new tables get created with the data of those plugins – so it is much easier to keep an overview when having a look into the database.

        In terms of performance Processwire is much faster than WordPress and much more secure as WP too even it is using lots of tiny little modules but together like in a lego.

        I think the reason for that is the fact that the amount of used code is reduced drastically by that very modular structure.

        To do the same in WPMUDEV WPMUDEV would need to rethink their complete plugin strategy and build lots of tiny modules which perhaps do only one thing – but not two, and then have a plugin which simply puts together all those tiny parts into a combination.

        WPMUDEV has 120 plugin plus 4 for buddypress.
        Many of those plugins still contain code from WordPress 2.8!!! and have deprecations in which show that they probably never got properly maintained since years (when was WP v. 2.8? – how many years ago?)
        Instead of reusing their own codes WPMUDEV seemed to have been using many different developers which not even know from each other – at least not about the already existing code. One reason for sure which causes that is the fact that the code of WPMUDEV is not accessible for development via GIT.

        With professional tools it would be very easy to spot all that redundancies, but as long as the WPMUDEV git repositories are not available even for members who pay 600$ a year and run web agencies with developers who could speed up the process with their contributions, nothing will change, unless there is a fork or a group of members –
        could be also people from elsewhere actually, which do exactly that. Taking a Master set of plugins and splitting all those parts up into tiny little modules which then could be reused. This would reduce the processed code tremendously.

        Of course, all Themes would need to be handled in a pretty similar way as right now the WordPress device is to have it all. So you do best by having a Theme which has tons of headers, footers, menus, blocks, post types etc p.p. and then the Theme must have a way to reduce all the css and js code and even html and php code to the amount which actually gets used.

        A great example which is doing that is the publisher template for better solutions. It is what I would call an all in one template build unfortunately on visual composer which ads tons of code itself but the theme has tons of options and finally, the code gets optimized so that still very good Google results are possible. They even have now an AMP mobile template.

        In Processwire you won’t get even to that mess as the way building a site is very design driven. You choose a nice looking template with all its features you like to have and then you only replace the parts which are dynamic or should be editable.

        You can take any HTML template which already reduces a lot of code instead of using a wp template or even one from DIVI or one which is using visual composer etc.

        The bloat of code in WordPress is homemade and can only be targeted if i.e. WPMUDEV as a plugin and theme provider which can offer their members lots of functionality right out of WPMUDEV coded parts. If those WPMUDEV Plugins would get modularized into tiny parts and then recombined and reused to fulfill perhaps even complete new tasks. It would be a completely new way of doing WordPress and therefore I am sure it would never ever happen.

        So if you need a fast reliable, very flexible and not at all messy CMS use Processwire instead. If you like the messy style or simply like not to change stay with WordPress as they will for sure get messier, more combined BUT they also will speed up a bit as the servers will have more memory ;-) and they will be faster too every year.

        Kind regards
        Andi

  • WPMU DEV Initiate

    Hi James, we are already WPMUDEV Customers and we are testing your products. We operate our wordpress installations in a cluster (AWS container service with a shared file system). To compensate for the latency we use the OP cache function of WP rocket. Is this also possible with Hummingbird?
    Best Regards Stefano

  • Site Builder, Child of Zeus

    The only annoying thing is that it doesn’t work on Multisite – live support and I had a play: it only works for the primary site and not for sub-sites, not least those Domain Mapped.

    As a result, I had to pay out $99 for WP-Rocket.

    All this is a bit poo, especially at $49 a month for a “complete solution” to WPMU Dev…

    • Developer

      Hi @brumbino,

      Could you please tell me what issues you have with the multisite install? Hummingbird is fully compatible with multisite installs and should handle page caching for subsites well.

      I would suggest you start a thread on the support forums and open up support access to your website, so we can investigate your issue further. Or if you prefer, you can leave you reply here.

      Best regards,
      Anton

Comments are closed.