Optimize Your WordPress Plugins with Tags

One of the core strengths of WordPress is the availability of many free plugins that allow you to easily and cheaply extend what your blog can do. However, the price paid for these plugins is in the additional overhead they place on your blog.

A high page load time will adversely affect your blog traffic and negatively impact your Google page rank.

One of the simplest ways to enhance page speed is to use a caching plugin with your WordPress blog.

It is also important to cache your WordPress gravatar images because constantly hitting the gravatar.com site can also result in significant page delays.

Another culprit of slow page load time is the_content filter.

the_content filter and page speed

Some plugins add in filters that process the entire content of your posts, frequently multiple times, before it is displayed. These operations can be very costly, and will greatly increase your page load time.

The two filters to look at first are the_content and the_excerpt.

the_content filter usually gets called when the full text of a post is shown. Depending on your WordPress theme, this may sometimes occur for each post shown on your blog front-page.

If you are running a plugin that has a costly the_content filter, your front-page load time will increase significantly. This comes from running the_content filters through multiple posts (default is 10) every time someone visits your WordPress blog.

Some WordPress themes show post excerpts instead of the entire post content on the front page. When this occurs, the_excerpt filter gets called and applied to each and every post.

If your posts do not have excerpts, one will be automatically generated from your post content. When this occurs, the_content filter gets applied to your entire post content before it gets shortened into excerpt form.

Therefore, the cost incurred will be the same as if you had displayed the full contents of each post.

Only execute the_content filter when necessary

One simple way to increase your page speed is to only execute costly the_content or the_excerpt filters on the posts that need it.

For example, the WP-Syntax plugin is good at formatting code segments within a post, but this operation can end up being quite time intensive.

Furthermore, the plugin executes on both the_content and the_excerpt filters, which greatly increased load time for all my pages especially my blog articles page.

At one time, it took an average of about 10 seconds for my blog articles page to get generated.

A simple fix is to only run the WP-Syntax filters on posts that actually have code segments.

// add to theme functions.php file
function remove_plugin_filters() {
	remove_filter('the_content', 'wp_syntax_before_filter',0);
	remove_filter('the_excerpt', 'wp_syntax_before_filter',0);
	remove_filter('comment_text', 'wp_syntax_before_filter',0);
	remove_filter('the_content', 'wp_syntax_after_filter',99);
	remove_filter('the_excerpt', 'wp_syntax_after_filter',99);
	remove_filter('comment_text', 'wp_syntax_after_filter',99);

function my_template_redirect() {
	global $wp_query;
	if (!is_singular() || !$wp_query->post) {

        // for single posts or pages
	if (!is_single('4878')) {
add_action('template_redirect', 'my_template_redirect');

The remove_plugin_filters function removes all of the WP-Syntax filters.

The my_template_redirect function decides when to remove plugin filters based on post attributes.
Lines 16-19 – Remove WP-Syntax filters when there are multiple posts (e.g. category pages, tag pages, or blog front-page) or no posts. I can do this because I am using excerpts when showing multiple posts, and none of my excerpts contain code segments.

Lines 21-24 – Remove WP-Syntax filters for all single posts that do not contain any code segments. This post, for example, contains code segments so I *do* want WP-Syntax filters to be applied. Many of my other posts however, do not have any code in them, thus there is no need to run the code layout filters through their content repeatedly.

Instead, we just do a quick post ID check.

Removing the_content filters by tag

The process above, however, requires that you update your theme functions.php file every time you add a post that uses the WP-Syntax plugin. This can quickly become tedious.

What we want is to specify WP-Syntax usage from within the WordPress dashboard.

A simple way to achieve this is through the use of tags. Instead of identifying which posts to filter or not to filter by using their ID, we can use their related tags.

function my_template_redirect() {
	global $wp_query;
	if (!is_singular() || !$wp_query->post) {
	$post = $wp_query->post;
	$wp_syntax = FALSE;
	if ($post->post_type == 'post') :
		$tags = wp_get_object_terms($post->ID, 'post_tag');
		foreach ($tags as $tag) {
			if ($tag->name == "wp-syntax") {
				$wp_syntax = TRUE;

	if (!$wp_syntax) {

Line 12 – Get all the tags from the current post.
Lines 13-18 – Look for the tag wp-syntax. If a post contains the wp-syntax tag, we run it through the code filters, if not, we remove the WP-Syntax code filters.

In this way, we can selectively enable WP-Syntax plugin processing by adding the wp-syntax tag to our posts.

Drum-roll – And the increased page speed goes to …

After optimizing my plugins using the process described above, my blog articles page now generates in about 1 second compared to the previous 10 seconds.

Most of my other pages are also loading a lot faster, although the time savings are not as dramatic as the articles pages.

Hope this helps to save you some time 😉

Related Articles


  1. says

    I have a question. I am back to building websites. I am creating a functionality plugin like I used to have in the past. You example above seems to only be useful if you are using WP Syntax Plugin.

    This would be unnecessary if you weren’t using the plugin, right?

    • ShibaShake says

      More generally, this article is about how we can pick and choose how we apply plugin functionality to only certain groups of posts/pages through the use of tags.

Leave a Reply

Your email address will not be published.