As a WordPress developer, you probably already know how important performance is to a successful website. However, understanding transients in WordPress and how they\u2019ll help you optimize your projects can be a little tricky.<\/p>\n\n\n\n
Fortunately, when you break them down, transients aren\u2019t all that difficult to understand. As long as you keep a few key guidelines in mind, you should be well on your way to incorporating them into your next WordPress plugin.<\/p>\n\n\n\n
In this post, we\u2019ll provide an overview of what WordPress transients are, along with how and when to use them. There\u2019s a lot of ground to cover, so let\u2019s get right to it!<\/p>\n\n\n\n\n\n
In order to understand transients, it\u2019s helpful to have some basic knowledge of caching<\/a> and Application Programming Interfaces (APIs)<\/a>. <\/p>\n\n\n\n Caching webpage data is essentially a way of temporarily saving a website\u2019s data so that if there are multiple requests for the same data, the site doesn\u2019t have to re-run MySQL or PHP. This can save seconds of time and reduce server load.<\/p>\n\n\n\n The idea is to keep data around temporarily, hence the word \u201ctransients.\u201d The Transients API is similar to the WordPress Options API. <\/p>\n\n\n\n You give data a name and a value\u2014which can be complex, like a multi-level PHP array\u2014and it stores the data. Later, perhaps even on a different request, you can retrieve that data using its name. The difference is that data in the Options table will stick around forever. That is, you can store data, and three years later, it will still be there.<\/p>\n\n\n\n Every transient is made up of three parts:<\/p>\n\n\n\n On the surface, that\u2019s all there is to WordPress transients. However, in order to use them properly, there\u2019s more you need to know.<\/p>\n\n\n\n Transients data will not stick around, however. That\u2019s the point! You can request the data, and find that it\u2019s missing in one of two ways. First, when you store<\/em> the data, you specify an expiration date. For example, you could say \u201cstore this for three hours.\u201d So if you request it after four hours, it will be missing.<\/p>\n\n\n\n The second way is that piece of data is allowed to simply vanish, at any time, for any reason. That sounds odd I know! What\u2019s the point of storing the data if you can\u2019t count on it? <\/p>\n\n\n\n The point is that the storage is a request which WordPress will attempt to honor, but because of this flexibility, it\u2019s possible to use different kinds of implementations for transient storage, and that means it\u2019s possible to use different, advanced technology to make transients extremely efficient, and operate properly even in a multi-server clustered environment.<\/p>\n\n\n\n Because of this \u201cvanish at any time\u201d thing, you generally use transients for a cache. That is, if you need to compute something that takes real time, like a slow MySQL query, or retrieving data from an external source like someone\u2019s Twitter or RSS feed, you can store the computed data in a transient, knowing that if it goes missing it\u2019s always possible to recreate it. <\/p>\n\n\n\n But in the usual case\u2014when it does NOT go missing\u2014you have the data quickly without having to recompute.<\/p>\n\n\n\n As we mentioned earlier, the primary benefit of transients is that they improve website performance<\/a>. Here\u2019s a rough outline of how that works, using the Google Site Kit<\/a> plugin as an example.<\/p>\n\n\n\n When the plugin is activated, it uses an API to display data from platforms such as Analytics and Search Console in the WordPress dashboard. Without transients, WordPress would have to retrieve this information from each tool every time you viewed your Site Kit dashboard:<\/p>\n\n\n\n Instead, Site Kit includes transients that cache data from Analytics and Search Console. They are stored for one day (or one hour if the platform returns no data). <\/p>\n\n\n\n Every subsequent time you access your Site Kit dashboard, WordPress can quickly retrieve the stored information from your database instead of having to call the API again. When the expiration period runs out, the old data is deleted.<\/p>\n\n\n\n This means you don\u2019t have to wait for your results to load every time. This comes in handy in a variety of situations, such as showing social media share counts for your posts or displaying a newsfeed.<\/p>\n\n\n\n What gets you into trouble with Transients are the different, and hard to reproduce, behaviors you get when your plugin\/theme runs under different transients implementations. Different transients implementations means you will ONLY run into problems in certain configurations with certain types of sites, and never in others. <\/p>\n\n\n\n As a developer, if you\u2019re not aware of this pitfall and aren\u2019t coding accordingly, you\u2019ll think your code is sound, but in fact it will break in the field, and you won\u2019t even know how to reproduce it!<\/p>\n\n\n\n Transients are deleted from your database once they reach the end of their expiration period. For that reason, you only want to use them for information that is continuously re-created. <\/p>\n\n\n\n Additionally, although they can improve your project\u2019s performance, transients are best reserved for large queries and remote calls. If it will require more code to create a transient than it will to simply make a fresh request for the resource each time it\u2019s needed, you\u2019re better off going without.<\/p>\n\n\n\n If you want to easily see and manage the transients that are currently at work on your WordPress site, you can install the Transients Manager<\/a> plugin:<\/p>\n\n\n\n It provides a complete list of transients, which you can find by navigating to Tools > Transients<\/em>:<\/p>\n\n\n\n Here you can see all three transient elements we listed earlier \u2013 the key (name), value, and expiration period. You can edit any of these features by clicking on the Edit<\/em> link:<\/p>\n\n\n\n You can also delete transients individually or in bulk.<\/p>\n\n\n\n When it comes to coding your own transients, there are three basic operations you\u2019ll likely need to use. We\u2019ve outlined each of them below, continuing to use Site Kit as an example.<\/p>\n\n\n\n Creating or \u2018setting\u2019 transients is the process of defining the key, value, and expiration period, and applying that information to the relevant data. To do so, you\u2019ll use the following format:<\/p>\n\n\n\n Here is the code used in Google Site Kit to set the transient that stores analytics data:<\/p>\n\n\n\n The transient key is googlesitekit_analytics_has_data<\/em> (defined earlier in the code), the value is $has_data<\/em> or $has_data ?<\/em>, and the expiration period is one day or one hour (depending on the value).<\/p>\n\n\n\n Retrieving transients is a little more complicated. First, you need to use a function to request the necessary data. Then you\u2019ll check to see if it has a corresponding transient that should be loaded, instead of making a new API request.<\/p>\n\n\n\n The result might look something like this:<\/p>\n\n\n\n You\u2019ll then need to either return the transient, or delete the expired data and make a new call to the source. Finally, you have to set the transient after<\/em> you\u2019ve returned the new data, so it will be stored again until the expiration period runs out.<\/p>\n\n\n\n In Google Site Kit, that looks like this:<\/p>\n\n\n\n This code should then be followed by the snippet we included in the previous section for setting transients.<\/p>\n\n\n\n In some cases, you may find that you want to remove a transient. For instance, if you want to always see the most updated analytics in Google Site Kit, it would be better not to cache data (although we\u2019re not recommending that you actually delete Site Kit\u2019s transients). <\/p>\n\n\n\n Otherwise, the plugin will show the same results throughout the day, even if you\u2019ve had new visitors. Since the transient lasts for 24 hours, the data you view in the afternoon will simply be a cached version of the data you loaded in the morning. The easiest way to delete transients is by using the Transients Manager plugin. However, if you want to use code instead, you can put the delete_transient()<\/em> function to use. All you need is the transient key:<\/p>\n\n\n\n However, you\u2019ll have to repeat this for each transient you wish to delete.<\/p>\n\n\n\n Transient expiration periods can be expressed in a few different ways. The simplest two options are:<\/p>\n\n\n\n Alternatively, you can also set never-expiring transients. This can be useful in situations where you want to keep transient data the same, until you manually delete and reset the cached information.<\/p>\n\n\n\n Creating never-expiring transients is quite simple. Simply leave the expiration parameter in the set_transient<\/em> function blank, or identify it as zero.<\/p>\n\n\n\n The WordPress Transients API<\/a> is simply the means by which information is cached in your site\u2019s database. It enables all of the related operations we\u2019ve discussed throughout this post, including setting, getting, and deleting transients.<\/p>\n\n\n\n In other words, the Transients API is just the part of WordPress\u2019 core that lets you use transients. <\/p>\n\n\n\n Using memcached instead of WordPress Transients has two special benefits, which is why we automatically preconfigure it for you here at WP Engine. We\u2019ve got your back<\/p>\n\n\n\n i. Memcached is 10x-100x faster at storing and retrieving values than WordPress Transients, which is especially interesting since the point of transients is to cache data to increase the speed of a site.<\/p>\n\n\n\n ii. Memcached sets the maximum amount of space it will take up with data (e.g. 64MB of RAM), which means if a site stores too much data at once, it will automatically throw out old data, and therefore never runs out of space. But the built-in WordPress Transients will store an arbitrary amount of data in the options table.<\/p>\n\n\n\n Suppose you\u2019re reading and writing the same Transients key repeatedly, and suppose it\u2019s 1k of data. In that case, both Memcached and the WordPress Transients will do just what you expect them to, and both will take up about 1k of space (either in the options table or in memcached).<\/p>\n\n\n\n Now suppose you\u2019re reading and writing different Transients keys, different for each browser session. In short, what if you\u2019re storing user-session data in Transients? <\/p>\n\n\n\n This makes sense on the surface. Session data shouldn\u2019t last forever, and you don\u2019t want to bother with special database tables. Besides that, many hosting companies don\u2019t allow PHP sessions, so this really is the next best thing. It\u2019s even fast and multi-server.<\/p>\n\n\n\n Here\u2019s where the differences appear. With Memcached, and with a site with low traffic, this method appears to work. The values last for a while, then get deleted as they expire. <\/p>\n\n\n\n However, if the server is heavily loaded, the amount of session data the server needs to store will exceed the space available in memcached, and therefore you\u2019ll start losing session data sooner than you thought. <\/p>\n\n\n\n And if you didn\u2019t test in this exact, heavily loaded, environment, you\u2019d never know that. In general, these environments end up filling memcached so quickly that effectively memcached is disabled because it can never hold onto data long enough to be useful. You effectively don\u2019t have a Transient API cache at all!<\/p>\n\n\n\n But with the WordPress Transients, you get different but still very undesirable behavior. Because the values are written to the database, not a fixed-sized block of RAM, they all stick around. Which means even with the heavily-loaded site, you still have your session data. Awesome!<\/p>\n\n\n\n Or so you thought. Because what isn\u2019t said in the Transient API is what happens when you use unique keys like sessions. <\/p>\n\n\n\n With the built-in method, the options table fills up indefinitely! WordPress\u2019s \u201cold data clean up\u201d only operates when you request the key (as we covered earlier). If you just leave the key, it\u2019s left in the options table, forever. There\u2019s no separate process that cleans these up!<\/p>\n\n\n\n We\u2019re not only aware of this problem, we want to help out our customers who might be running code that doesn\u2019t understand this. That\u2019s where managed hosting for WordPress comes into play!<\/p>\n\n\n\n Every night, we have an automated process to look through your options table for expired transients, and delete them (both the data and the expiration date item). Boom! They\u2019re gone, and you don\u2019t have to worry about them.<\/p>\n\n\n\n So that\u2019s awesome that we do this, but as a developer of a general plugin or theme which is supposed to operate properly on any hosting environment, you can\u2019t do this in all the potential environments your plugin or theme might be deployed, and you want to make sure you\u2019re providing your users and customers with the most optimized code possible.<\/p>\n\n\n\n However, now that you know how Transients can go awry, it might be an awesome idea to take a look and see how you can make your code more efficient. <\/p>\n\n\n\n Chances are, if you\u2019ve read this far, you like optimizing your code, and this blog post may throw down the gauntlet for you and motivate you to re-write some things to be more scalable!<\/p>\n\n\n\n As a WordPress developer, providing your end users with access to remote data while maintaining fast performance is key. WordPress transients can help you accomplish just that.<\/p>\n\n\n\n However, it doesn\u2019t hurt to get a little extra help from lightning-fast hosting and professional developer resources<\/a>. Whether you\u2019re new to coding or a seasoned pro, we\u2019re ready to help. Check out our plans<\/a> today!<\/p>\n","protected":false},"excerpt":{"rendered":" As a WordPress developer, you probably already know how important performance is to a successful website. However, understanding transients in WordPress and how they\u2019ll help you optimize your projects can be a little tricky. Fortunately, when you break them down, transients aren\u2019t all that difficult to understand. As long as you keep a few key…<\/span><\/span><\/p>\n","protected":false},"author":1,"featured_media":146076,"template":"","resource-topic":[912],"resource-role":[895,896,897,899],"resource-type":[916],"class_list":["post-100657","resource","type-resource","status-publish","has-post-thumbnail","hentry"],"yoast_head":"\n\n
The benefits of using transients on your WordPress site<\/h2>\n\n\n\n
Drawbacks of using transients on your WordPress site<\/h2>\n\n\n\n
When to use WordPress transients<\/h2>\n\n\n\n
Managing WordPress transients<\/h2>\n\n\n\n
Basic operations used in transients<\/h2>\n\n\n\n
1. Setting transients<\/h3>\n\n\n\n
Set_transient (\u2018key\u2019, $value, expiration_period)<\/code><\/pre>\n\n\n\n\/\/ Cache \"data found\" status for one day, \"no data\" status for one hour.\n\t\t\tset_transient( $transient_key, (int) $has_data, $has_data ? DAY_IN_SECONDS : HOUR_IN_SECONDS );\n\t\t}\n\n\t\treturn (bool) $has_data;\n\t}\n}<\/code><\/pre>\n\n\n\n2. Retrieving transients<\/h3>\n\n\n\n
function some_function(){\n\t$transient = get_transient(\u2018key\u2019);<\/code><\/pre>\n\n\n\n\t\/**\n\t * Checks whether Analytics data exists for the given URL.\n\t *\n\t * @since 1.4.0\n\t *\n\t * @param string $url The url to check data for.\n\t * @return bool\n\t *\/\n\tprotected function has_data_for_url( $url ) {\n\t\tif ( ! $url ) {\n\t\t\treturn false;\n\t\t}\n\n $transient_key = 'googlesitekit_analytics_has_data_' . md5( $url );\n $has_data = get_transient( $transient_key );\n\n if ( false === $has_data ) {\n \/* @var Google_Service_AnalyticsReporting_Report[]|WP_Error $reports Array of reporting report instances. *\/\n $reports = $this->get_data(\n 'report',\n array(\n 'url' => $url,\n 'metrics' => array(\n array( 'expression' => 'ga:users' ),\n array( 'expression' => 'ga:sessions' ),\n ),\n )\n );\n\n if ( is_wp_error( $reports ) ) {\n $reports = array(); \/\/ Bypass data check and cache.\n }\n\n foreach ( $reports as $report ) {\n \/* @var Google_Service_AnalyticsReporting_Report $report Report instance. *\/\n $report_data = $report->getData();\n \/* @var Google_Service_AnalyticsReporting_ReportData $report_data Report data instance. *\/\n foreach ( $report_data->getTotals() as $date_range_values ) {\n \/* @var Google_Service_AnalyticsReporting_DateRangeValues $date_range_values Values instance. *\/\n if (\n isset( $date_range_values[0], $date_range_values[1] )\n && ( 0 < $date_range_values[0] || 0 < $date_range_values[1] )\n ) {\n $has_data = true;\n break 2;\n }\n }\n }<\/code><\/pre>\n\n\n\n3. Deleting transients<\/h3>\n\n\n\n
<\/p>\n\n\n\ndelete_transient(\u2018key\u2019);<\/code><\/pre>\n\n\n\nTransient expiration: How does it work?<\/h2>\n\n\n\n
\n
Understanding the WordPress Transients API<\/h2>\n\n\n\n
The two most common implementations of the Transients API backend:<\/h3>\n\n\n\n
\n
Applying transients in your development<\/h2>\n\n\n\n
Do more with your WordPress site<\/h2>\n\n\n\n