WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 10 months ago

#48880 new enhancement

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

Reported by: naxvog Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Script Loader Keywords: has-patch needs-testing
Focuses: javascript, performance Cc:

Description

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.

Attachments (1)

48880.diff (1.3 KB) - added by naxvog 10 months ago.
Changes to the WP_Scripts localize method and the block editor init script

Download all attachments as: .zip

Change History (6)

@naxvog
10 months ago

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

#1 @swissspidy
10 months ago

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.

#2 @gziolo
10 months ago

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.

#3 in reply to: ↑ description @gziolo
10 months ago

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.

#4 @johnbillion
10 months ago

  • Keywords has-patch needs-testing added
  • Version 5.3 deleted

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

#5 @aduth
10 months ago

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.

Note: See TracTickets for help on using tickets.