Skip to content

Extend block.json schema to allow fetchpriority and in_footer to be specified for view scripts/modules #71366

@westonruter

Description

@westonruter

In Core-54018, it was proposed that scripts defined in blocks.json should be allowed to be declare to be printed in the footer. Ultimately, this was closed due to #52536 since all block view scripts now get printed with defer, which has a similar effect. There is, however, still a performance benefit to printing deferred scripts in the footer since they compete less with critical resources, like the LCP image, per Core-63486. See also my blog post.

Another way to prevent scripts and script modules from adding network contention for the critical resources is to add fetchpriority=low, which is proposed in Core-61734. The patch by default uses fetchpriority=low for any script modules registered for the Interactivity API, but there is now way for for a different default to be used. Specifically, there were two comments that called this out:

// TODO: There needs to be a way to specify that a script defined in a module is safe to use fetchpriority=low. Perhaps the viewScript should not only allow a handle string or a file:./foo.js string, but allow an an array of params like { "href": "./foo.js", "fetchpriority": "low" }. This would allow for more metadata to be supplied, like the script loading strategy. Related: https://core.trac.wordpress.org/ticket/56408 and https://core.trac.wordpress.org/ticket/54018. (ref)

// TODO: Add ability for the fetchpriority to be specified in block.json for the viewScriptModule. In wp_default_script_modules() the fetchpriority defaults to low since server-side rendering is employed for core blocks, but there are no guarantees that this is the case for non-core blocks. That said, viewScriptModule entails Interactivity API, following the pattern from core it should be SSR'ed and that is why this is the default for when the block supports interactivity. (ref1, ref2)

This issue is to propose extending the block.json schema. I'm re-opening Core-54018 which is where the core would leverage the new properties when registering scripts and script modules.

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature] Script Modules APIRelated to the Script Modules API that adds support for native ES modules and import maps[Type] PerformanceRelated to performance efforts

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions