x-html-edge-cache-version returning -1

[ScottTravisHartley]

After integrating the script I am not noticing a decrease in TTFB at the level I would expect. Using the standard cache everything method my TTFB would be reduced to about 30-40MS which I expected.

However, I noticed after adding the plugin (for WordPress) and adding the above script after setting up the workers within my account and adding the necessary information my cached version only ever seems to return -1 and only appears to be reporting cache misses.

Related Domain: https://www.sertmedia.com/

However, the proxied scripts functionality is working as expected, and the font functionality works as well despite me deactivating the functionality (for fonts).

For example https://gtmetrix.com/reports/www.sertmedia.com/ws0Mrsrt

Not quite sure what the issue is with the setup?

Additional information. The account does not have KV access, therefore it is using the API key setup all the information was pasted into the spots as instructed in the docs.

[pmeenan]

It looks like the plugin headers aren't present. The most likely cause for that is if you have a server-side cache as well that has a cached copy of the pages before the plugin was installed. If you clear the server-side caches it should start working.

-1 is normal when you are using the API for purging.

I'll see about adding some troubleshooting tips to the docs because there are a few things that can cause the cache to bypass (server-side caches, reloading pages, using dev tools with "cache disabled" checked).

[ScottTravisHartley]

Okay, so it looks to be an issue with the Nginx caching SiteGround has setup purging it did not good but disabling it resolves the issue. I will have to look more into it to figure out why it does this but that being said the issue is not on this side thank you!

[pmeenan]

One option to allow for both might be for me to allow for a static config in the worker where you manually specify bypass cookies (I can include a default) and then it can cache even if it doesn't see the response headers from the plugin. That assumes the SiteGround caching will pass-through any site edits though, otherwise the edge cache will get stale.

I could also potentially combine it with a stale-while-revalidate check while running in that mode where it would return the cached HTML immediately and asynchronously check to see if the HTML updated (in case a purge wasn't detected). That way it would serve a single stale page load and update itself.

[ScottTravisHartley]

SiteGround's cache does have an auto-purge system for site edits so it shouldn't get stale as do most caching plugins so this sounds like a solid solution.

[michaelbourne]

To go along with this, what would cause a response of "x-html-edge-cache-status: Miss, Cached"?

Similar to the issue above, I tested along side WP Rocket (so a page cache could kick in if CF missed) and noticed it wasn't sending the headers either, which makes some sense. Disabling caching through WP Rocket (but leaving other performance features on) did work however.

[pmeenan]

"Miss, Cached" usually means the page wan't in the edge cache, was fetched from the origin and added to the edge cache. The "miss" could have also been for a bypass from a page navigation with dev tools or a soft-reload. I updated the worker earlier today to only bypass on hard reloads (ctrl-reload) and it also has a "Reload Bypass" string now in that case so it is easier to tell.

[michaelbourne]

Awesome, appreciate that.