diff --git a/server/lib/set-headers-to-preload-assets.js b/server/lib/set-headers-to-preload-assets.js index 689edd6..409eb72 100644 --- a/server/lib/set-headers-to-preload-assets.js +++ b/server/lib/set-headers-to-preload-assets.js @@ -18,12 +18,46 @@ function setHeadersToPreloadAssets(res, pageOptions) { const { styles, preloadScripts } = getDependenciesForEntryPointName(pageOptions.entryPoint); + // XXX: Should we add `nopush` to the `Link` headers here? Many servers initiate an + // HTTP/2 Server Push when they encounter a preload link in HTTP header form + // otherwise. Do we want/care about that (or maybe we don't)? (mentioned in + // https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf#6f54) + const styleLinks = styles.map((styleUrl) => { return `<${styleUrl}>; rel=preload; as=style`; }); + // TODO: We should preload fonts as well. + // + // We use `cors` because fonts are fetched with "CORS mode 'cors'" (see + // https://drafts.csswg.org/css-fonts/#font-fetching-requirements) + // + // TODO: Should this be `cors` or `crossorigin`? + // https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#headers shows + // `crossorigin` but + // https://html.spec.whatwg.org/multipage/links.html#link-type-preload (the spec) says + // `cors` so I'm not sure. + // + // `Link: ; rel=preload; as=font; cors` + + // We use `rel=modulepreload` instead of `rel=preload` for the JavaScript modules + // because it's a nice dedicated thing to handle ESM modules that not only downloads + // and puts it in the cache like a normal `rel=preload` but the browser also knows + // it's a JavaScript module now and can parse/compile it so it's ready to go. + // + // Also as a note: `