[PSA] bfcache Enabling bfcache by default on Desktop in M96

[Minoru Chikamune]

tl;dr: We are enabling back/forward cache by default on Desktop in M96. This feature may require changes to Chromium embedder code.

Back/forward cache improves user experience by enabling instant history navigation to previously-visited pages by freezing and preserving them in memory and reusing them upon history navigations. This feature is now enabled by default. While the bfcache is implemented in //content, it changes a number of assumptions around navigation and document lifecycle, which can lead to various bugs in the code relying on them. 

BFCache for a given WebContents is disabled unless the embedder explicitly opt-ins into it by overriding a IsBackForwardCacheSupported() method on WebContentsDelegate to return true. Given that instant history navigations considerably improve user experience, we encourage //content embedders to consider enabling it. However we strongly recommend //content embedders to audit their codebases to detect and fix assumptions invalidated by BFCache before enabling it — more details are available here.

Please feel free to reach out to the bfcac...@chromium.org if you have any questions about back/forward cache.

Thanks

[Erik Anderson]

Hi,

 

There’s currently a lot of knobs configured via Finch which are similarly mirrored in testing/variations/fieldtrial_testing_config.json.

 

Do you have a summary of the behavioral deltas with and without that FeatureParam configuration being present?

 

Is there a plan to move some or all that configuration into in-code defaults that would be, by default, inherited by embedders?

 

Thanks,

Erik

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAEy%2BVD%2BtQYEfwjbYjRCc7JXLRJ%3DS9YpQU9KyJjcAWB8%2BS6t7xA%40mail.gmail.com.

[Minoru Chikamune]

> Do you have a summary of the behavioral deltas with and without that FeatureParam configuration being present?

Oh, this is a good question. Let me explain each FeatureParams.

Param name	Recommended value	Description
cache_size	6	The BFCache cache size per tab.
foreground_cache_size	2	The cache size for the foreground render process per tab.
max_buffered_bytes	200000 (default value)	Maximum number of bytes that can be buffered while in back-forward cache (per-request).
max_buffered_bytes_per_process	1024000 (default value)	Maximum number of bytes that can be buffered in total (per-process) by all network requests in one renderer process while in back-forward cache.
TimeToLiveInBackForwardCacheInSeconds	180 (default value)	The time to live in seconds for documents in BackForwardCache.
enable_same_site	false (default value)	(Beta) Same site BFCache.
unload_support	no (default value)	always: disable unload handler opt_in_header_required: (deprecated) no: enable unload handler (recommended)
all_extensions_allowed	true	Extension support.
extension_message_supported	true	Extension message support for extension.
content_injection_supported	true	Content script support for extension.
check_eligibility_after_pagehide	(N/A)	(deprecated)
file_system_api_supported	(N/A)	(deprecated)
grace_period_to_finish_loading_in_seconds	(N/A)	(deprecated)
supported_features	(N/A)	(deprecated)

> Is there a plan to move some or all that configuration into in-code defaults that would be, by default, inherited by embedders?

Currently, we don't have a plan yet, but we want to update the default values to match with the recommended values.

You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/MW2PR00MB042508A32567357D799C6B6DF4B79%40MW2PR00MB0425.namprd00.prod.outlook.com.

[Erik Anderson]

Hi,

 

Thanks for the info! As an embedder, we’ve been exploring the benefits vs. regressions we might see. If you’re able to share anything about your high-level evaluation methodology it would be a big help.

 

In particular, it seems likely that histogram perf metrics related to page load time may regress because the current, relatively fast back/forward navigations (vs. a normal nav) typically have higher cache hit rates (because of recency and because cache control directives can be handled a little differently) and are presumably making those histograms look faster on average. With bfcache, some set of those back/forward navigations will instead be handled by a bfcache’d page which isn’t doing a nav at all and will not make contributions to those histograms.

 

Are you able to share anything about the methodology you used to reason over perf wins vs. hypothetical losses? Are you looking at both a new, separate set of metrics tied to bfcache’d pages and otherwise re-baselining the existing metrics impacted by there being fewer traditional navigations?

 

Do you have any synthetic tests that attempt to measure the perf impact of this feature? Understanding your methodology there would also be valuable to learn from.

 

Thanks,

Erik

[Minoru Chikamune]

On Fri, Oct 29, 2021 at 8:11 AM Erik Anderson <Erik.A...@microsoft.com> wrote:

Do you have any synthetic tests that attempt to measure the perf impact of this feature? Understanding your methodology there would also be valuable to learn from.

We are checking the following BackForwardCache.Restore.NavigationToFirstPaint histogram which measures milliseconds from back-forward cache and the first paint.

https://source.chromium.org/chromium/chromium/src/+/main:tools/metrics/histograms/metadata/navigation/histograms.xml;l=490-502;drc=81a3b73b3497db891e10a984206d86ce0e21f1f1;bpv=0;bpt=0