Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Auto generated preload links should respect fetchpriority if specified #26810

Closed
liuyenwei opened this issue May 12, 2023 · 5 comments
Closed
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@liuyenwei
Copy link
Contributor

React version: 18.3.0-canary-a389046a5-20230512

Steps To Reproduce

  1. Server render a React component that renders either <script> or <link> tags with fetchpriority set
  2. Observe that React will add <link rel="preload"> links for each of the discovered resources but without the same fetchpriority set.

Link to code example:

The current behavior

Currently, if we server render a component such as the one below:

<html lang="en">
  <head>
    <link rel="stylesheet" href="/styles.css" fetchpriority="low" ></link>
  </head>
  <body>
    <script src="/script.js" fetchpriority="low" ></script>
  </body>
</html>

React will also render preload links for the script and link but without the fetchpriority set:

<head>
    <link rel="preload" as="style" href="/styles.css" />
    <link rel="preload" as="script" href="/script.js" />
    <link rel="stylesheet" href="/styles.css" fetchpriority="low" ></link>
  </head>
  <body>
    <script src="/script.js" fetchpriority="low"></script>
  </body>

The result is that both styles.css and script.js are fetched with fetchpriority set to high

The expected behavior

When generating preload links for script and link components, React should respect fetchpriority if specified.

@liuyenwei liuyenwei added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label May 12, 2023
@liuyenwei
Copy link
Contributor Author

Looking through the code, it seems that this should be a straightforward fix by making a change here and here

If that sounds correct (and there isn't any disagreement about the expected behavior) - I'm happy to push up a PR to address this.

@gaearon
Copy link
Collaborator

gaearon commented May 16, 2023

cc @gnoff

@gnoff
Copy link
Collaborator

gnoff commented May 16, 2023

@liuyenwei PR would be welcome!

@liuyenwei
Copy link
Contributor Author

@gnoff #26826

@gaearon
Copy link
Collaborator

gaearon commented May 23, 2023

Closing per #26826 (review).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

3 participants