4 ms·

"link" headers giving asset references with `rel="preload"` work pretty fine for this purpose, although it can kick start only after the first response comes in

by sriku 6y ago

"link" headers giving asset references with `rel="preload"` work pretty fine for this purpose, although it can kick start only after the first response comes in. Browsers seem to do the right thing on encountering this and all the "preload" resources get fetched "in parallel" .. meaning the server doesn't wait for resource1 to finish before starting to stream resource2 and on the network panel they all seem to be coming in simultaneously .. each taking roughly the same time as when fetched from the server sequentially. Header pattern - link: </somewhere/something.png>; rel="preload"; as="image", </somewhere/something.js>; rel="preload"; as="script", ... This saves considerable page load time if you maintain granular resources and simplifies build and deploy by permitting that granularity in the first place .. and the resources can be parsed+compiled on multiple cores (not sure which browser engines do that, but would be possible). This mechanism seems effective enough in cases where HTTP/2 push could be beneficial. Thoughts by push advocates/critics? edit: .. and this works well with the cache.

treve 6y ago
Yeah this works well for specifically this case. There's other cases that I feel we haven't had a good chance to explore, specifically as it pertains to APIs. I wanted to kill many compound HTTP request within a single one. Many API formats pack many logical entities in a single response, and that doesn't work well with caches. Wouldn't it be nice if the next paradigm shift in API development goes towards every entity being addressable, cacheable by a browser but not suffering from the penalty of having to do many requests? That's mostly where my work on Prefer-Push came from. I wrote a much longer article about this use-case earlier this year: https://evertpot.com/h2-parallelism/ https://evertpot.com/h2-parallelism/
- nsomaru 6y ago
  Isn’t a URL a “uniform resource locator” which effectively addresses an “entity” conceptually. It would seem then that your gripe is with the design of particular APIs?
  - treve 6y ago
    Yes, nearly all of them. For example: consider an operation like 'give me a list of articles', most APIs will combine this result in a single request/response. But if each article has a URI as well, they won't end up in a browser cache by their own address.
- svrtknst 6y ago
  Maybe your familiar with it already, but Joe Armstrong had some similar ideas about addressable entitites: https://joearms.github.io/published/2015-03-12-The_web_of_names.html https://joearms.github.io/published/2015-03-12-The_web_of_na...
  - macintux 6y ago
    Joe was such a prolific thinker. I could listen to him talk about anything.
- eterps 6y ago
  > Yeah this works well for specifically this case. What do you think of the opinion of Kévin Dunglas (Vulcain) in this case. Too optimistic? See: https://github.com/dunglas/vulcain/issues/70#issuecomment-726120834 https://github.com/dunglas/vulcain/issues/70#issuecomment-72...
  - treve 6y ago
    I'm aware of the project but don't know enough details of this feature to really comment on it! I imagine that it addresses some, but not all of the potential benefits H/2 push could have.
    - eterps 6y ago
      Thanks. Do you still see ways/options leading to that 'perfect world' scenario? Or does that seem unrealistic for years to come given the current situation?
      - treve 6y ago
        I may not have a full understanding on the project, but I have doubt. One benefit of Push is that the server can potentially generate a group of responses together, which can be much cheaper than generating them individually. When prefetch is used instead of push, the decision on when and what to fetch is on the client, so if the server could generate them as a group, a proxy like Vulcain would have to buffer the results somehow until the browser asks for them, which is not ideal. I might be wrong, but I don't think their server ever intended to fix the Query+1 issue. If Vulcain and Push already worked well for you in the past, maybe it's still as effective without Push though!
- mariusor 6y ago
  Your article mirrors very well the use case I wanted to solve in one API I'm working on. Thank you for detailing the matter so thoroughly.
kmonsen 6y ago
it’s a little bit different in that with preload the broader needs to parse the content first, but with push it was coming as a header and could be done earlier. I think.
byroot 6y ago
> although it can kick start only after the first response comes in There is a RFC for a new 103 Early Hint response: https://tools.ietf.org/html/rfc8297 https://tools.ietf.org/html/rfc8297 This would allow to to send `link` headers before the full response was generated. However no browser support it right now, and Chrome simply added instrumentation to later decide if they'll implement it. The problem is nobody want to bother implementing it if it doesn't bring anything yet, so we're kinda stuck in a chiken and egg situation. If some Chrome or other browser developers are around: please implement 103 Early Hints support.
youngtaff 6y ago
Chrome set's the exclusive flag on it's H2 requests so although the requests might be dispatched in parallel servers may still queue the responses. Preload is as much of a foot gun as it is a useful tool - it's way too easy to preload content that then delays other more critical content, and it takes time to find the balance

by sriku 6y ago

treve 6y ago

Yeah this works well for specifically this case. There's other cases that I feel we haven't had a good chance to explore, specifically as it pertains to APIs. I wanted to kill many compound HTTP request within a single one. Many API formats pack many logical entities in a single response, and that doesn't work well with caches. Wouldn't it be nice if the next paradigm shift in API development goes towards every entity being addressable, cacheable by a browser but not suffering from the penalty of having to do many requests? That's mostly where my work on Prefer-Push came from. I wrote a much longer article about this use-case earlier this year: https://evertpot.com/h2-parallelism/ https://evertpot.com/h2-parallelism/

nsomaru 6y ago
Isn’t a URL a “uniform resource locator” which effectively addresses an “entity” conceptually. It would seem then that your gripe is with the design of particular APIs?
- treve 6y ago
  Yes, nearly all of them. For example: consider an operation like 'give me a list of articles', most APIs will combine this result in a single request/response. But if each article has a URI as well, they won't end up in a browser cache by their own address.
svrtknst 6y ago
Maybe your familiar with it already, but Joe Armstrong had some similar ideas about addressable entitites: https://joearms.github.io/published/2015-03-12-The_web_of_names.html https://joearms.github.io/published/2015-03-12-The_web_of_na...
- macintux 6y ago
  Joe was such a prolific thinker. I could listen to him talk about anything.
eterps 6y ago
> Yeah this works well for specifically this case. What do you think of the opinion of Kévin Dunglas (Vulcain) in this case. Too optimistic? See: https://github.com/dunglas/vulcain/issues/70#issuecomment-726120834 https://github.com/dunglas/vulcain/issues/70#issuecomment-72...
- treve 6y ago
  I'm aware of the project but don't know enough details of this feature to really comment on it! I imagine that it addresses some, but not all of the potential benefits H/2 push could have.
  - eterps 6y ago
    Thanks. Do you still see ways/options leading to that 'perfect world' scenario? Or does that seem unrealistic for years to come given the current situation?
    - treve 6y ago
      I may not have a full understanding on the project, but I have doubt. One benefit of Push is that the server can potentially generate a group of responses together, which can be much cheaper than generating them individually. When prefetch is used instead of push, the decision on when and what to fetch is on the client, so if the server could generate them as a group, a proxy like Vulcain would have to buffer the results somehow until the browser asks for them, which is not ideal. I might be wrong, but I don't think their server ever intended to fix the Query+1 issue. If Vulcain and Push already worked well for you in the past, maybe it's still as effective without Push though!
mariusor 6y ago
Your article mirrors very well the use case I wanted to solve in one API I'm working on. Thank you for detailing the matter so thoroughly.

kmonsen 6y ago

it’s a little bit different in that with preload the broader needs to parse the content first, but with push it was coming as a header and could be done earlier. I think.

byroot 6y ago

> although it can kick start only after the first response comes in There is a RFC for a new 103 Early Hint response: https://tools.ietf.org/html/rfc8297 https://tools.ietf.org/html/rfc8297 This would allow to to send `link` headers before the full response was generated. However no browser support it right now, and Chrome simply added instrumentation to later decide if they'll implement it. The problem is nobody want to bother implementing it if it doesn't bring anything yet, so we're kinda stuck in a chiken and egg situation. If some Chrome or other browser developers are around: please implement 103 Early Hints support.

youngtaff 6y ago

Chrome set's the exclusive flag on it's H2 requests so although the requests might be dispatched in parallel servers may still queue the responses. Preload is as much of a foot gun as it is a useful tool - it's way too easy to preload content that then delays other more critical content, and it takes time to find the balance