- From: youennf <notifications@github.com>
- Date: Fri, 22 Mar 2019 16:05:33 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/881/c475810539@github.com>
Overall, I would tend to go with the minimum proposal to have a functional <link prefetch> targeting navigation loads. Some additional questions/observations: 1. Is prefetch sometimes/mainly/solely targeting (top) navigation loads. It seems to be the case since we want prefetch (at least navigation cross origin prefetch) to escape cache partitioning for instance. Preload, on the other hand, is about subresource loads, and can be used for all other cases. I like the difference as this allows to express that: - a web page might know that it will probably navigate to another page (prefetch) - a web page might know its own resources (preloads) - a web page might not try to (in fact fail to) determine the resources of the potential next page and try to over-optimize the next page, especially third-party ones. If we narrow down the scope of prefetch to navigation loads, we might be able to simplify things without loosing too much functionality. 2. Does it make sense for prefetch loads to go through SW of the prefetching page? The response might depend on 1. Let's assume we target navigation loads. For third-party navigations, SW interception benefit is unclear, downside is increased processing/latency. For same-origin navigations, there might be some theoretical benefits. That said, the service worker intercepting the prefetch might not be the one intercepting the navigation load. Preloads might be good enough there. We also do not want to have the prefetch load go to the SW of the future navigation page. 3. Should a SW that intercepts the navigation load know that a prefetch is available? We might expect the navigation load to go through SW before using the prefetch cache. It could be handy for the SW to say: yes, go use the prefetch cache. Might be dealt separately. 4. Do we need the boolean in the Request interface? If we allow prefetch loads SW interception, probably. Otherwise, question 5. 5. Do we want JS to be able to create Request with this flag set? If we narrow down the scope to navigation loads, I am not sure allowing fetch() with a speculative load is very useful. One use case might be to emulate form submissions. Not sure the complexity of handling long living requests with body is worth this usecase. 6. Should responses be made available to the web page doing the prefetch? onload/onerror might be fine to have for <link prefetch>. This does not require to provide the response to the webpage. In general, we should be worried of communicating third party responses to the web page if mode is not cors. But cors might not be always suitable for prefetch. no-cors might not be suitable either, for instance due to CORP checks. Maybe prefetch would be better served with its own mode. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/881#issuecomment-475810539
Received on Friday, 22 March 2019 23:05:56 UTC