$postglobal variables, respectively. When data about the current post is needed, MySQL isn’t queried again; rather, the data is pulled from the
$postglobal variable. The run-time cache is a simple and efficient strategy for caching data.
WP_Object_Cacheclass. The hallmark of object caching is to provide a persistent caching backend that allows cached data to be available across requests. Both
WP_Object_Cacheclass can provide this persistence.
wp_optionstable for data storage. A point of confusion regarding transients as an object cache often comes from fact that transients are stored in WordPress’s MySQL database table. A MySQL database is a minimally sufficient place to store objects as it can be a location that allows much faster retrieval of data than the object’s original location.
object-cache.php. If this file is defined, it will be loaded instead of the default class. This type of file is known as a WordPress drop-in. A few different
object-cache.phpfiles exist in the plugin repository for different caching engines like Memcached, Redis or OPcache.
wp-content/directory, you can define all of the logic related to caching a page.
advanced-cache.phpis that it is loaded in the first 1% of the WordPress page load. As such, if the cached page is found, 99% of the WordPress load is avoided, which leads to a significant performance boost in the application. An important thing to note with
advanced-cache.phpis that it needs a persistent cache to store its data. The most effective solution is to use a persistent object cache as the data store, but solid solutions exist that utilize the file system for this cache.
advanced-cache.phpis the easiest and most accessible form of page caching in WordPress, you can also use a reverse proxy approach with Varnish, Nginx, or a hosted caching solution. We will not go into these solutions here because these are mostly configured at the systems level and have little to do with WordPress specifically. We only touch on this as an alternative to