Improve loading method for block Javascript

[megphillips91]

What problem does this address?

Performance. All block styles are loaded at pageload if the block plugin is installed and active in the site whether or not the block is in use on the page. Leads to many JS files enqueue at runtime and potential performance drain on sites which lack efficient CDN and cache.

Not sure how many plugins enqueue additional scripts that run on the front end of the site and how and when that will factor into this concern. Regarding that same conversation, I am not sure how the admin edit page screen or whatever other screen is loading the block editor is also affected and whether this would mean separate concerns for JS intended to be used within the admin or the front end of the site.

What is your proposed solution?

I don't really have the 'right' answer, and I know there are some sort of fundamental roadblocks, but I am just throwing out ideas here...

1. Can we address some way of implementing server side caching of these JS files into core?
2. Does it make sense to inline some JS in a way that would pull the JS only if the block is present on the page?
3. Referencing the solution being proposed on the css side: Improve loading method for block styles #28358 potentially we can follow some similar scheme to address the JS?
4. Marketing and Learn teams to prepare material and meetup workshops which outline best practices for implementing server side cacheing and CDN to offset these challenges.
5. Plugin screen to have a "blocks" tab which helps site admins keep track of how many plugins are being installed and for what purpose. I have heard good reactions to a plugin which is doing great at highlighting which blocks are being used and how many times and where on site, etc. (can't remember name ATM) and can help site admins use a smaller number of blocks more efficiently across site.

[youknowriad]

Just to clarify, is this about the editor or the frontend? If it's about the editor, I'd suggest closing this in favor of #27268

For the frontend, we don't have many blocks adding JS to the frontend (0 in core blocks) but a declarative approach (like the CSS one) is explored in #29537

I know @sarayourfriend did some work on the former too but there's a lot of complexities there.

[skorasaurus]

For the frontend (that is when a user is viewing a published page or post), javascript files registered by a specific block are only loaded when a block is present on a page/page.
This was just recently accomplished in #25220 As far as I know, no modifications are needed for a block to take advantage of this. I tested it yesterday with a couple blocks that each load JS and none of their JS was being loaded on pages that didn't contain that block.
(ref #15256 (comment))
(Please correct me if I'm wrong; this had been one of my personal pet peeves with Gutenberg and I'd love it if this was solved!)

EDIT: Sorry for confusion, I'm still trying to understand myself if blocks' JS are only loaded when they appear on a page #29537 (comment) I need to learn more about this.

As for number 5, I agree that this is a problem (and it has been for years with wordPress, with keeping track of which shortcodes are being used on a site; I've been using find-my-blocks with some success.

[gziolo]

maybe not - #29537 (comment) I have read into this more...

The goal is to eventually have a loading of all assets optimized on the front and correlated with blocks used. The only remaining use case that I'm aware of is infinite scrolling that loads more content and can contain additional blocks that would have to dynamically inject CSS and JS. @aristath can provide a more detailed answer as he explored everything for CSS support.

[aristath]

The only remaining use case that I'm aware of is infinite scrolling that loads more content and can contain additional blocks that would have to dynamically inject CSS and JS. @aristath can provide a more detailed answer as he explored everything for CSS support.

Yeah, infinite-scroll is not yet addressed. The main issue is there is currently nothing implementing infinite-scroll so it was impossible to test and fix it properly. I have some ideas and a proof-of-concept to add these via JS, but until we actually have something to test infinite-scroll there's not much that can be done.
The POC I had for this adds a small script that checks if the stylesheet already exists in the DOM. If it does not, then it gets injected in <head> and the browser loads it.
Is anyone aware of an infinite-scroll implementation that works with FSE? If yes then I can test it and submit a PR for this scenario 👍