The spec says: User agents may copy entries from one Document <https://html.spec.whatwg.org/multipage/dom.html#document> object's list of available images <https://html.spec.whatwg.org/multipage/images.html#list-of-available-images> to another at any time I believe the change is in line with the spec. It makes this behavior more frequent. The spec does not define behavior for other resources for now. The other involved resource types are stylesheet, fonts and scripts. It would be desirable to add a description about MemoryCache for these resources in the spec and allow cross-document reusing. For now I believe it is acceptable to launch the experiment in dev and canary.
We plan to launch the experiment in dev and canary in April. There are concerns about the memory footprint increase introduced by the change so we decide to hold the experiment in beta or stable. The experiment will provide data for the tradeoff between memory consumption and load speed. If the experiments in dev and canary show a positive impact on page loading metrics, we plan to refine the resource saving strategy and launch with the new implementation. On Mon, Mar 20, 2023 at 10:49 PM Mike Taylor <miketa...@chromium.org> wrote: > What are the desired timelines for the experiments? > > The design doc mentions only testing in dev and canary - do you plan to > eventually experiment in beta or stable? > On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote: > > Contact emails g...@google.com > > Explainer > https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing > > Specification The feature is not web-spec related. > > Design docs > > https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing > > Summary > > To measure the impact of garbage collection on Blink memory cache and > potential performance boost, we plan to keep strong references to loaded > resources in the Blink memory cache. The change will serve as an estimation > only project to collect data about the maximal cache hit rate with all > resources available. > > > Blink component Blink>Loader > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> > > TAG review > TAG review is not required since the experiment changes the internal > behavior of renderer and is transparent to the websites and web developers. > > Risks > > > Interoperability and Compatibility > > Resource reference lifetime does not affect the behavior of the browser. > We do not expect there to be interoperability or compatibility issues. > > *Gecko*: No signal > > *WebKit*: No signal > > *Web developers*: No signals > > *Other signals*: > > WebView application risks > > The change does not modify the behavior of web APIs > > Goals for experimentation > > The four configurations will be launched on dev/canary. The combinations > are: * The control group. No strong reference to resources. * Save strong > references for all resources of all types for all the pages. * Save strong > references for only script, fonts and stylesheets for all pages. * Save > strong references for all resources for only one page. * Save strong > references for only script, fonts and stylesheets for only one page. We > will evaluate the following metrics under different configurations * Core > web browsing metric (FCP/LCP etc) * Cache hit rate: > Blink.MemoryCache.RevalidationPolicy * Memory footprint * Crash Rate > > > Reason this experiment is being extended > > Ongoing technical constraints > > Debuggability > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? No, resource reference lifetime in blink is invisible to the websites. > > Flag name MemoryCacheStrongReference for the overall configuration. > MemoryCacheStrongReferenceSingleUnload and > MemoryCacheStrongReferenceFilterImages for sub configurations > > Requires code in //chrome? False > > Tracking bug https://crbug.com/1409349 > > Estimated milestones > > The feature is for experiment only. We do not expect to launch it to > stable as it is. If the experiment provides positive results, we will move > on to further refine the resource lifetime management strategy in Blink. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5196823129489408 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NyS7LtKn4p4vSvHKByTvNHuSqwSpW%2BdrQh378xf2RaC3w%40mail.gmail.com.
