[wp-trac] [WordPress Trac] #42438: preload is missing from ressource hints.

[WordPress Trac]

#42438: preload is missing from ressource hints.
------------------------------------------+-------------------------
 Reporter:  nico23                        |       Owner:  swissspidy
     Type:  defect (bug)                  |      Status:  assigned
 Priority:  normal                        |   Milestone:  5.0
Component:  Script Loader                 |     Version:  4.9
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+-------------------------

Comment (by igrigorik):

 Replying to [comment:5 westonruter]:
 > I just ran across this as I was looking to add `<link rel="preload"
 as="script" href="https://cdn.ampproject.org/v0.js">` to the AMP plugin.
 >
 > While preload != resource hints it seems the existing resource hints API
 in WordPress is well suited for preload. For example, with
 [attachment:"add_preload_to_ressource_hints.patch"]:
 >
 > {{{#!php
 > <?php
 > add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
 >       if ( 'preload' === $relation_type ) {
 >               $urls[] = array(
 >                       'rel'  => 'preload',
 >                       'as'   => 'script',
 >                       'href' => 'https://cdn.ampproject.org/v0.js',
 >               );
 >       }
 >       return $urls;
 > }, 10, 2 );
 > }}}
 >
 > @igrigorik Would this be bad?

 Not sure if "bad" is the right term, but at a risk of being pedantic..
 personally I _would_ prefer if preload was exposed as standalone and
 separate API: "hints" have a different semantic and UA behavior from
 preload and merging them into the same API might cause unnecessary
 confusion for a bunch of folks.

 If I could make a wish, I think it would be:

 - deprecate `as` and `pr` attributes on `wp_resource_hints`
 - introduce `wp_preload` with support for `as` *and* enforce that `as`
 must be provided

 Splitting these into separate top level APIs matches the spec behavior and
 intent, and I think it would help developers navigate the requirements
 much more clearly too.

 > As for the `pr` attribute in `wp_resource_hints()`, it's just allowing
 for the attribute to be used, it doesn't mandate it. We could add a
 special condition to `_doing_it_wrong()` if that attribute is provided.
 Likewise, we could call `_doing_it_wrong()` if the `as` attribute is used
 with anything other than `rel=preload`.

 Yeah, I think could work. This wouldn't be my first choice from overall
 design perspective, but it would get the job done.

 Q: Is there a much higher lift to implement and ship separate `wp_preload`
 API?

 > Also, does it matter the order of the links? Should `preload` links come
 after resource hint links?

 No, the order does not matter.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42438#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform