 Hi gang, my name is Matthias and I work on Chrome. Today I'd like to highlight a handy little JavaScript performance trick that's a little bit surprising and somewhat counter-intuitive. JavaScript applications, and in particular web apps, commonly use large objects to represent state or other data. The example we're looking at right now is fairly simple and small, but on the web it's surprisingly common to see objects of several kilobytes in size, especially for web apps built using frameworks such as React or Redux. Unfortunately web apps often depend on this data for their initial render. In such cases, this large JavaScript object ends up on the critical path and so users end up staring at a blank screen until all of this data is loaded, parsed, compiled and executed by the JavaScript engine. How can web developers make this faster? One approach is to use server-side rendering. You serve plain HTML that already contains the processed form of the data, and therefore no JavaScript is required for the initial load of your app. This way you can avoid the need for the large JavaScript objects entirely. But what if you can't use server-side rendering? Is there anything else we can do to improve performance? It depends. In many cases, this critical data doesn't contain anything that cannot be unambiguously represented in JSON. There's no date objects, no big-ins, no maps, no sets, and so on. And in those cases, instead of having an object literal in the JavaScript source code, you can serialize the object as JSON, turn it into a JavaScript string literal, and then pass that to the built-in JSON.Pars function. This technique produces an equivalent object. Now which of these two techniques do you think is faster? As it turns out, the JSON approach is significantly faster. This is a little surprising and counter-intuitive. The JavaScript object literal feels like the more direct approach, whereas JSON.Pars feels like an additional layer of indirection. Yet somehow JSON.Pars is much faster. Why is that? Part of the reason is that for JavaScript engines, the JSON example is super simple to scan and parse. Think of it this way. To the JavaScript parser, this code snippet is little more than a call expression with a single argument. The large blob of data is just a single string literal token. On the other hand, the equivalent object literal consists of many more tokens. Each property name is an identifier token or a string-like literal, and in this case, each of the values is a numerical literal, but they could really be anything. They could be nested objects or areas with properties and values of their own, in which case there's even more tokens. So compared to the JSON.Pars example, the JavaScript parser needs to work harder just to tokenize the script correctly. Another reason why JavaScript object literals are harder to scan and parse is because you don't know ahead of time that they're object literals. Let's unpack that a little bit. Pretend you're a parser for a minute, and you're looking at source code character by character. In JSON, as soon as you see an opening brace, there's only two possible options. Either this is the start of an object, or this is invalid JSON. Two options. That's it. In JavaScript, however, there's many more possibilities. An opening brace could be the start of an object literal, but it could also be a number of other things. Let's walk through some examples. Here we have an opening brace on the second line. What do you think? Is this an object literal or not? And what does the X on the second line refer to? Does it refer to the binding on the first line or is it something else? Turns out it's not even possible to answer these questions without looking at the rest of the code. In this case, the second line creates an object literal. X refers to the binding on the first line. But in this case, it's an object is structuring, and the X doesn't refer to the first line at all. And then there's this scenario, where the second line contains an arrow function with a destructuring parameter named X. In that case, the X also does not refer to the first line. The point I'm trying to make here is that parsing JavaScript is tricky because its grammar is context sensitive. JSON doesn't have that problem, and so parsing JSON is much simpler. And that's why, especially for large objects, it's faster to use json.bars than to use a JavaScript object literal. At this point, you're probably wondering, how much faster is it exactly? We measured this for an 8 megabyte payload on cold loads with no caching and found that in V8 and Chrome, the json.bars technique is 1.7 times as fast as the object literal. And the speedup applies to other JavaScript engines and browsers as well. In Safari and JavaScript Core, the difference is even greater. There, json.bars is twice as fast. Okay, you might say, that's just a synthetic benchmark with a very large payload. How does this affect real-world web apps? Well, Henrik Yoritek applied this optimization to a Redux app he was working on and published a case study about the results. There was an 18% improvement in Time to Interactive, and the app's Lighthouse performance score went up 8 points as well. That's not bad for applying a single optimization. How can you start making use of this optimization? I wouldn't recommend doing this manually. In source code, you still want to use object literals, since they're just more readable. Instead, tooling can help you to automatically transform large object literals into json.bars as a built-time optimization. Webpack already applies the json.bars technique if your code base uses JSON modules. There's also a Babel plugin that can apply the transformation on other code. For more JavaScript performance tips, check out the cost of JavaScript on the V8 blog. And that's it. Thanks for watching, everyone.