This is a single JS object weighing in at 700KB (minified, not gzipped), which is hopefully exaggerated. A 4ms difference is undetectable. Throttling it back 6x results in a difference of less than 2 animation frames.
-
Show this thread
-
Actual runnable benchmark: https://jgaskins.dev/js-vs-json/ The number that pops up is the number of milliseconds it took to fetch, load, parse, and execute the JS. Here's the code (including the Ruby script used to generate the JSON):https://github.com/jgaskins/jgaskins.github.io/tree/master/js-vs-json …
1 reply 0 retweets 1 likeShow this thread -
I'm irritated that multiple Google developers are selling this as a "perf tip". There's nothing about it that will improve your app's performance.
2 replies 0 retweets 5 likesShow this thread -
Replying to @jamie_gaskins
Benchmarking is hard. Even for your test case, I consistently get better metrics for JSON vs. JS, but there seems to be something funky about the way things are being measured here. Opening either the JS or the JSON page and refreshing once every ~500 ms results in the number
2 replies 0 retweets 0 likes -
Replying to @mathias @jamie_gaskins
Mathias Bynens Retweeted Henrik Joreteg
…steadily increasing, which is a signal that this benchmark might be a little off. I’d recommend measuring through chrome:tracing and RCS: https://v8.dev/docs/rcs FWIW, several others have reported wins from adopting this technique:https://twitter.com/HenrikJoreteg/status/1143953338284703744 …
Mathias Bynens added,
Henrik Joreteg @HenrikJoretegThis is no joke. TTI (in an already fast app) dropped by .74 seconds! Just by switching from object literal to doing this: `window.__REDUX_STATE__ = ${jsesc(JSON.stringify(startingState), { json: true, isScriptContext: true, wrap: true })}` using: https://github.com/mathiasbynens/jsesc … https://twitter.com/mathias/status/1143551692732030979 …Show this thread1 reply 0 retweets 0 likes -
Replying to @mathias
I don't see a steady increase. It jumps around a bit, certainly, but not in a single direction.
1 reply 0 retweets 0 likes -
Replying to @jamie_gaskins
For this payload https://raw.githubusercontent.com/WebKit/webkit/ffdd2799d3237993354978b9d0cdd1d248fe3787/PerformanceTests/JetStream2/SeaMonster/inspector-json-payload.js …, the JSON.parse approach is ~40% faster in V8 v7.6. (In V8 v7.5 it's only ~34% faster.) Measured by literally invoking `d8 foo.js` 100 times for each test, where foo.js contains nothing but the patterns we're discussing.
1 reply 0 retweets 0 likes -
Replying to @mathias
There is no way a React app sending a 7MB Redux store snapshot in their initial payload should care about whether they're putting it in JS or JSON. Their biggest problem is that they're sending 7MB in their initial payload. Even my 700KB example was ridiculous.
2 replies 0 retweets 0 likes -
Replying to @jamie_gaskins
I agree 7 MB is not something I hope to see often on real-world web apps. But 700 kB does not seem too far-fetched, IMHO. Have you tried measuring a 700 kB payload the way I described?
1 reply 0 retweets 0 likes -
Replying to @mathias
I'm 100% on your side when it comes to CPU cycles, but that isn't the whole picture. The JSON-string version is a larger file because you have to quote keys and escape quotes. That and cross-browser comparability is why I made the benchmark that includes downloading the file :-)
1 reply 0 retweets 0 likes
Here are the results from our measurements in JS engines directly. You're absolutely right that download cost matters too (as @addyosmani's post points out!). In our tests, file sizes are JS = 7.33 MB, JSON = 8.20 MB.pic.twitter.com/btFfHl1Xno
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.