Use of Cache-Control: no-store, no-cache, max-age=0 should be flagged by Site Health for unauthenticated frontend responses

[westonruter]

Browsers have typically prevented a page from being served from bfcache when is served with Cache-Control: no-store. For example, in Core-21938 this was done to prevent a cached page from being accessed after a user logs out of WordPress. However, there are many sites that serve Cache-Control: no-store even to unauthenticated requests. This is the number one reason for why bfcache is disabled in WP sites, as is seen at GoogleChromeLabs/wpp-research#75.

Chrome is currently experimenting with enabling bfcache when pages are served with Cache-Control: no-store, but there are scenarios still where such pages remain ineligible.

A Site Health test can be added which warns sites when they served unauthenticated responses with Cache-Control: no-store as this can make them ineligible for bfcache and thus negatively impact navigation performance.

[westonruter]

This may end up being important for Speculative Loading as well (h/t @yoavweiss):

Looks like Chromium is about to change how prefetches behave, so that only cacheable resources will be served from the prefetch cache: https://groups.google.com/a/chromium.org/g/blink-dev/c/Zdo71C0k9C0/m/BRXW6aQiAAAJ

If you're prefetching your HTMLs, make sure they are actually cacheable, even with a short lifetime.

[gilbertococchi]

That's an interesting insight, +1.

Also, if a WP Site uses Speculation Rules Prefetch or Prerender having BFCache working is particularly important in case of following back/forward navigations.

Speculation Rules is an API that works really well in combination with BFCache (not being blocked) and/or Cross Document View Transition.

[westonruter]

This may make sense to propose as part of the core merge for Speculative Loading since it if the Cache-Control header prevents Speculation Rules from working, then having the feature enabled in core would only wastefully increase server load without improving the user's navigation experience.

See Core-62503 and WordPress/wordpress-develop#7860.

cc @felixarntz

[westonruter]

Speculative Loading should also then be disabled automatically when a user is logged-in.

[westonruter]

Speculative Loading should also then be disabled automatically when a user is logged-in.

I've filed this as #1709.

[westonruter]

@b1ink0 Given your recent experience on Site Health tests #1727 and #1762 you may want to pick this up as well.

[b1ink0]

@westonruter
I have a few questions regarding the implementation to clarify things:

1. From what I understand, we need to add this check for the HTML page, such as the home page, and verify its header—but not for the assets, correct?
2. If we need to add this check for the assets as well, then integrating the assets check into #1727 seems like a better approach, while handling the HTML page check as a separate site health check.

[gilbertococchi]

@westonruter I took a stab at looking at the HTTP Archive data and it looks like there are at least 547k WP Origins using CCNS to date.

[westonruter]

1. From what I understand, we need to add this check for the HTML page, such as the home page, and verify its header—but not for the assets, correct?

Correct! Doing one HTTP GET request to the homepage.

2. If we need to add this check for the assets as well, then integrating the assets check into #1727 seems like a better approach, while handling the HTML page check as a separate site health check.

No, this doesn't relate to the assets. So I think these two tests are related but distinct.