Solving the caching issue

After a large amount of abortive searching into how to fix the httpd config to deal with caching / rewriting headers for query strings in Directory blocks, along these lines:

<Directory "/var/www/html">  
    <FilesMatch "\.(css|js|pdf)$">
        RewriteEngine on
        RewriteCond %{QUERY_STRING} /ver=\d{1}\.\d{1}\.\d{1}/
        Header set Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=2592000, stale-while-revalidate=86400, stale-if-error=604800"

and finding this not quite enough to get over the line, I found this blog post which solves the caching with constant strings problem in WordPress in a slightly different way. In particular, it suggests installing the Code Snippets plugin and activating this snippet on the front end to rewrite query strings

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
add_action('init', 'remove_query_strings');

I did this and it works locally when I load the page in Chrome.

However, so far this doesn’t seem to have been picked up by which is still indicating 1) that there are various query string urls on the site and 2) that these query string urls are not cached, but I figure there is some form of caching going on elsewhere (Cloudflare, I would posit) that should sort itself out in an hour or two (Cloudflare CDN free has a TTL of 2 hours I believe). Certainly as mentioned in Chrome locally query strings are no longer present when I examine the page load in the network tab … anyway maybe this is a “walk away for a bit and see if things are fixed later” kind of deal.

Alternatively, if this doesn’t really fix the problem, I might have another go at wrangling the httpd.conf change above into shape. It is probably almost there — maybe I need to explicitly load mod_headers and/or modify the regex slightly? Perhaps the regex is not in httpd compliant form? Maybe I also need to pair it with a RewriteRule, even if I don’t want to modify the url and just have an identity operation therein? And, if I did all of this, how to deal with 3rd party urls for css and/or js? Can I use a php cache instead (WPFC_CACHE_QUERYSTRING) even though not as performant as httpd? Actually, I might do that anyway. Actually ha! no, that is in regards to a different plugin, WP Fastest Cache.

Okay, so I went to Cloudflare and performed a custom purge on the assets identified as slow with query strings … time to wait 30 seconds and then rerun the check! Yes, that fixed it.

However, “Eliminate render-blocking resources”, uh … how to fix that? This blog post suggests a couple of plugins, either Async Javascript or Autoptimise. The latter has 1+ million installs so I guess that is good adoption.

I also identified that styles.css and woocommerce-blocks.css are not necessary, maybe I can dequeue those in a snippet?

Okay, progress. Maybe I can also use this snippet for jQuery, here. That doesn’t seem to work out of the box, maybe I need recaptcha? No, I’ll just skip the check for the Autoptimize setting I think and just use the jQuery function. Nope, that doesn’t work either! Maybe purge cloudflare cache for jquery again?

Time to check out Async JS I think … no, that didn’t work either.

I might just eliminate the exception for jQuery.min.js from the list of options in Autoptimize. Yep, that fixed it, but at the expense of a console error. Maybe this approach? That doesn’t appear to work. Maybe this approach instead?

Now, I can further improve performance by downloading the google font using this and self hosting, this should shave another 800ms off page load; significant! And I can try to decrease the size of any images loaded on the page, too; this should speed up the time to first contentful paint.

I’m still not cracking 90 though on PageSpeed or in terms of performance – still a measly 87. Hopefully though once I’ve addressed the above items I will be in the green.

The “web server initial response time” metric is red, but there is not much I can do about that, short of upgrading from a skateboard to a bicycle. Maybe that can be a next year thing, i.e. for the 2023 calendar campaign cycle. But not this time around; there are plenty of lower hanging fruit to pluck as yet, and actioning those should be sufficient in order to obtain adequate performance.

After all of this, I should probably look into other ways I can improve the soap site’s first contentful paint, which is sitting at a snail’s pace of 5.5 seconds on 3G at present; way too high. Apparently 1.8 seconds or less is the gold standard here.

In the back of my mind too I’m wondering as to how much of this configuration can be automated if and/or when I want to roll a new server (more likely, servers – with db replication and synchronisation) in the t4g family. As much as possible should sit in my terraform infrastructure repo, including the code snippets. I’d probably want to do a mysql dump before decommissioning the old server, so that I can keep all the old settings information for the associated plugins. There must be a way that folks have documented regarding process in that respect … maybe here? In particular I’d ideally probably want to dump the DB to my local machine using DBeaver to make sure I have a proper backup. I’ll create a card in the backlog to figure out how to action that.

Tags: ,

One Response to “Solving the caching issue”

  1. Hosted Google Fonts on Soap Site | Where's my hat?! Says:

    […] reactivating Datadog RUM and see if there is any performance degradation now that I’ve performed other mitigations for async […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: