Header preload and CSS / JavaScript

[annevk]

To parse CSS you need to know quirks mode / no-quirks in advance and have an encoding. For JavaScript you also need an encoding. We could assume no-quirks and then throw away the results if it turns out to be quirks, but it would be good to have this explicitly tested to ensure implementations don't take the wrong shortcuts.

(We might also consider some kind of flag where the developer can give guarantees about the resource so the browser doesn't have to do things speculatively and potentially throw away results.)

[annevk]

To make it a little more explicit, it would be good to encourage folks to at least define charset at the HTTP level when they preload resources with 103 responses as at that point we do not know what the fallback encoding is (from the document that follows the 103).

[snuggs]

@tmornini interesting discovery on HTTP 103. Let's discuss next time we speak.

[yoavweiss]

I can see other problems with early hints and preload (e.g. CSP & Referrer Policy), but the download of CSS and Javascript could be kicked off early without knowing their presumed charsets, assuming they are only parsed after the HTML starts arriving and the charset is known.

[annevk]

That is a good point, we cannot really download them until we know the CSP and Referrer Policy...

[yoavweiss]

Another problem is cookies, which may not to be properly set, if the app relies on the HTML's response header to set them.

[tmornini]

@snuggs This seems like a MICRO OPTIMIZATION at best.

Having a hard time imagining building anything where the body takes long enough to compute to make this worthwhile -- and how I'd know what hints to throw without fishing them out of the body in the first place.

Perhaps if I sleep on it it'll make sense in the morning. 😄

[yoavweiss]

@tmornini See https://blog.yoav.ws/being_pushy/ for the use-case and how it's handled with H2 server push. Theoretically early hints + preload can tackle the same use-case (with an RTT worth of extra delay). In practice, there are significant hurdles to surmount before that'll be implementable.

[tmornini]

@yoavweiss 👍🏻

[tmornini]

@yoavweiss

Where I wrote:

the body takes long enough to compute to make this worthwhile

Matches the concept of “server think time” in that article.

For what it’s worth, I think 103 is a very bad idea.

HTTP is fundamentally request/response.

103 makes it request/response-response-adinfinitun

It adds complexity and makes HTTP harder to reason about. 👎🏻

[annevk]

HTTP has always had 1xx responses so this doesn't really change anything about HTTP.

[annevk]

But also, this is getting rather off-topic.

[tmornini]

@annevk Fair enough 👍

[yoavweiss]

Closing as there's nothing actionable here from preload's perspective. @annevk - feel free to reopen if you feel otherwise

[annevk]

Part of OP would mean introducing a new feature, no? Also, reporters typically cannot reopen issues on GitHub as they don't have the authority...

[annevk]

Also in general it seems these considerations need to be spelled out somewhere so new implementers are not led astray into making optimizations that are not doable.

[yoavweiss]

Also in general it seems these considerations need to be spelled out somewhere so new implementers are not led astray into making optimizations that are not doable.

Adding a note to that effect seems reasonable. I'll reopen.

Regarding the charset bits for:

We might also consider some kind of flag where the developer can give guarantees about the resource so the browser doesn't have to do things speculatively and potentially throw away results.

Isn't that already possible with the type attribute and adding a charset to it?

(Admittedly, quirks mode may require a separate flag. I'm not convinced the potential optimization will encourage adoption of such a flag)

[annevk]

I don't think a type attribute is looked at for script loading (at least not for encodings).

[yoavweiss]

type processing was added to preload at #87 but later removed when integrating the processing with HTML (since it's already processed elsewhere)

I agree that if we want to use that as a hint to the parser, we'd need to better tie these concepts in the spec. I'm currently not convinced there's a huge need for that.

[yoavweiss]

Going back to this after a long while (sorry!). Seems like the only actionable bit is to add a note that implementations should not start processing preloaded resources before:
a) They know the (no) quirks mode for CSS.
b) They know the document's encoding for both CSS and JS.

I think we should dive into type related optimizations only after we see this is a significant problem IRL. I suspect it's not.