Allow Remix applications to control <link rel="modulepreload"> behavior through a flag

[backjo]

Remix today automatically generates <link rel="modulepreload" /> entries for all of the client-side JS files needed on a page. While this is really helpful for eliminating a potential dependency waterfall issue around loading JS, it introduces a different performance issue in Chrome for some applications. As documented in the linked discussions and issues below, Chrome loads these modulepreload entries aggressively - including in our case and others, at the cost of render-blocking assets like CSS. In our application, which has about 28 different JS modulepreloads (most small with a few larger files), disabling modulepreload (through a hacky monkeypatch) caused our FCP to improve by approximately 50% on the standard Lighthouse Mobile CWV assessment.

We believe that users should be able to direct this behavior through a flag and choose which compromise (FCP vs time to interactive) they want to make, instead of being forced today to compromise FCP for a potentially better time to interactive.

See discussions at #6685 and vitejs/vite#5991 for overall issue context. Please feel free to close as a duplicate of the linked discussion if it's considered as such - it was unclear whether there was a explicit feature request ask out of it.

[scottlepich]

Adding modulepreload to all of these resources makes them download in high priority. In addition, if there are more resources added than a Mobile browser can download in parallel as described above, there is a compounding effect as each tranche is downloaded in sequence.

The result of these factors can block rendering and the main thread, hurting perceived content performance as measured by Google's lighthouse scores for both Largest Contentful Paint (LCP) and Interaction to Next Paint (INP).

Agree with @backjo: it would be really fantastic to have some control over this attribute.