Benchmarks Optimizing and tuning WordPress and XenForo with NewRelic

Oh, I should have clicked that arrow...

Sure enough, the "x-cache-handler: cache-enabler-engine" response header inserted by Cache Enabler is NOT listed in the KeyCDN tool. The header shows as expected when I view the site in an Incognito browser window, and other third-party response header tools like https://httpstatus.io/ also show the header. I wonder what the KeyCDN tool is doing?

I'm using Polish but not with WebP. I did when I first switched to Cloudflare a few years ago, but some of my users and writers complained about WebP breaking their ability to save and edit images. A lot of users use my forums to swap and share images that they want to edit/collaborate on. They didn't understand what WebP was or what was actually going on; I was busy with other things and just disabled it at the time to save everyone the hassle.

Now I see that I can enable it or disable Polish based on Page Rules. If I enable WebP and then set a Page Rule to disable Polish on forum attachments and image proxy images, that might work. Of course then I will lose Polish (non-WebP) compression on forum images, so... I don't know. I wish there was a way to just enable/disable only WebP conversion with Page Rules. Or maybe I should just do it anyway and drag all my users into the future kicking and screaming.

I didn't have much time to work on this today, but as of now my plan of attack looks like this:

1. Use your optimise-images.sh on all the files in my /wp-content/uploads folder.
2. Install/configure either EWWW or another image compression tool to compress uploads automatically in the future.
3. Configure CloudFlare to do WebP conversion and delivery.

 

I figured out why KeyCDN's TTFB Performance Tester (and other TTFB tools) were bypassing Cache Enabler.

Those tools send "HEAD" requests instead of "GET" requests. I noticed this after closer inspection of the server request logs.

HTTP/1.1: Method Definitions

Cache Enabler's custom nginx rules use 405 errors and a @fallback "named location" which effectively bypasses the cached file for any request that is not a GET:

Code (Text):

location / {
        error_page 405 = @fallback;
        recursive_error_pages on;

        # check request method
        if ( $request_method != GET ) {
            return 405;
        }
...
}

I think it might be worth it to modify the nginx configuration so that it does cache HEAD requests. It is somewhat ironic that the benefits of KeyCDN's own speed plugin are not visible with their own testing tool because of this!

 

Ha, yep, that explains it. Another reminder to always do things "the Centminmod way".

 

A very interesting update this time.

While checking my Crawl Stats in my Google Search Console (go to Settings -> Crawl Stats) I discovered that millions of XenForo search results pages (/forum/search/*) were being crawled by Google every single day. I could not believe it because I thought robots.txt would prevent that... but when I checked it, I realized I had not updated my robots.txt since 2015!

That was before I upgraded to XF2.x, and unfortunately I have had an outdated robots.txt file for six and a half years. I know the importance of robots.txt but just always thought "oh yeah, I have that taken care of". The fact it took me so long to discover this is embarrassing, but I digress.

This is the contents of my new file, inspired by the defaults on XenForo.com:

Code (Text):

# BAD BOTS
User-agent: PetalBot
User-agent: AspiegelBot
User-agent: AhrefsBot
User-agent: SemrushBot
User-agent: DotBot
User-agent: MauiBot
User-agent: MJ12bot
Disallow: /

# AMAZON BOT
User-agent: Amazonbot
Disallow: /forum/threads/*/reply

# ALL BOTS
User-agent: *
Disallow: /wp-admin/
Disallow: /forum/whats-new/
Disallow: /forum/account/
Disallow: /forum/attachments/
Disallow: /forum/goto/
Disallow: /forum/posts/
Disallow: /forum/login/
Disallow: /forum/search/
Disallow: /forum/admin.php
Allow: /

I implemented the necessary changes and submitted the update to Google. To Google's credit the bot picked up the changes and changed its behavior almost immediately.

This had absolutely destroyed my crawl budget, so it was interesting to watch as suddenly Google started crawling a lot more of my legitimate content, most of it older.

It is still too early for these changes to show up in the Google Search Console reports, but my other reports saw drastic changes. At the same time, I noticed that there were still a lot of requests coming from AhrefsBot and SemrushBot. I blocked them with Cloudflare Firewall rules.

Most of the worthless requests were going to XenForo, so it saw the biggest change in request volume in NewRelic. The changes were implemented late afternoon on Jan. 11, 2022.

You can see request volume drop:



With fewer requests, this of course makes XF look a bit slower! But that's expected and these numbers are more accurate:



Cloudflare Analytics were also quite interesting. "Page views" and "visits" both collapsed, but bandwidth and requests remained largely the same, as you can see here:




Cache performance also looks so much better, as the origin is not having to serve so many crap requests.

 

Oh yes, I almost forgot... it's custom Cloudflare Worker time.

I have finally implemented a custom CF Worker to cache just my WordPress pages. It took some tweaking, but the results have been incredible!

Because my WordPress install is at root and my articles are not in any subdirectory, this creates a possible problem as the Worker will be running on all requests to the domain not serviced by other Workers. So, I thought it would be wise to set up a bunch of null Worker routes on my domain so the Worker isn't inspecting a lot of requests it will never need to cache. (A null route is just setting a path for a Worker and then just choosing "None" for the service. As far as I know, this is the only way to achieve this.)

I set up null routes for a few custom directories I use on my site in addition to WP directories. There are also a ton of requests to files like the favicon and Apple touch icons, so I included those as well.

Code (Text):

/wp-content/*
/wp-includes/*
/wp-admin/*
/favicon*
/apple*
/forum/*

For the other requests, I still had concerns about my Worker caching things that it should not. So, I decided to define custom HTTP headers in my theme's functions.php file which will only be inserted on the types of pages I want to be cached. There may be a better way to accomplish this functionality but it seemed like the most reliable and straightforward to me.

Functions.php code:

PHP:

/**
 * Function to include the MyCF-Cache HTTP header that will be used to signal
 * which pages to cache for the custom Cloudflare Worker.
 *
 * Here is why we use the 'template_redirect' hook:
 * https://wordpress.stackexchange.com/a/258899/160222
 */
add_action( 'template_redirect', 'send_mycf_header' );
function send_mycf_header() {
    // If this is a page type we want to cache, return the header
    if ( is_home() OR is_category() OR is_tag() OR is_author() OR ( is_single() && 'post' == get_post_type() ) ) {
        header( 'MYCF-Cache: true' );
    }
}

I discovered this header is not included if the page is returned by Cache Enabler, because of course it never touches PHP and the file is served directly by Nginx. However, those responses include a "x-cache-handler" header.

So, in my Worker, I check for the presence of either of those headers before determining if the request should be cached. Here is the Worker with some descriptive comments for anyone curious about how it works. It also includes a lot of "console.log" statements to make testing and debugging easier using Wrangler's tail command.

Code:

addEventListener('fetch', event => {
  // We add "passThroughOnException()" here in case
  // there is an error. This line means it will automatically
  // pass the request through to the origin transparently
  // in case something goes wrong in the Worker.
  event.passThroughOnException()
  event.respondWith(handleRequest(event))
})

async function handleRequest(event) {
  const request = event.request
  const { city, region, country, colo } = request.cf
  const ip = request.headers.get("CF-Connecting-IP")
  console.log(`Request from ${ip} (${city}, ${region}, ${country})`)

  /**
   * If the request contains wp or xf cookies, bypass the cache
   * and fetch from the origin.
   */
  if (request.headers.get("Cookie")) {
    const cookies = request.headers.get("Cookie")
    const has_target_cookies = Boolean(
      cookies.includes('xf_user') ||
      cookies.includes('wordpress_logged_in') ||
      cookies.includes('wp-postpass') ||
      cookies.includes('woocommerce_')
    );
 
    if (has_target_cookies) {
      console.log(`CACHE BYPASSED: target cookies detected`)
      return fetch(request)
    }
  }
 
  /**
   * Check to see if this page is already in the cache. If not, we need
   * to fetch it from the origin and (maybe) store it into the cache.
   *
   * The cacheKey will be constructed from the URL and will only contain
   * the origin and and pathname. If we do not do this, the full URL, including
   * any query parameters, will be cached. This will break caching for any links
   * with utm_ tags, social media tools, or clicks via Facebook.
   *
   * https://developers.cloudflare.com/workers/examples/cache-api
   */
  const cache = caches.default    // use the "default" cache
  const url = new URL(request.url)
  const cacheKey = url.origin + url.pathname

  let response = await cache.match(cacheKey)

  if (!response) {
    // If no response from the cache, we will fetch it from the origin
    response = await fetch(request)

    // Do not cache an unsuccessful (non-200) response
    if (response.status != 200) {
      console.log(`CACHE BYPASS: ${response.status} response code, will not be cached`)
      return response
    }

    // Check custom headers
    const myCacheHeader = response.headers.get('mycf-cache')
    const cacheEnablerHeader = response.headers.get('x-cache-handler')

    if (myCacheHeader || cacheEnablerHeader) {
      console.log(`CACHE MISS: Storing into ${colo} edge cache`)

      // We will be storing this response in the cache. We must create a copy and
      // add our own Cache-Control headers to store it in cache
      // for seven days (604800 seconds).
      response = new Response(response.body, response)
      response.headers.append("Cache-Control", "s-maxage=604800")

      // Store the fetched response into the cache. We use "waitUntil" here to return
      // the response without having to wait for the cache write to complete.
      event.waitUntil(cache.put(cacheKey, response.clone()))
    } else {
      console.log(`CACHE BYPASS: No custom headers detected, not something we want to cache`)
    }
  } else {
    console.log(`CACHE HIT: Serving from ${colo} edge cache`)
  }

  return response
}

This was paired with the Cloudflare WordPress plugin with APO disabled to clear the cache as necessary on post publication.

The results speak for themselves. Here is the KeyCDN TTFB Performance Tester results.

No worker (Cache Enabler only):


With CF Worker after cache primed at all edge locations:


If we compare these numbers to where I was on my old server in November, we can see that for a user in London, that is a 90% faster TTFB and for a user in Sydney, that's a 94% faster TTFB!

The Worker was implemented on January 12, 2022, so there is just a few days worth of data, but we can already see a change in Google Analytics server response times:



And for some more perspective, let's take that chart back out to October 1...



This is a major improvement so I am hopeful this will have at least some impact on my Google rankings. I will be keeping a close eye on my Search Console data over the coming weeks and months.

 

That would definitely be the easiest solution, but cost becomes an issue if a Worker is handling all those requests.

Right now my Workers in total (I have other Workers doing things) serve around 150k requests/day, or 4.5 million/month. The threshold is 10 million/month included in my CF Paid plan so they don't cost me anything. Without using null routes, all 3.5+ million/requests a day would be getting processed by Workers and it would be around $70+ extra per month!

 

Another quick optimization win...

For some time now I have been battling with WordPress plugins that include a lot of extra JS and CSS files. I am a fairly proficient WordPress developer — I built my site's own theme from scratch and created custom plugins — but wrestling with these stupid files was always a challenge.

Today, though, I finally figured out the problem was the official Braintree (payment processor) WooCommerce plugin. It was forcing the entire Jquery library to load along with some other Jquery-related plugins and CSS on every WordPress page, though it wasn't obvious that was the plugin causing the issues. It was only when I started looking at the differences in files included on the page between my local development site and my public production site that I started to get suspicious of it.

Anyway, I switched over to the official WooCommerce Stripe plugin, which is apparently much more well-built, and the extra files have finally been removed without the need for any ugly hacks on my part.

The result is a 35% reduction in average JS file download size on WordPress pages, from 114KB to 73KB. According to my Cloudflare Analytics report, this will save me and my visitors over 650MB of bandwidth per day, or nearly 20GB per month!

 

Yes, extremely tricky!

I thought jQuery was being included by a "quiz" plugin that we use to make quiz-type articles on our site which are pretty popular sometimes. I thought that plugin was the one that needed jQuery, and I thought it was too poorly-coded to only insert the library on posts/pages that actually had quizzes on them, so I had kind of given up on removing the library. I actually was looking into using Cloudflare Workers' HTMLRewriter to see if I could remove the library conditionally depending on whether or not the page included a quiz on it! Fortunately I found the real culprit.

There is SO MUCH performance to be pulled out of WordPress, and there are SO MANY bad plugins out there.

That's one reason I like NewRelic so much. It makes it easier to see where the problems are coming from.

 

A few graphs from Cloudflare Analytics...

As a reminder, the Cloudflare Worker which caches WordPress pages was implemented on January 11, 2022.

Here we can see how it affected the median page load metrics for the entire site:



Now we filter this to just include WordPress pages... Look at the instant drop in "Request" time. We can also exclude traffic from the United States, where the server is actually hosted in Ashburn, VA, to make the improvement really stand out!



And finally, for fun, let's look at how much things have improved for visitors on the other side of the world in Australia...



How awesome is that?

Even inside the United States, though, we can still see a real improvement in speeds for visitors due to the number of POPs Cloudflare has in U.S. cities:

 

Still going.

For the past two weeks, I have had the Image Optimizer for XF 2.x plugin optimizing my forum's 2.1 million attachments and proxied images in the background. (I actually added a secondary cron job for it so it would run every minute instead of the default five so it wouldn't take 8 months to complete... )



This is pretty crazy. Due to the age of my forum (21 years) and the fact that many of these images had never been optimized beyond XenForo's (or vBulletin's... or Ikonboard's...!) modifications, I think these results were especially dramatic. I will actually be able to downgrade my server backup plan because of this plugin and save a good bit of money. I could even go a step further and ditch the secondary HDD which stores my attachments/image proxy and put everything on the 1TB NVMe drive... but I'll have to think about that a bit more.

Looking at some of the images, a few of the default settings might have been slightly too aggressive. I am now using 70-90 for PNGQuant compression range and 1 for PNGQuant speed. I've also increased the JPEG optimization level to 86. However, the vast majority of the optimized images were over a year old and will rarely be viewed. So I think it's a good compromise. Needless to say, I highly recommend this plugin for anyone on XF2.

I was waiting for this process to complete before enabling Cloudflare's WebP compression. Now that it has finished and the option is enabled, I did a full CF cache purge for my site and ventured out to see just what kind of real-world improvement this brought.

My forum hosts some huge gallery threads and users stuff them with high-resolution images, so we have some pages that are ridiculously large.

I checked specific pages in some of these threads and looked at page size in Chrome Developer Tools three times: before optimization, after plugin optimization, and finally after enabling CF WebP compression. This allows us to see just how much was gained from each step.

Thread 1

• Original size: 68.3 MB
• Plugin optimized: 26.7 MB
• WebP enabled: 20.8 MB (-70% smaller)
• Total savings: 47.5 MB

Thread 2

• Original size: 73.5 MB
• Plugin optimized: 43.8 MB
• WebP enabled: 35 MB (-52% smaller)
• Total savings: 38.5 MB

Thread 3

• Original size: 151 MB
• Plugin optimized: 58.8 MB
• WebP enabled: 48.4 MB (-68% smaller)
• Total savings: 102.6 MB

These improvements should be especially noticeable for mobile users on capped plans and those on slower internet connections.