[wp-trac] [WordPress Trac] #50328: Enqueue script and style assets only for blocks present on the page

[WordPress Trac]

#50328: Enqueue script and style assets only for blocks present on the page
-------------------------+-----------------------------
 Reporter:  aduth        |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Editor       |    Version:
 Severity:  normal       |   Keywords:
  Focuses:  javascript   |
-------------------------+-----------------------------
 Related: https://github.com/WordPress/gutenberg/pull/22754
 Related: #49926

 **Context:**

 Currently, all scripts and styles for all blocks will be rendered in every
 front-end page. This is hugely wasteful, since in reality only the scripts
 and styles associated with blocks relevant for that page should be
 enqueued.

 In part, this is made difficult by the fact that it's quite common to
 enqueue block assets as part of the `enqueue_block_assets` action, which
 is called not specifically for any one block type, but rather once per
 page load.

 **Proposal:**

 Only block assets (scripts and styles) of blocks present in the page
 should be enqueued.

 **Implementation Specifics:**

 See also relevant Gutenberg proposal changes:
 https://github.com/WordPress/gutenberg/pull/22754

 While the previously-mentioned behavior of `enqueue_block_assets` may not
 be reconcilable with the desire to load assets relevant for the page, it
 should be possible for a block implementer to opt in to this behavior
 using the (already supported) `script` and `style` arguments of
 `register_block_type`.

 **Backward Compatibility:**

 See also discussion from:
 https://github.com/WordPress/gutenberg/pull/22754

 Notably
 [https://github.com/WordPress/gutenberg/pull/22754#issuecomment-638860540
 this comment]:

   I think it's something that, if implemented, should warrant some release
 devnotes explaining the change.
   The broad answer for me is that it does change some behaviors, but not
 anything that was ever particularly documented as expected, or practically
 speaking would be common to depend upon.
   Specifically, these changes could include:
   If one was to rely on some block script to define some functionality
 leveraged outside the script and on pages where the block isn't present,
 those scripts would now only be enqueued on pages where the block is
 present. This is very similar case to "incidental availability" of script
 functionality from dependencies of other scripts, and is more an error on
 the part of the developer where any such script should be defined as an
 explicit dependency of the script.
   If one was to rely on some block stylesheet to style pages where that
 block is not present, it would now only be enqueued on pages where the
 block is present. It is not clear there would be any reason someone would
 have done this, since the purpose of a block stylesheet should be to style
 the block (or even if it was styling the page, at least only the page
 where the block is present).
   If one was to rely on the particular page enqueue lifecycle (header,
 footer placement), those expectations could change. This is documented in
 more detail in the original comment, and is potentially not an unsolvable
 challenge to preserve the current behavior if problematic.
   It could also use some further testing regarding the comment at #21838
 (comment) of more specialized use-cases, though the later comment #21838
 (comment) seems to imply that the general approach is compatible.

 Another potential use-case described at
 https://github.com/WordPress/gutenberg/pull/22754#issuecomment-639079262,
 though granted to be an uncommon scenario.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50328>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform