Performance¶

• Table of contents
• Performance
  • Getting optimal performance
  • Metadata Caching
    • Notice
    • Show timing information
    • Enable metadata caching
    • How it works
    • Clearing the cached metadata
    • Using alternative transient storage backends
    • Troubleshooting
    • Further reading

This page contains information related to the performance of WordPress when Add-Meta-Tags is activated and, also, insight about the best practices in order to minimize the metadata generation times.

Getting optimal performance¶

Many new features and improvements have been implemented in Add-Meta-Tags during the last years. Moreover, there is excessive usage of data sanitization in order to avoid incidents of abuse. All these implementations have slightly increased the time that is required to generate the relevant metadata.

TODO: Analysis of:

• info about metadata in head/footer/content section
• overhead of Schema.org microdata

Metadata Caching¶

This section contains information about how Add-Meta-Tags can cache the generated metadata and aims to help you decide whether you need to enable this feature or not.

Metadata caching should be the last thing that should bother you while configuring this plugin. You should consider enabling it only after you have finished configuring the rest of the settings.

If you are here to troubleshoot a problem you have encountered with metadata caching, please head down to the Troubleshooting section for quick tips.

Notice¶

Metadata caching is an experimental feature, which should only be used by experienced WordPress users. If you are a WordPress beginner or if you don't have enough knowledge about the concept of caching and, especially, if you have followed instructions without having understood how this works, please keep this feature turned off, read this section of the documentation carefully and ask any questions you might have before enabling it. Even if you do otherwise, your web site is not going to be harmed in any way, but it is always a good idea to have a good understanding about how things work.

Show timing information¶

If this option is enabled, information about the total time that was required to generate a block of metadata is printed. This feature, generally, should not be enabled, unless you want an indication of the metadata generation times in each request.

Make no mistake, the printed timings are not a benchmark, but rather very rough indicators about how Add-Meta-Tags performs in your specific environment. Moreover, these timings may differ very much, even in consequent loadings of the same web page. This happens because other factors such as the server's load play a determinant role on how WordPress performs. In general, timings you get on live web sites, in shared hosting environments, on virtual servers with shared resources or even on dedicated boxes on which, apart from the web server, other production services are running, are not going to be consistent. This is not a problem of the plugin and there is absolutely nothing that can be done about it.

Enable metadata caching¶

Metadata caching can be enabled by setting the number of seconds, for which the metadata should be cached, to a number greater than zero.

Metadata generation requires some system resources. By caching the generated metadata, the plugin does not have to regenerated it in subsequent requests, but, instead, use the same cached metadata until it expires. If this feature has been enabled, Add-Meta-Tags caches the metadata the first time the page is requested using the WordPress Transients API, which is meant to be used to store temporary data that expires inside the WordPress database or other storage backend for quick access. No extra database tables are created for this purpose. WordPress itself already uses the Transients API for similar purposes.

Obviously, metadata caching comes at the cost of some storage space, which raises the question "Should I use it?". Unfortunately, there is no clear answer to this question, but it depends on many factors. In general, low or mid traffic web sites would see very little benefit by using metadata caching. On the contrary, on high traffic web sites, and only in case WordPress has to load on every request, every millisecond counts and in this case the benefits can be great. On the other hand, regardless of the amount of the web traffic, in case a caching proxy server or a content delivery network (CDN) is used in front of your WordPress driven web site or if a plugin that produces static versions of your dynamic web pages is active, the benefits of metadata caching are minimal. In fact, in such cases caching metadata should rather be considered as a waste of even the little storage space that is used than a performance boost. Additionally, in very large multi-site WordPress installations, on which the superadmin does not have full control over the various blogs, under certain circumstances, metadata caching could lead to a significant increase of the used storage space in the database.

You should always keep in mind that this feature exists only for those who judge that they need it. There is no general rule that applies to all cases. Enabling it should result is slightly better page loading times in several cases.

How it works¶

At this time, metadata can be cached for published content pages (posts, pages, attachments, custom post types, products, etc), but not for archives or other custom content. This happens not only because metadata generation for archives is not a computationally expensive process, but also, more importantly, because more research needs to be done to determine whether such a feature could be abused.

If metadata caching has been enabled, Add-Meta-Tags, before attempting to generate a new metadata block, checks whether a cached metadata block, which has not expired, already exists. If such a cached block is found, then it is used as is.

Clearing the cached metadata¶

If a published post, for which metadata has been cached, is edited and saved, then automatic purging of its cached metadata takes place. Add-Meta-Tags will generate a fresh metadata block the next time the post's page is visited. So, in order to manually clear the cached metadata for a specific post, page, attachment, etc, all you have to do is to save it. Purging the cached metadata of individual post objects works regardless of the storage backend for transient data.

Moreover, every time you save the plugin settings, all metadata entries that have been cached in the database are automatically purged in order to avoid using stale metadata which has not been generated according to the plugin settings that are in effect. This is by design. Please note that this automatic purging of the whole metadata cache when the plugin settings are saved will not work in case a different storage backend than the database is used by WordPress to store the transient data. In such advanced configurations clearing the whole metadata cache can only be done manually. The manual purging of the whole metadata cache can be performed using the amt command of wp-cli. This manual purging operation is transient storage backend agnostic. Please make sure to read the Using alternative transient storage backends section below for more information about the best practices when using alternative storage backends.

Another useful technical note is that WordPress keeps expired transient data in the database or other storage backend until it is requested again. The transient data is not automatically removed by scheduled clean-up jobs. This is by WordPress design.
How many seconds should metadata be cached for?

Since you are the one who knows the details of your environment and the general configuration of your web site, this is your call. Setting the caching timeout to 60, 300, 86400 (a day), 604800 (a week) seconds or whatever is totally up to you.

However, some details need to be taken into consideration when a storage backend different than the database is used. Please make sure to read the Using alternative transient storage backends section below for more information about the best practices regarding the caching timeout in such configurations.

Using alternative transient storage backends¶

By default, WordPress stores the transient data in its database, but different storage backends may be configured for this purpose. Add-Meta-Tags uses the Transients API to manage its metadata cache, so it is going to work fine regardless of the type of the storage backend, except for the automatic purging of the whole metadata cache when the plugin settings are saved, which does not work in case a different storage backend than the database is used.

If a different storage backend than the database is used for the transient data, setting a caching timeout and thus enabling metadata caching in Add-Meta-Tags should be the last thing to configure. If you set a big caching timeout and later make changes to the Add-Meta-Tags configuration, especially changes regarding the enabled metadata generators, the metadata blocks that have already been cached will not be cleared when the plugin settings are saved, because this automatic purging of the full metadata cache works only when the cache is stored in the database. In such cases, manual purging of the whole metadata cache has to be performed from the command line.

If you are using an alternative transient data storage backend and access to the command line is not possible, then you should reevaluate your cache expiration strategy and set a lower caching timeout, for instance 60 or 300 seconds. This way your posts will contain stale metadata for a very little amount of time until it expires, in which case a fresh metadata block will be generated according to the plugin settings that are in effect.

Troubleshooting¶

In case you are getting unexpected metadata in your pages, here are a few things you can try in order to troubleshoot.

Pro tip: before checking the HTML source code of the page, please make sure you have cleared your browser's cache to prevent it from getting in the way. Alternatively, you can hard refresh the web page, for instance by pressing Ctrl-F5 in Firefox or Chrome.

First, if you are seeing unexpected metadata in the HTML source code of a content page, for instance a post or page or attachment, try to resave it in order to trigger the automatic purging of its cached metadata. If for any reason this does not help, turn off metadata caching globally in the Add-Meta-Tags settings. This can be done by setting the number of seconds to cache metadata to zero and save the settings. Saving the settings also automatically purges the whole metadata cache. If you are using an alternative storage backend for transient data (see above), use the amt command of wp-cli

If you are still seeing wrong metadata in the HTML source, then the metadata caching feature of the Add-Meta-Tags plugin is not the cause of the problem. If you are using a caching proxy server, a CDN or a caching plugin for WordPress that generates static versions of your dynamic pages, please make sure to purge their caches and ask for help in their support channels.

Further reading¶

Many new features and improvements have been implemented in Add-Meta-Tags during the last years. All these implementations have slightly increased the time that is required to generate the relevant metadata. Several code optimizations have been planned for the future.

In the meantime, check the Performance section of the technical documentation. (currently, work in progress)