Add preload link headers for downstream Cloudflare early hints (assets download before the page is rendered) #171
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MadLittleMods
added
T-Enhancement
MadLittleMods
added a commit
that referenced
this pull request
Apr 26, 2023
Follow-up to #171 and #175 where they broke because we went from scripts to modules. Part of #132 Before this PR, we were seeing these warning in the Chrome devtools console: ``` A preload for 'foo' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute. ``` This is caused by a credentials mode mismatch between the `<script type="module">` tag and the `Link` header. A `<script type="module">` with no `crossorigin` attribute indicates a credentials mode of `omit` and a naive `Link: </foo-url>; rel=preload; as=script;` has a default credentials mode of `same-origin`, hence the mismatch and warning we're seeing. We could set the credentials mode to match using `Link: </foo-url>; rel=preload; as=script; omit` but there is an even better option! We can use the dedicated `Link: </foo-url>; rel=modulepreload` link type which not only downloads and puts the the file in the cache like a normal preload but the browser also knows it's a JavaScript module now and can parse/compile it so it's ready to go. --- Future consideration: Adding `nopush` to preload link headers. 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) --- References for preload `Link` headers: - https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf#6f54 - https://html.spec.whatwg.org/multipage/links.html#link-type-preload - https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#headers - https://developer.chrome.com/blog/modulepreload/#ok-so-why-doesnt-link-relpreload-work-for-modules
MadLittleMods
deleted the
madlittlemods/32-add-preload-link-headers-for-cf-early-hints
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add preload link headers for downstream Cloudflare early hints.
Because it takes us at best several seconds to request information from a homeserver and then server-side render the page, the browser has to wait for the response before it can even try loading the necessary assets. With this change that facilitates early hints, the browser can preload all of the assets necessary before we are done generating the response and will be ready to go by the time we're all done on the server.
Fix #32
Part of #132
Tracking actually enabling early hints in Cloudflare in the deployment issue: https://github.com/vector-im/sre-internal/issues/2079
To demonstrate the problem, see the waterfall
Dev notes
Cloudflare: