Using JSON.parse instead of an actual object literal when localizing scripts

[naxvog]

As the V8 team at Google stated in their "The cost of JavaScript in 2019" ​https://v8.dev/blog/cost-of-javascript-2019#json" blog post using JSON.parse() is generally faster (~18%) for configuration object literals such as the output of the localize method of the WP_Scripts class.

As the output of the localize method is already rendered using wp_json_encode() the change would be quite trivial and backward compatible.

Added a diff with additional changes to the block editor init script using the same method.

[naxvog]

Changes to the WP_Scripts localize method and the block editor init script

[swissspidy]

I'd like to really stress this:

A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes.

I doubt this change will make a noticeable difference.

[gziolo]

I was talking with @aduth that we could use this technique in other places, one of them is:

wp.apiFetch.createPreloadingMiddleware()

It is used in Gutenebrg to preload REST API requests on the server.

It looks like is another one:

wp.editPost.initializeEditor()

It might also contain tons of data once the theme opts-in to provide some custom CSS.

There is also this REST API config which is exposed in HTML source which can grow big which is another one to consider. It might be already included in the preloading middleware though.

[gziolo]

Replying to naxvog:

Added a diff with additional changes to the block editor init script using the same method.

Now that I checked the source of the diff, I think the part updating the block editor makes sense. As noted in my previous comment, we should also do the same for the preloading middleware for REST API calls.

[johnbillion]

Assuming that this has actually been tested, what do the before and after timings look like?

[aduth]

Unless I've missed something in the related resources, this is also specifically talking about Chrome / V8. We should be mindful as well as to the potential impact on other supported browsers.

Generally, I feel that these sorts of engine-specific optimizations are not really reliable over the long-term. Then again, since this is mostly an internal implementation detail, it seems like it shouldn't be too much of a problem to change again, if ever the advantage swung back in the other direction in the future.