# Introducing Shared Memory Versioning to improve slow interactions

DevFeed: [Introducing Shared Memory Versioning to improve slow interactions](<https://devfeed.tech/articles/introducing-shared-memory-versioning-to-improve-slow-interactions-4188.md>)

Original publisher: [Read original article](<https://blog.chromium.org/2024/06/introducing-shared-memory-versioning-to.html>)

Author: Chromium Blog (noreply@blogger.com)

Published: 2024-06-03T17:24:00Z

Content type: article

Language: en

Sources: [Chromium Blog](<https://devfeed.tech/sources/chromium-blog.md>)

Topics: [real user monitoring](<https://devfeed.tech/topics/real-user-monitoring.md>), [Processes](<https://devfeed.tech/topics/processes.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [memory](<https://devfeed.tech/tags/memory.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [none](<https://devfeed.tech/tags/none.md>), [performance](<https://devfeed.tech/tags/performance.md>), [privacy](<https://devfeed.tech/tags/privacy.md>), [process](<https://devfeed.tech/tags/process.md>), [the-fast-and-the-curious](<https://devfeed.tech/tags/the-fast-and-the-curious.md>), [traces](<https://devfeed.tech/tags/traces.md>), [web-platform](<https://devfeed.tech/tags/web-platform.md>)

## AI overview

The article describes Chrome's use of field data and anonymized Perfetto traces to investigate slow web interactions. It identifies redundant synchronous cookie reads from the network service as a source of contention and introduces shared memory versioning as the stated improvement.

## Source excerpt

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 s