[wp-trac] [WordPress Trac] #63805: Extend the existing conditional loading optimization for block-specific global styles from core blocks to include third-party blocks, improving performance by only loading styles for blocks actually present on the page.

[WordPress Trac]

#63805: Extend the existing conditional loading optimization for block-specific
global styles from core blocks to include third-party blocks, improving
performance by only loading styles for blocks actually present on the page.
-------------------------+-----------------------------
 Reporter:  mokhaled     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Themes       |    Version:
 Severity:  normal       |   Keywords:  has-patch
  Focuses:  performance  |
-------------------------+-----------------------------
 Extend the existing conditional loading optimization for block-specific
 global styles from core blocks to include third-party blocks, improving
 performance by only loading styles for blocks actually present on the
 page.

 == Description ==

 === Current Behavior ===

 WordPress currently applies conditional loading for block-specific global
 styles only to core blocks. When `wp_should_load_block_assets_on_demand()`
 returns true, core blocks benefit from having their global styles loaded
 only when the block is actually present on the page. However, third-party
 blocks always have their global styles loaded unconditionally, missing
 this performance optimization.

 === Problem ===

 The existing TODO comment in `wp_add_global_styles_for_blocks()` (line
 316) states: "TODO: Explore how this could be expanded to third-party
 blocks as well." This represents a performance opportunity where third-
 party blocks could benefit from the same conditional loading optimization
 that core blocks already enjoy.

 === Solution ===

 This patch extends the conditional loading logic to support third-party
 blocks by:

 1. '''Unified Handle Generation''': Both core and third-party blocks now
 use the same logic to determine if their styles should be loaded
 2. '''Third-party Block Handle Pattern''': Implements the expected
 WordPress handle format for third-party blocks (`wp-block-namespace-block-
 name`)
 3. '''Consistent Fallback''': Maintains existing fallback behavior for
 blocks with unexpected naming patterns
 4. '''Documentation Update''': Removes the TODO and updates comments to
 reflect that both core and third-party blocks are supported

 === Technical Details ===

 ==== Core Block Handles ====
 * Pattern: `core/paragraph` → Handle: `wp-block-paragraph`

 ==== Third-party Block Handles ====
 * Pattern: `my-plugin/custom-block` → Handle: `wp-block-my-plugin-custom-
 block`

 ==== Code Changes ====

 The patch modifies `wp_add_global_styles_for_blocks()` in two locations:

 1. '''Direct block name handling''' (line ~318)
 2. '''Theme.json path-based handling''' (line ~346)

 Both locations now:
 * Generate appropriate handles for third-party blocks
 * Apply the same conditional loading check
 * Maintain fallback for edge cases

 === Performance Impact ===

 '''Positive''': Reduces CSS payload by only loading third-party block
 styles when blocks are actually used on the page.

 '''Risk''': Minimal - maintains existing fallback behavior and follows
 established WordPress patterns.

 === Testing ===

 * [x] PHP syntax validation passes
 * [x] Follows WordPress coding standards
 * [x] Maintains backward compatibility
 * [x] Preserves existing core block functionality

 === Files Modified ===

 * `src/wp-includes/global-styles-and-settings.php`

 === Patch File ===

 `third-party-blocks-conditional-loading.patch`

 ----

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