APO on sub-directory and testing if it works

Hi,

1- Can you please let me know if I wish to use APO on a sub-directories not sub-domains of my main domain as well as the main domain, do I install the plugin on each sub-directory? If so, do I enter the API token on each plugin settings on sub-directories or the Global API Key?

2- I don’t see any APO appearing when viewing page source. How can I test if APO is working or not?

  1. I’ve not tried this, but theoretically this would work. APO will keep track of the URLs it needs to purge, so it won’t purge the other subdirectory. Because they’re the same zone, you’d use the same Token for both/all sites. @yevgen is the expert in this area.
  2. You won’t see APO in Page Source. It shows in the Response Headers you can see from a browser’s Dev Tools (F12 in Chrome). Or from Waterfall View in GTMetrix or WebPageTest.
  1. You need to install plugin on all sud-directories where you plan to run APO. Plugin installation will make sure to auto purge cache on content change for each subdirectory. You can use API token as it will be used on the main domain (Global API Key will work as well). Once APO is activated it will take over caching the whole domain example.com/*. In order to limit caching to only subdirectories where WordPress is running you need to disable APO caching. There 2 ways of doing it:
  • serve response header cf-edge-cache: no-cache on all non WordPress parts of the site, it will instruct APO service to bypass caching for those urls. This is recommended approach.
  • configure Page Rules to exclude non WordPress parts of the site from caching: with “Cache Level: Bypass”. Please not it will disable all caching including static assets for those paths. That’s why for your configuration it’s better to disable APO via response header.
  1. I will refer to APO’s FAQ.
1 Like

For a moment, this confused me. So…you need to disable unintented caching on those other parts of your domain. Not APO itself. Hence, adding headers and Page Rules to those other parts of your domain.

I suspect it’s the entire zone, so all subdomains as well?

One thing I don’t recall or haven’t seen: Does APO ever do a “Purge Everything”? (purge all cache in that zone…all subdomains, all directories, etc.).

For a moment, this confused me. So…you need to disable unintented caching on those other parts of your domain. Not APO itself. Hence, adding headers and Page Rules to those other parts of your domain.

Yes, unintended caching for non WordPress parts of the site is the main issue with subdirectories setup.

I suspect it’s the entire zone, so all subdomains as well?

Nope, APO is activated per domain, it will require separate plugin installation on a subdomain to work.

One thing I don’t recall or haven’t seen: Does APO ever do a “Purge Everything”? (purge all cache in that zone…all subdomains, all directories, etc.).

Yes it does, on theme change it will call Purge everything. Purging by hostname is only available for Biz and Ent plans, that’s why we do purge everything instead of purge by hostname (e.g. only on subdomain).

1 Like

This is an example of serving response header for non WordPress parts of the site via Cloudflare Worker, so origin could stay untouched:

addEventListener("fetch", (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  /**
   * Response properties are immutable. To change them, construct a new
   * Response object. Response headers can be modified through the headers `set` method.
   */
  const originalResponse = await fetch(request)

  let response = new Response(originalResponse.body, originalResponse);

  // Add a header using set method
  response.headers.set("cf-edge-cache", "no-cache")

  return response
}
1 Like

Why not do the reverse ? tell CF Wordpress plugin to only cache when cf-edge-cache: cacheable header or similar exists and if it doesn’t exist, do not cache. This way you can code CF Wordpress plugin to directly control caching Wordpress url paths and any non-Wordpress site requests with missing cf-edge-cache: cacheable header would not be cached in APO cache. Then there would be no extra work for CF customer.

Or the header could include the url pathname as a criteria for caching. That’s how I have my CF Worker cache done right now it’s on a per url pathname or extension basis to control if CF CDN should cache it and for how long to cache the specific pathname/extension.

1 Like

I figured that was the default. No header? No cache. Because without the plugin, there’s no header, and that seems to be what Cloudflare is looking for in the first place to activate APO.

That makes sense. It isn’t at the moment because we wasn’t migrated all existing customers who use APO but didn’t install/setup WP plugin initially (we deprecated this mode last year). Once we reach out to those small percentage of existing customer we will be able to make no header equal to no-cache.

2 Likes

When APO was announced we allowed running APO without plugin installed, so lack of cf-edge-cache response header is a valid usecase. We need to migrate some customers (ask them to install plugin) before we can make the change.

1 Like

I see that would be problematic for those that enabled APO without the Cloudflare Wordpress plugin.

1 Like

Thank you both for your replies.

I have managed to check if APO is working and it is.

The difference in speed and TTFB is totally amazing.

2 Likes