Intent to Ship: JSON and style support for link rel=modulepreload

174 views
Skip to first unread message

Chromestatus

unread,
Jan 22, 2026, 3:56:22 PM (11 days ago) Jan 22
to blin...@chromium.org, ksc...@microsoft.com
Contact emails
ksc...@microsoft.com

Explainer
No information provided

Specification
https://github.com/whatwg/html/pull/11981

Summary
Adds support for JSON and style module types as <link rel="modulepreload"> destinations. <link rel="modulepreload"> is already supported in Chromium (see https://chromestatus.com/feature/5762805915451392), but it currently only supports preloading script-like module scripts. This feature addresses a functionality gap, as JSON and CSS module scripts are supported in Chromium elsewhere but are not supported as <link rel="modulepreload"> destinations.

Blink component
Blink>DOM

Web Feature ID
modulepreload

Motivation
Style and JSON are fully supported as modules in Chromium (see https://chromestatus.com/feature/5948572598009856 and https://chromestatus.com/feature/5749863620804608), but <link rel=modulepreload> only supports preloading script modules. This feature addresses a gap in the platform. In addition, supporting "style" as a modulepreload destination addresses a pain point identified when using external files with Declarative CSS Modules (see https://chromestatus.com/feature/4790543041298432).

Initial public proposal
https://github.com/whatwg/html/issues/10233

TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
No information provided

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=2004751)

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=303761)

Web developers: No signals

Other signals:

Ergonomics
This feature will increase ergonomics with CSS Module Scripts (see https://chromestatus.com/feature/5948572598009856) and Declarative CSS Module Scripts (see https://chromestatus.com/feature/4790543041298432). No known ergonomics risks.

Activation
No polyfill is necessary, as a module import will succeed regardless of whether it's preloaded or not. In unsupported browsers, it will do nothing.

Security
No security risks.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Debuggability
Basic support via the Network tab in DevTools, which displays preloaded resources from this feature.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
Yes
https://github.com/web-platform-tests/wpt/pull/56617

Flag name on about://flags
No information provided

Finch feature name
No information provided

Non-finch justification
This is not a new feature, just an expansion of an existing feature, so Finch is not necessary.

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/466888680

Measurement
There is already a UseCounter for <link type=modulepreload> (see https://chromestatus.com/metrics/feature/timeline/popularity/2232). I plan on adding an additional UseCounter for style module preloads.

Estimated milestones
Shipping on desktop146
Shipping on Android146
Shipping on WebView146


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5202661416763392?gate=6500470023651328

This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Jan 22, 2026, 9:58:41 PM (11 days ago) Jan 22
to Kurt Catti-Schmidt (SCHMIDT), blink-dev
Issues don't count as formal position requests - can we please file them? See https://www.chromium.org/blink/launching-features/wide-review/#signal-process

Web developers: No signals

Other signals:

Ergonomics
This feature will increase ergonomics with CSS Module Scripts (see https://chromestatus.com/feature/5948572598009856) and Declarative CSS Module Scripts (see https://chromestatus.com/feature/4790543041298432). No known ergonomics risks.

Activation
No polyfill is necessary, as a module import will succeed regardless of whether it's preloaded or not. In unsupported browsers, it will do nothing.

Security
No security risks.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Debuggability
Basic support via the Network tab in DevTools, which displays preloaded resources from this feature.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
Yes
https://github.com/web-platform-tests/wpt/pull/56617

Flag name on about://flags
No information provided

Finch feature name
No information provided

Non-finch justification
This is not a new feature, just an expansion of an existing feature, so Finch is not necessary.
Per https://chromium.googlesource.com/chromium/src/+/HEAD/docs/flag_guarding_guidelines.md#When-is-a-flag-required, we should land this change behind a feature flag, in case things go unexpectedly wrong. Can you do that?

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/466888680

Measurement
There is already a UseCounter for <link type=modulepreload> (see https://chromestatus.com/metrics/feature/timeline/popularity/2232). I plan on adding an additional UseCounter for style module preloads.

Estimated milestones
Shipping on desktop 146
Shipping on Android 146
Shipping on WebView 146


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5202661416763392?gate=6500470023651328

This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69728ee9.050a0220.19f748.008b.GAE%40google.com.

Kurt Catti-Schmidt (SCHMIDT)

unread,
Jan 23, 2026, 12:35:22 PM (10 days ago) Jan 23
to Mike Taylor, blink-dev
Hi Mike,

Thanks for taking a look. Standards Positions for WebKit and Mozilla have been filed and added to chromestatus. I also added the Finch feature name to chromestatus and updated the fields in the email below.

-Kurt

From: Mike Taylor <mike...@chromium.org>
Sent: Thursday, January 22, 2026 6:58 PM
To: Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style support for link rel=modulepreload
 

On 1/22/26 3:56 p.m., Chromestatus wrote:

Contact emails
Explainer
No information provided

Specification
Summary
Adds support for JSON and style module types as <link rel="modulepreload"> destinations. <link rel="modulepreload"> is already supported in Chromium (see https://chromestatus.com/feature/5762805915451392), but it currently only supports preloading script-like module scripts. This feature addresses a functionality gap, as JSON and CSS module scripts are supported in Chromium elsewhere but are not supported as <link rel="modulepreload"> destinations.

Blink component
Web Feature ID
Motivation
Style and JSON are fully supported as modules in Chromium (see https://chromestatus.com/feature/5948572598009856 and https://chromestatus.com/feature/5749863620804608), but <link rel=modulepreload> only supports preloading script modules. This feature addresses a gap in the platform. In addition, supporting "style" as a modulepreload destination addresses a pain point identified when using external files with Declarative CSS Modules (see https://chromestatus.com/feature/4790543041298432).

Initial public proposal
TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
Issues don't count as formal position requests - can we please file them? See https://www.chromium.org/blink/launching-features/wide-review/#signal-process

Web developers: No signals

Other signals:

Ergonomics
This feature will increase ergonomics with CSS Module Scripts (see https://chromestatus.com/feature/5948572598009856) and Declarative CSS Module Scripts (see https://chromestatus.com/feature/4790543041298432). No known ergonomics risks.

Activation
No polyfill is necessary, as a module import will succeed regardless of whether it's preloaded or not. In unsupported browsers, it will do nothing.

Security
No security risks.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Debuggability
Basic support via the Network tab in DevTools, which displays preloaded resources from this feature.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
Flag name on about://flags
No information provided

Finch feature name
ModulePreloadStyleJson

Mike Taylor

unread,
Jan 27, 2026, 2:34:32 PM (6 days ago) Jan 27
to Kurt Catti-Schmidt (SCHMIDT), blink-dev

Thanks - looks like we're just waiting for annevk (or another HTML editor) to merge https://github.com/web-platform-tests/wpt/pull/56617 and https://github.com/whatwg/html/pull/11981#issuecomment-3771477272?

Yoav Weiss (@Shopify)

unread,
Jan 28, 2026, 2:57:30 AM (6 days ago) Jan 28
to blink-dev, Mike Taylor, blink-dev, ksc...@microsoft.com
On Tuesday, January 27, 2026 at 8:34:32 PM UTC+1 Mike Taylor wrote:

Thanks - looks like we're just waiting for annevk (or another HTML editor) to merge https://github.com/web-platform-tests/wpt/pull/56617 and https://github.com/whatwg/html/pull/11981#issuecomment-3771477272?


On 1/23/26 12:35 p.m., Kurt Catti-Schmidt (SCHMIDT) wrote:
Hi Mike,

Thanks for taking a look. Standards Positions for WebKit and Mozilla have been filed and added to chromestatus. I also added the Finch feature name to chromestatus and updated the fields in the email below.

-Kurt

From: Mike Taylor <mike...@chromium.org>
Sent: Thursday, January 22, 2026 6:58 PM
To: Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style support for link rel=modulepreload
 

On 1/22/26 3:56 p.m., Chromestatus wrote:

Contact emails
Explainer
No information provided

Can you expand on how developers are supposed to use this? Would they need to add particular attributes that would let the browser know that the modules preloaded are CSS/JSON?
Is there a way for developers to detect browser support for this? What happens if there isn't? Is there a risk of preloading modules that would then not be used? 


Specification
Summary
Adds support for JSON and style module types as <link rel="modulepreload"> destinations. <link rel="modulepreload"> is already supported in Chromium (see https://chromestatus.com/feature/5762805915451392), but it currently only supports preloading script-like module scripts. This feature addresses a functionality gap, as JSON and CSS module scripts are supported in Chromium elsewhere but are not supported as <link rel="modulepreload"> destinations. 

Blink component
Web Feature ID
Motivation
Style and JSON are fully supported as modules in Chromium (see https://chromestatus.com/feature/5948572598009856 and https://chromestatus.com/feature/5749863620804608), but <link rel=modulepreload> only supports preloading script modules. This feature addresses a gap in the platform. In addition, supporting "style" as a modulepreload destination addresses a pain point identified when using external files with Declarative CSS Modules (see https://chromestatus.com/feature/4790543041298432).

Initial public proposal
TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
Issues don't count as formal position requests - can we please file them? See https://www.chromium.org/blink/launching-features/wide-review/#signal-process

Links to the positions filed? 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Kurt Catti-Schmidt (SCHMIDT)

unread,
Jan 28, 2026, 1:07:02 PM (5 days ago) Jan 28
to Yoav Weiss (@Shopify), blink-dev, Mike Taylor
Hi Yoav,

Thanks for the input. Responses below and inline.

  • Can you expand on how developers are supposed to use this? Would they need to add particular attributes that would let the browser know that the modules preloaded are CSS/JSON? Is there a way for developers to detect browser support for this? What happens if there isn't? Is there a risk of preloading modules that would then not be used? 

Good point, there's no explainer and the summary was missing examples as to how this is supposed to be used, so this has been addressed with the new sentence "Style modules can be preloaded with <link rel="modulepreload" as="style" href="..."> and JSON modules can be preloaded with <link rel="modulepreload" as="json" href="...">." The "as" attribute is necessary to opt into these new supported module types, and absence of it defaults to a script modulepreload.

For this feature, developers don't need to detect support, as preloads are a hint for the renderer to preload for a later import, and they can't guarantee that a preload has completed by the time it's used. If the import was preloaded, it's a cache hit, and if not, it's a fetch - either way there's still an import, so there's no need to detect support. For browsers that don't support modulepreload, a <link rel="modulepreload"> tag does nothing, and for browsers that only support script modulepreloads (and not style or JSON), <link rel="modulepreload" as="style"> was considered invalid and will also do nothing (see wpt.live/preload/modulepreload-as.html). Note that some browsers do log to the console when invalid values are used for modulepreloads.

Preloading modules that are not used later wastes bandwidth, but there's no risk of site compat. Many browsers will also notify developers of this situation in developer tools - Chrome logs "The resource <URL> was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.".

  • Links to the positions filed? 

I updated the links inline in the original email, but they look similar to the old links, so it probably looked like I didn't update anything. Here they are separately: https://github.com/mozilla/standards-positions/issues/1342 and Support style and JSON as modulepreload destinations · Issue #603 · WebKit/standards-positions.


-Kurt

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>
Sent: Tuesday, January 27, 2026 11:57 PM
To: blink-dev <blin...@chromium.org>
Cc: Mike Taylor <mike...@chromium.org>; blink-dev <blin...@chromium.org>; Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style support for link rel=modulepreload
 


On Tuesday, January 27, 2026 at 8:34:32 PM UTC+1 Mike Taylor wrote:

Thanks - looks like we're just waiting for annevk (or another HTML editor) to merge https://github.com/web-platform-tests/wpt/pull/56617 and https://github.com/whatwg/html/pull/11981#issuecomment-3771477272?


On 1/23/26 12:35 p.m., Kurt Catti-Schmidt (SCHMIDT) wrote:
Hi Mike,

Thanks for taking a look. Standards Positions for WebKit and Mozilla have been filed and added to chromestatus. I also added the Finch feature name to chromestatus and updated the fields in the email below.

-Kurt

From: Mike Taylor <mike...@chromium.org>
Sent: Thursday, January 22, 2026 6:58 PM
To: Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style support for link rel=modulepreload
 

On 1/22/26 3:56 p.m., Chromestatus wrote:

Contact emails
Explainer
No information provided

Can you expand on how developers are supposed to use this? Would they need to add particular attributes that would let the browser know that the modules preloaded are CSS/JSON?
Is there a way for developers to detect browser support for this? What happens if there isn't? Is there a risk of preloading modules that would then not be used? 

Good point, there's no explainer and the summary was missing examples as to how this is supposed to be used, so this has been addressed with the new sentence "Style modules can be preloaded with <link rel="modulepreload" as="style" href="..."> and JSON modules can be preloaded with <link rel="modulepreload" as="json" href="...">." The "as" attribute is necessary to opt into these module types.

For this feature, developers don't need to detect support, as preloads are a hint for the renderer to preload for a later import. If the import was preloaded, it's a cache hit, and if not, it's a fetch - either way there's still an import statement, so there's no need to detect support. For browsers that don't support modulepreload, a <link rel="modulepreload" as="style"> does nothing, and for browsers that only support script modulepreloads, <link rel="modulepreload" as="style"> is considered invalid and will also do nothing (see wpt.live/preload/modulepreload-as.html). Note that some browsers do log to the console when invalid values are used for modulepreloads, but this won't break any sites.

Preloading modules that are not used later wastes bandwidth, but there's no risk of site compat. Many browsers will also notify this in developer tools - Chrome logs "The resource <URL> was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.".



Specification
Summary
Adds support for JSON and style module types as <link rel="modulepreload"> destinations. <link rel="modulepreload"> is already supported in Chromium (see https://chromestatus.com/feature/5762805915451392), but it currently only supports preloading script-like module scripts. This feature addresses a functionality gap, as JSON and CSS module scripts are supported in Chromium elsewhere but are not supported as <link rel="modulepreload"> destinations. Style modules can be preloaded with <link rel="modulepreload" as="style" href="..."> and JSON modules can be preloaded with <link rel="modulepreload" as="json" href="...">.

Blink component
Web Feature ID
Motivation
Style and JSON are fully supported as modules in Chromium (see https://chromestatus.com/feature/5948572598009856 and https://chromestatus.com/feature/5749863620804608), but <link rel=modulepreload> only supports preloading script modules. This feature addresses a gap in the platform. In addition, supporting "style" as a modulepreload destination addresses a pain point identified when using external files with Declarative CSS Modules (see https://chromestatus.com/feature/4790543041298432).

Initial public proposal
TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
Issues don't count as formal position requests - can we please file them? See https://www.chromium.org/blink/launching-features/wide-review/#signal-process

Links to the positions filed? 

I updated the links inline in the original email, so it probably looks like I missed it. Here they are: https://github.com/mozilla/standards-positions/issues/1342 and Support style and JSON as modulepreload destinations · Issue #603 · WebKit/standards-positions.


Done via ModulePreloadStyleJson

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
Measurement
There is already a UseCounter for <link type=modulepreload> (see https://chromestatus.com/metrics/feature/timeline/popularity/2232). I plan on adding an additional UseCounter for style module preloads.

Estimated milestones
Shipping on desktop
146
Shipping on Android
146
Shipping on WebView
146


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss (@Shopify)

unread,
Jan 28, 2026, 2:59:06 PM (5 days ago) Jan 28
to Kurt Catti-Schmidt (SCHMIDT), blink-dev, Mike Taylor
On Wed, Jan 28, 2026 at 7:06 PM Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com> wrote:
Hi Yoav,

Thanks for the input. Responses below and inline.

  • Can you expand on how developers are supposed to use this? Would they need to add particular attributes that would let the browser know that the modules preloaded are CSS/JSON? Is there a way for developers to detect browser support for this? What happens if there isn't? Is there a risk of preloading modules that would then not be used? 

Good point, there's no explainer and the summary was missing examples as to how this is supposed to be used, so this has been addressed with the new sentence "Style modules can be preloaded with <link rel="modulepreload" as="style" href="..."> and JSON modules can be preloaded with <link rel="modulepreload" as="json" href="...">." The "as" attribute is necessary to opt into these new supported module types, and absence of it defaults to a script modulepreload.

For this feature, developers don't need to detect support, as preloads are a hint for the renderer to preload for a later import, and they can't guarantee that a preload has completed by the time it's used. If the import was preloaded, it's a cache hit, and if not, it's a fetch - either way there's still an import, so there's no need to detect support. For browsers that don't support modulepreload, a <link rel="modulepreload"> tag does nothing, and for browsers that only support script modulepreloads (and not style or JSON), <link rel="modulepreload" as="style"> was considered invalid and will also do nothing (see wpt.live/preload/modulepreload-as.html).

That's great!!

Kurt Catti-Schmidt (SCHMIDT)

unread,
1:12 PM (8 hours ago) 1:12 PM
to Mike Taylor, blink-dev
Both of those PR's are now merged.

From: Mike Taylor <mike...@chromium.org>
Sent: Tuesday, January 27, 2026 11:34 AM

To: Kurt Catti-Schmidt (SCHMIDT) <ksc...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: JSON and style support for link rel=modulepreload
 

Alex Russell

unread,
3:06 PM (6 hours ago) 3:06 PM
to blink-dev, ksc...@microsoft.com, blink-dev, Mike Taylor
An enthusiastic LGTM1; thanks for dotting i's and crossing t's.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages