`importance` is horribly long
mnot opened this issue · 9 comments
Considering how much this might show up in HTML, APIs and HTTP headers, can we come up with something shorter?
Especially HTTP headers, where HPACK/QPACK won't be able to offer a lot of benefit (as there will be a lot of entropy in the link part of the header, presumably).
Thanks for the feedback, @mnot. Our original intention was to opt for priority, but we wanted to avoid folks thinking this guarantee a specific netstack priority level. With my bikeshed hat on..
- priority (revisit..)
- rank
- effect
- weight
cc @domfarolino @yoavweiss for further brainstorming.
I'd be OK revisiting priority. I guess since the spec's name is Priority Hints, that might be enough to make it clear to developers that even thought the attr name is priority, they are not actually setting the priority explicitly, but I do worry about the confusion. Would like to hear developer opinions on importance vs priority, given the fact that it is a hint.
I like priority. load-priority could be good if want to be exact.
I'm not sure the length is enough of a concern to make the attribute application less clear (what it affects, that it is just a hint, etc).
load-priority isn't any shorter. The individual enums for importance are short (high, low, auto) which helps a bit. If we merged it with loading and changed the enums then we'd be around the same length with something like loading=urgent.
The attribute is optional so it doesn't need to be added to the headers unless the defaults need to be overridden and I expect that case is going to be particularly rare (or at least the need to override will - it's always possible it will get sprayed by some automation).
A preload in HTTP response headers gets processed early. If it is on a HTML response then before ANYTHING in the HTML and if it is on a subresource then before the subresource is processed. On a HTML response, any preloads in the response headers had better be important or they are going to jump ahead of important resources anyway by virtue of being processed first and it is highly unlikely that any overrides are going to do anything meaningful.
On a subresource, things get to be a bit more subtle. The best case I can think of is for a JS module that imports other JS modules, a preload hint in the HTTP response header can start the browser downloading the subresources a bit sooner (before the script needs to be parsed and evaluated). The module doesn't necessarily have the context of the page that it is being loaded in though and assuming the preloads are important (or not) may not match reality for where they are embedded.
Having the preloads for the imports in the HTML markup after the script tag would be optimal but that aside, a module with a LOT of imports, all preloaded is probably the worst-case scenario for the header compression and in that case, the extra bytes for an importance override on all of them is probably the least of the issues.
If the lack of HPACK/QPACK compression for header substrings is an issue then maybe that should be considered for a newer revision. There is likely a fair amount of repetition in headers in the wild that aren't exact matches. Even just for the link header, as=<type>, rel=preload, URL fragments are all likely fairly repetitive if a single connection has multiple preload headers.
@miketaylr It actually got worse because the attribute associated with preload that would wind up in headers is "fetchpriority" which is 3 characters longer.
That said, we added language to the spec and explainer to encourage using it sparingly so under normal conditions it should be a non-issue (and if there are enough preloads in headers with specified importance to matter from a bandwidth perspective, the page has a lot more pressing issues).
It is important to note that changing the priority of one resource usually comes at the cost of another resource so hints should be applied sparingly. Marking everything in the document as high-priority will likely make for a worse user experience but correctly tagging a few resources that the browser would otherwise not load optimally can have a huge benefit.
@mnot WDYT?
This can be closed given #64, right?
@miketaylr It actually got worse because the attribute associated with preload that would wind up in headers is "fetchpriority" which is 3 characters longer.
Sorry yeah, I meant closed as HORRIBLY LONGER. 🤪
If it only goes on a few things, it may not be worth worrying about -- but I suspect that whatever we write, some will spray it all over everything :-/
I was thinking of something like imp -- i.e., abbreviating it.
I think this should be closed unless there's a reason to revisit this. In HTML it's named fetchpriority and in Fetch it's just priority.
It doesn't end up exposed directly as an HTTP header at the moment. Instead the values get mapped to transport layer priority semantics, whatever those may be.