Preload resources

[ThierryA]

There's a lot of good content — e.g., see (1), (2), (3) — on various preload use cases that can be useful within core and themes. I'll just highlight a few...

1. early load of late discovered resources: fonts, stylesheets, hero images, media, etc.
2. decoupling fetch and execution: simple "async CSS" (with help of onload), manual scheduling of JS parse+execute, etc.
3. as a mechanism to signal H2 push to servers/CDNs

Picked up from track ticket #42438, just parking an issue here which may be closed if it continues to get worked directly as a patch.

[futtta]

re (3): HTTP/2 push is planned to be removed from Chrome, see https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ

[ThierryA]

Thanks @futtta, I blindly pasted from the trac ticket which is 3 years old 😬

In any case, I think for WP core the main focus would largely be (1).

[eclarke1]

@ThierryA is this ticket still required in the performance project, if so, should we add to the Infrastructure focus and move to Triage there?

[ThierryA]

@eclarke1 Yes this ticket is still applicable to the project. This one is more horizontal to the current focus area, we briefly discussed having an API (name TBD) focus for horizontal features as such but didn't quite get to decide it. I would tend to say it is ok to leave this issue as is for now and revisit it in due time.

This issue is maybe something @swissspidy or @westonruter could help with.

[swissspidy]

I feel like https://core.trac.wordpress.org/ticket/42438 should get fixed first, to have a simple API to add preloads.

Then this ticket here could be used to explore actually making use of it in core.

[ThierryA]

I feel like https://core.trac.wordpress.org/ticket/42438 should get fixed first, to have a simple API to add preloads.

We could also develop it as an API module here so that it serves as a "feature plugin" for core patch. Either way works, as long as some progress is made 😉

[dainemawer]

Just a question about this...the more power we give end users to be able to "preload" anything the less of a priority and less sense it makes to preload resources. Preloading more than a few items kind of defeats the point. If an API is built to handle preloading, we should ensure that there is explicit guidance around what to preload. Namely, assets that would improve visual impacts such as the LCP image or font files.

As soon as you preload images, font files, multiple JS and CSS files then assets are no longer really "prioritised" - if everything is a priority then nothing is a priority.

In fact I would say this API is worth leveraging if we need to improve LCP metrics for images, see ticket:
#117

[swissspidy]

Providing guidance/documentation definitely makes sense. Don't think we can do anything on the code level for that though.

[westonruter]

Providing guidance/documentation definitely makes sense. Don't think we can do anything on the code level for that though.

If you call wp_add_preload_link() more than X times it could throw a _doing_it_wrong() 😄

[sgomes]

In my opinion a thin wrapper around <link rel=preload> doesn't seem particularly useful, since adding that markup is fairly doable through existing hooks, or in templates. Are there any particular use-cases a preload API would significantly help with?

[jonathanbardo]

One use case we recently had for this was for preloading CSS link that goes inside of a shadow root custom element to prevent a flash of unstyle content. We did easily add the preload instruction in another hook that is in the header but it seems backward and not the right place to do this given there is a resource hint hook.

When browsers see a shadow root they immediately put the content on the page and if the CSS is not inline (for instance as a <link> tag) it will load the resource when it hits your custom component. There is a slight moment when the CSS is not loaded that the markup looks unstyle and create an unpleasant experience. If we add a preload instruction for the css link in the header this solves our problem completely.

[manuelRod]

Hello guys, I didn't see this ticket, however, I was working in trac 42438 and created a patch for it in the core.
I've added preload support with a new function wp_preload_links()
This the P.R: WordPress/wordpress-develop#2505

[mehigh]

This is great. Thank you @manuelRod
Glad to see that it covers the preloading of responsive images too, that's very handy, in addition to all of the other use-cases.

[manuelRod]

Just a little reminder, I've worked on a core patch covering this: https://core.trac.wordpress.org/ticket/42438.
There is a bit of discussion over there, I would love some people chiming in and pushing this forward.

[mehigh]

Let's assign this to @manuelRod as he's following up on trac. I'll add my view there as well.

[felixarntz]

https://core.trac.wordpress.org/ticket/42438 has been completed a year ago, therefore closing this issue.