Menu Caching

We all know that database calls are the main performance bottleneck in WordPress. What most people don’t know though, is how “expensive” in terms of performance the WordPress menus are.

This plugin will cache the menu HTML and show the cached version to your visitors, saving your database from far too many unnecessary calls.

Menu data are scattered across six(!) different database tables. When a user visits a page, an odyssey throughout the database begins.
In ‘wp_terms’, ‘wp_term_taxonomy’ and ‘wp_options’ tables we’ll find menu ID, slug and theme location. Then ‘wp_posts’ and ‘wp_postmeta’ to find menu’s nav items and their metas.
In the metas, we will find its targeted object, so let’s pay ‘wp_terms’ or ‘wp_posts’ a visit again to find the menu item’s target and ‘wp_termmeta’ to find its metas.

These are a lot of tables and even more database calls! When all required data is collected, the menu HTML is created and it is shown to the user.

The same process is repeated for every menu on the page. Desktop menu, mobile menu, some menus on the footer, a menu for the customer account on the header’s right next to the cart icon…

Imagine all these menus, some of them with decades of menu items, loading in every page for every visitor on your site.

Menu changes are very rare and this makes them an easy target for caching. Caching the generated menu HTML will prevent all these unnecessary database calls and greatly improve page loading times.

Full features list

• Caches all classic WordPress menus to improve page loading time.
• Enable/disable caching per menu.
• Clear all menu cache with a button on the settings page.
• Every time you edit a menu, its cache is automatically purged.
• All cached data are automatically purged every 10 hours to keep everything fresh, like nonces etc.
• Compatible with caching plugins like WPRocket, W3 Total Cache etc.
• Compatible with most translation plugins. Tested ok with WPML and TranslatePress.

How it works

Every time a user visits a page with a menu, WordPress collects all menu data from the database, and then runs a walker to create the menu’s HTML. Right before this generated HTML is returned to the user, the HTML is saved in the database in a transient.

Next time a user requests this specific menu, the saved HTML will be returned, instead of creating the menu from scratch.

Test results – How effective is it anyway?

If you use a good caching plugin and a certain page is served from cache, then you won’t see a difference in loading times. BUT… there are many cases when a page is not served from cache and in that scenario you will notice a huge difference.

Some of the scenarios when a page is not served from cache:

• If you are not using a page caching plugin (Why not? Please install one!).
• No existing cached version exists of the requested page. You benefit from menu caching during the first page load on every page, before the cached version is saved.
• When users are logged-in. Even when using a per-user cache for logged-in users, menu caching is still super useful to quickly create the menu as the cache files are getting created.
• On e-commerce sites on pages that can’t be cached by default, like cart, checkout, my account, wishlist etc.
• In most e-commerce sites, when a customer adds something to cart, then serving pages from cache stops to prevent false data in the mini-cart.
• On some AJAX requests that load page content that includes menus.

Let’s see the results from some tests run on a medium-to-large e-commerce site with a mega menu with many categories, a separate mobile menu and a couple more small menus.

For admin user:

• Loading time for all menus – no menu caching: 0.46s (in average)
• Loading time for all menus – with menu caching: 0.0015s (in average)
• Speed benefit: 300+ times faster – menu loads almost instantly!

For incognito visitor:

• Loading time for all menus – no menu caching: 0.232194 sec
• Loading time for all menus – with menu caching: 0.001185 sec
• Speed benefit: ~200 times faster – menu loads almost instantly!

Of course these numbers depend on your WordPress installation, your server setup and so many parameters but the outcome will be the same.

With menu caching, instead of building the menu every time and losing precious time during page load, your menus will load instantly from cache.

Compatibility with new “block” themes

Menus on the new block themes are constructed in a different way via the block editor, and not via the classic nav builder we all love to hate. This plugin can’t optimize menus built with the new block editor. It’s not going to break anything though, it won’t do anything at all. If you use a classic theme like 99.9% of the WordPress websites out there, this plugin will be useful to you.

Roadmap

This plugin does only one specific thing, menu caching. There is no plan to add more features. Of course small improvements may be implemented, and if any bug appears, I will try to fix it. Next versions will try to expand compatibility with more popular themes.

A next update is already under development, intending to add compatibility with the Woodmart theme.

If you have any good ideas about this plugin and you want to contribute, you can make a PR in the github repo.