Is there a way to ensure local fonts load from CDN when CDN is enabled?

Question

I've set up a WordPress site with one local font. It is stored in the a fonts folder in the child theme. It is loaded with the following in the child theme style.css

@font-face {
    font-family: 'Last Paradise';
    src: url('fonts/LastParadise.eot');
    src: url('fonts/LastParadise.eot?#iefix') format('embedded-opentype'),
        url('fonts/LastParadise.woff2') format('woff2'),
        url('fonts/LastParadise.woff') format('woff'),
        url('fonts/LastParadise.ttf') format('truetype'),
        url('fonts/LastParadise.svg#LastParadise') format('svg');
    font-weight: normal;
    font-style: normal;
}

The site has a CDN, which is currently activated by the bunny.net CDN plug-in. Although I've tried various other options, such as the CDN Enabler plug-in from KeyCDN, and also via the CDN options that are in various caching plug-ins I've tested.

In all cases, the above-mentioned font does not load from the CDN. It is called from the website URI.

I notice that there are a couple of other fonts that are loaded by plug-ins, and these also loading from the site URI not the CDN URI.

Questions

1. Is there a specific way to import/enqueue/reference a local font such that its URI will be picked up by a CDN plug-in, and thus converted to using the CDN URI when CDN is enabled? (I realise I could put in the full CDN based URI in the above @font-face CSS, but I'd like to know if there's a way to reference the font locally, such that when CDN is enabled then its URI will be converted to CDN URI.

2. Is there a way to over-ride (like to de-enqueue and then re-enqueue) fonts that are being loaded by plug-ins? Such that I could force it to load from the CDN URI (by using the full CDN based URI when re-referencing it?)

Answer 1

I will post my findings here as they will likely be useful to anyone else facing a similar situation.

I had considered whether the issue was with the CDN redirection implemented on the site (a plug-in). But the fact that every (3 of the most popular) CDN plug-ins I tried, and every cache plug-in with CDN settings (3 widely used cache plug-ins), had the same result suggested to me that was not the source of the issue.

After looking more extensively into this situation, what I have found is that this issue was caused by the Aggregate CSS-files feature of the popular Autoptimize plug-in.

I found that Autoptimize provides a way around this. It is explained in the FAQ here.

To me, this discovery makes an important point, which is worth noting. Anyone else finding that their CDN implementation is mostly working, but some font (or perhaps some other assets) are not loading via their chosen CDN redirection method (such as any of the popular CDN enabling plug-ins) should first consider that the issue is likely caused by a conflict with another plug-in. If you are using the somewhat popular Autoptimise plug-in, or any other optimisation plug-in that aggregates CSS files, that should be one of the first things troubleshoot.

In direct answer to the two questions:

1. All popular CDN redirection plug-ins should have no issue redirecting the URI for fonts loaded via @font-face { ... } in the CSS from the theme assets and from plug-in assets. If they appear to be having such an issue, it is most likely another plug-in that's at fault (as noted above).
2. In WordPress there is no dequeue then (re)enqueue equivalent for @font-face declarations. You would have to dequeue the entire CSS file in question, and enqueue a modified version of it (with the hard-coded CDN URIs). Not useful, and not advisable.

Over-riding @font-face declarations

Should the need arise (not the case in this instance, now that it's clear another plug-in was the cause of the issue) to over-ride an @font-face { ... } declaration in the CSS files of any plug-in, etc., you can do so by declaring that same @font-face { ... } yourself. You can then hard-code in the font file sources to what you need them to be. I tested this by declaring a number of @font-face { ... } statements via the popular Code Snippets plug-in. Doing this effectively changed the source locations of the font faces in question. One scenario this could come in handy is if you want to locally source a font that a plug-in is pulling in from a remote source.