[wp-trac] [WordPress Trac] #63636: Enable instant page navigations from browser history via bfcache when sending "nocache" headers

[WordPress Trac]

#63636: Enable instant page navigations from browser history via bfcache when
sending "nocache" headers
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.9
Component:  Administration                       |     Version:  6.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-unit-   |     Focuses:
  tests                                          |  performance, privacy
-------------------------------------------------+-------------------------

Comment (by westonruter):

 @kkmuffme Sorry for the delay in replying to you.

 Replying to [comment:10 kkmuffme]:
 >
 > 1) Since the function is called "wp_get_nocache_headers()" I'd expect
 that there should be absolutely no caching including no bfcache be
 happening. This is why "no-store" should stay included.

 Except for most of this function's existence, from 2.8.0 until 6.3.0, it
 didn't include `no-store`. The function has "nocache" in its name which to
 me implies the `no-cache` directive.

 > 2) In an ideal world it's +100 from me :-)
 > However:
 > The problem with those headers is always that proxy caches change
 if/which directives they adhere to and how.

 I don't fully understand everything you've outlined here. But I will note
 that the Cloudflare docs there say: "`private` — Indicates the response
 message is intended for a single user, such as a browser cache, and must
 not be stored by a shared cache like Cloudflare or a corporate proxy."

 I don't understand the the Cloudflare docs there on the conditions. When
 it says “Browser Cache TTL is set” is this referring to the `max-age`
 directive? It says if Origin Cache Control is disabled, “Cache-Control
 returned to eyeball does not include private.” (Aside: Strange to mention
 “eyeball” 👁️ and not “the client”.) Is a solution here then to make sure
 the `Cache-Control` response header does not have `max-age`?

 > 3) the bfcache introduces a huge potential for data loss for data that
 can be used by multiple users (= anything in wp-admin)

 Yes, this is a good callout. Nevertheless, the lack of bfcache also
 introduces a huge potential for data loss for all users as well, if they
 navigate away from a page without having saved a change, for example. But
 you're also right that there needs to be better accounting for updating
 stale data. I opened an issue for this a couple months ago:
 https://github.com/westonruter/nocache-bfcache/issues/25

 I will say, however, that post locking should specifically deal with the
 scenario you're talking about.

 > Fyi Chrome is implementing this natively:
 https://developer.chrome.com/docs/web-platform/bfcache-ccns
 > Also see https://github.com/whatwg/html/issues/7189

 Yes, but unfortunately cookie changes happen often, especially client-side
 via JS, which means this doesn't apply. And this is Chrome only.

 And the Chrome docs there still say: “Best practice remains to minimize
 use of Cache-Control: no-store rather than depend on these heuristics.”

 Another common reason I see bfcache being blocked is
 `JsNetworkRequestReceivedCacheControlNoStoreResource`, where JavaScript on
 a page makes a request to a resource served with the no-store directive
 (e.g. REST API or admin-ajax). This happens everywhere in the wp-admin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63636#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform