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

Everytime 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 not see a difference in loading times. BUT… there are many cases when a page is not served from cache and it 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.

Read the full description on the official page →