https://blog.chromium.org/2024/06/introducing-shared-memory-versioning-to.html * Chromium Blog Chromium Blog News and developments from the open source browser project Introducing Shared Memory Versioning to improve slow interactions Monday, June 3, 2024 [Fast] On the Chrome team, we believe it's not sufficient to be fast most of the time, we have to be fast all of the time. Today's The Fast and the Curious post explores how we contributed to Core Web Vitals by surveying the field data of Chrome responding to user interactions across all websites, ultimately improving performance of the web. As billions of people turn to the web to get things done every day, the browser becomes more responsible for hosting a multitude of apps at once, resource contention becomes a challenge. The multi-process Chrome browser contends for multiple resources: CPU and memory of course, but also its own queues of work between its internal services (in this article, the network service). This is why we've been focused on identifying and fixing slow interactions from Chrome users' field data, which is the authoritative source when it comes to real user experiences. We gather this field data by recording anonymized Perfetto traces on Chrome Canary, and report them using a privacy-preserving filter. When looking at field data of slow interactions, one particular cause caught our attention: recurring synchronous calls to fetch the current site's cookies from the network service. Let's dive into some history. Cookies under an evolving web Cookies have been part of the web platform since the very beginning. They are commonly created like this: document.cookie = "user=Alice;color=blue" And later retrieved like this: // Assuming a `getCookie` helper method: getCookie("user", document.cookie) Its implementation was simple in single-process browsers, which kept the cookie jar in memory. Over time, browsers became multi-process, and the process hosting the cookie jar became responsible for answering more and more queries. Because the Web Spec requires Javascript to fetch cookies synchronously, however, answering each document.cookie query is a blocking operation. The operation itself is very fast, so this approach was generally fine, but under heavy load scenarios where multiple websites are requesting cookies (and other resources) from the network service, the queue of requests could get backed up. We discovered through field traces of slow interactions that some websites were triggering inefficient scenarios with cookies being fetched multiple times in a row. We landed additional metrics to measure how often a GetCookieString() IPC was redundant (same value returned as last time) across all navigations. We were astonished to discover that 87% of cookie accesses were redundant and that, in some cases, this could happen hundreds of times per second. The simple design of document.cookie was backfiring as JavaScript on the web was using it like a local value when it was really a remote lookup. Was this a classic computer science case of caching?! Not so fast! The web spec allows collaborating domains to modify each other's cookies. Hence, a simple cache per renderer process didn't work, as it would have prevented writes from propagating between such sites (causing stale cookies and, for example, unsynchronized carts in ecommerce applications). A new paradigm: Shared Memory Versioning We solved this with a new paradigm which we called Shared Memory Versioning. The idea is that each value of document.cookie is now paired with a monotonically increasing version. Each renderer caches its last read of document.cookie alongside that version. The network service hosts the version of each document.cookie in shared memory. Renderers can thus tell whether they have the latest version without having to send an inter-process query to the network service. [Fast] This reduced cookie-related inter-process messages by 80% and made document.cookie accesses 60% faster . Hypothesis testing Improving an algorithm is nice, but what we ultimately care about is whether that improvement results in improving slow interactions for users. In other words, we need to test the hypothesis that stalled cookie queries were a significant cause of slow interactions. To achieve this, we used Chrome's A/B testing framework to study the effect and determined that it, combined with other improvements to reduce resource contention, improved the slowest interactions by approximately 5% on all platforms. This further resulted in more websites passing Core Web Vitals . All of this adds up to a more seamless web for users. [Screenshot] Timeline of the weighted average of the slowest interactions across the web on Chrome as this was released to 1% (Nov), 50% (Dec), and then all users (Feb). Onward to a seamless web! By Gabriel Charette, Olivier Li Shing Tat-Dupuis, Carlos Caballero Grolimund, and Francois Doray, from the Chrome engineering team Share on Twitter Share on Facebook Google Labels: the fast and the curious [ ] [ncccFICB87] Labels * $200K 1 * 10th birthday 4 * abusive ads 1 * abusive notifications 2 * accessibility 3 * ad blockers 1 * ad blocking 2 * advanced capabilities 1 * android 2 * anti abuse 1 * anti-deception 1 * background periodic sync 1 * badging 1 * benchmarks 1 * beta 83 * better ads standards 1 * billing 1 * birthday 4 * blink 2 * browser 2 * browser interoperability 1 * bundles 1 * capabilities 6 * capable web 1 * cds 1 * cds18 2 * cds2018 1 * chrome 35 * chrome 81 1 * chrome 83 2 * chrome 84 2 * chrome ads 1 * chrome apps 5 * Chrome dev 1 * chrome dev summit 1 * chrome dev summit 2018 1 * chrome dev summit 2019 1 * chrome developer 1 * Chrome Developer Center 1 * chrome developer summit 1 * chrome devtools 1 * Chrome extension 1 * chrome extensions 3 * Chrome Frame 1 * Chrome lite 1 * Chrome on Android 2 * chrome on ios 1 * Chrome on Mac 1 * Chrome OS 1 * chrome privacy 4 * chrome releases 1 * chrome security 10 * chrome web store 32 * chromedevtools 1 * chromeframe 3 * chromeos 4 * chromeos.dev 1 * chromium 9 * cloud print 1 * coalition 1 * coalition for better ads 1 * contact picker 1 * content indexing 1 * cookies 1 * core web vitals 2 * csrf 1 * css 1 * cumulative layout shift 1 * custom tabs 1 * dart 8 * dashboard 1 * Data Saver 3 * Data saver desktop extension 1 * day 2 1 * deceptive installation 1 * declarative net request api 1 * design 2 * developer dashboard 1 * Developer Program Policy 2 * developer website 1 * devtools 13 * digital event 1 * discoverability 1 * DNS-over-HTTPS 4 * DoH 4 * emoji 1 * emscriptem 1 * enterprise 1 * extensions 27 * Fast badging 1 * faster web 1 * features 1 * feedback 2 * field data 1 * first input delay 1 * Follow 1 * fonts 1 * form controls 1 * frameworks 1 * fugu 2 * fund 1 * funding 1 * gdd 1 * google earth 1 * google event 1 * google io 2019 1 * google web developer 1 * googlechrome 12 * harmful ads 1 * html5 11 * HTTP/3 1 * HTTPS 4 * iframes 1 * images 1 * incognito 1 * insecure forms 1 * intent to explain 1 * ios 1 * ios Chrome 1 * issue tracker 3 * jank 1 * javascript 5 * lab data 1 * labelling 1 * largest contentful paint 1 * launch 1 * lazy-loading 1 * lighthouse 2 * linux 2 * Lite Mode 2 * Lite pages 1 * loading interventions 1 * loading optimizations 1 * lock icon 1 * long-tail 1 * mac 1 * manifest v3 2 * metrics 2 * microsoft edge 1 * mixed forms 1 * mobile 2 * na 1 * native client 8 * native file system 1 * New Features 5 * notifications 1 * octane 1 * open web 4 * origin trials 2 * pagespeed insights 1 * pagespeedinsights 1 * passwords 1 * payment handler 1 * payment request 1 * payments 2 * performance 20 * performance tools 1 * permission UI 1 * permissions 1 * play store 1 * portals 3 * prefetching 1 * privacy 2 * privacy sandbox 4 * private prefetch proxy 1 * profile guided optimization 1 * progressive web apps 2 * Project Strobe 1 * protection 1 * pwa 1 * QUIC 1 * quieter permissions 1 * releases 3 * removals 1 * rlz 1 * root program 1 * safe browsing 2 * Secure DNS 2 * security 36 * site isolation 1 * slow loading 1 * sms receiver 1 * spam policy 1 * spdy 2 * spectre 1 * speed 4 * ssl 2 * store listing 1 * strobe 2 * subscription pages 1 * suspicious site reporter extension 1 * TCP 1 * the fast and the curious 22 * TLS 1 * tools 1 * tracing 1 * transparency 1 * trusted web activities 1 * twa 2 * user agent string 1 * user data policy 1 * v8 6 * video 2 * wasm 1 * web 1 * web apps 1 * web assembly 2 * web developers 1 * web intents 1 * web packaging 1 * web payments 1 * web platform 1 * web request api 1 * web vitals 1 * web.dev 1 * web.dev live 1 * webapi 1 * webassembly 1 * webaudio 3 * webgl 7 * webkit 5 * WebM 1 * webmaster 1 * webp 5 * webrtc 6 * websockets 5 * webtiming 1 * writable-files 1 * yerba beuna center for the arts 1 Archive * 2024 + Jun + May + Apr + Mar + Feb * 2023 + Nov + Oct + Sep + Aug + Jun + May + Apr + Feb * 2022 + Dec + Sep + Aug + Jun + May + Apr + Mar + Feb + Jan * 2021 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2020 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2019 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2018 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2017 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2016 + Dec + Nov + Oct + Sep + Aug + Jun + May + Apr + Mar + Feb + Jan * 2015 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2014 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2013 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2012 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2011 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2010 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2009 + Dec + Nov + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2008 + Dec + Nov + Oct + Sep [8LnOxYWFhZ] Feed Follow @ChromiumDev Give us feedback in our Product Forums. [P2DAYDAaDwWA] * Google * Privacy * Terms