Getting APO working with siteground

[james.s]

As some further info on my previous post [Confirming APO active]

if i run the CURL command CF suggested

*curl -X GET "api.cloudflare.com/client/v4/user/tokens/verify" \*
*     -H "Authorization: Bearer <--API token-->" \*

then i get the response posted above. but if i just run

*curl -IX GET <--mydomain-->*

then i get the following. which implies cf-edge-cache is working right?

*Date: Sat, 15 Jul 2023 11:48:35 GMT*
*Content-Type: text/html; charset=UTF-8*
*Transfer-Encoding: chunked*
*Connection: keep-alive*
*CF-Ray: 7e71c6f6cd5f447a-EWR*
*CF-Cache-Status: HIT*
*Cache-Control: max-age=14400*
*Last-Modified: Sat, 15 Jul 2023 11:47:26 GMT*
*Strict-Transport-Security: max-age=31536000; preload*
*Vary: Accept-Encoding*
*cf-apo-via: tcache*
*cf-edge-cache: cache,platform=wordpress*
*host-header: 6b7412fb82ca5edfd0917e3957f05d89*
*x-content-type-options: nosniff*
*x-httpd: 1*
*x-proxy-cache: MISS*
*x-proxy-cache-info: 0 NC:000000 UP:SKIP_CACHE_SET_COOKIE*
*x-xss-protection: 1; mode=block*
*Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=bWOL%2B%2FHBDAPEwlyaf6bkwImUaejbI0HR5ruLTUSzZXsOPSUR1id28JfI38Q%2Bu%2BwCfTIvOzAoZuR%2Bvg10Jta1Pll84Mzz7O6nIjbV5T1EYqCPWGwGjatQclf3WnaO15%2B7Gq05DvEj"}],"group":"cf-nel","max_age":604800}*
*NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}*
*Server: cloudflare*
*Content-Encoding: gzip*
*alt-svc: h3=":443"; ma=86400*

on the cloudflare plugin on wordpress at least it no longer has the error. as far as i can tell the only real change was disabling a CF page rule to cache everything. which seems counterintuitive. perhaps if you have any insights to both validate my outcome and asssist others running the same configuration hurdles. greatly appreciated.

[Laudian]

@james.s

the only real change was disabling a CF page rule to cache everything. which seems counterintuitive

You should either use the plugin or page/cache rules for cache configuration. If you use both, they will very likely conflict.

But “cache everything” is a bad idea anyway.

[cbrandt]

@james.s

which implies cf-edge-cache is working right?

Right. The cf-edge-cache header is sent from the Cloudflare Plugin, regardless of APO activation. It signals the plugin is properly installed. The cf-apo-via will return whether the content was fetched from cache or from the origin, and why. For instance, cf-apo-via: origin, qs, signals that the content was fetched from the origin due of the presence of a query string in the URL.

@james.s

disabling a CF page rule to cache everything. which seems counterintuitive

APO is a general tool, applied to the whole domain/subdomain where it’s enabled. Page Rules or Cache Rules should be used mostly to create exceptions that APO might not ordinarily cover, in response to a specific user’s needs.

As for the title of your topic, Siteground Optimizer should work in tandem with APO, as long the plugin purges its cache in tandem with Cloudflare’s when changes are made. Otherwise, as @Laudian has said, they might conflict.

Many caching and optimization plugins will make an API call to purge the relevant pages from Cloudflare cache when posts are created, edited, deleted etc. The problem arises when the plugin is updated or has some of its settings changed, and the plugin purges subrequest URLs and replaces them with new, randomly-generated filenames.

So, if you change a setting on page cache/optimizer plugin, it may purge some files from its cache, with the result that pages in Cloudflare cache may be pointing to the wrong URLs for aggregated CSS and JS files. This is not an issue with any specific optimization plugin. You need to make sure to purge Cloudflare cache whenever there are changes/updates made to your theme or plugins that result in new files names.

The vast majority of the WordPress plugins will not change subrequest URLs in the final HTML and you shouldn’t worry when updating them. But those that do change URLs, like optimization plugins, ideally should send a request to purge the relevant HTML pages from Cloudflare cache every time they replace subrequest URLs (mostly those CSS and JS aggregated files)

However, many plugins don’t, and it’s up to you to decide how to handle that situation. You can, for instance, disable all optimization features of you caching plugin, and count on similar features offered by Cloudflare instead (minification, Rocket Loader etc.). Or adopt a routine where every time you change settings or update your optimization plugin, you make sure to check whether any subrequest files had their names changed, and if so, purge the relevant Cloudflare cache. Or write a script to monitor for such changes and purge the pages accordingly. Or make a request to the plugin developer that they develop a solution for this situation. (One attempted solution was developed by the Autoptimized plugin.)

[james.s]

appreciate the thorough explanation, thank you @cbrandt