You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal is to speculatively load all static resources as soon as possible and store them permanently (and manage them on-demand) without blocking page that is being viewed.
I am looking for a solution to create efficient persistent prefetch of selected (static) resources that could be stored for later use with parallel download, but without blocking other on-demand requests.
I am looking to manage maybe tens or hundreds of small files - the idea is to have one service with let's say url-to-etag map of all static resources which I could compare with what I already have stored in cache - and update old resources/download missing resources.
As for the googled solution to the problem:
1, Issue with rel="prefetch" or "preload" is, that it is stored in HTTP cache - which will get flushed without me having anything to say into it (and without me being able to say, that it is already deprecated).
I also have no means of knowing when did the resources get preloaded (to store them in cache api) for precache or how to continue downloading resources during navigation (preload).
2, Inside service worker I haven't found any means of how to set low priority to request (HTTP/2) as not to block other on-demand requests. Workaround for this is fetching one resource at a time - which is not as efficient. The other workaround would be to monitor all the traffic (should be impossible from userspace if I am correct).
Did I maybe miss something what could be done?
Sorry if this is not a correct place to write such suggestion. Maybe you could direct me for the future.
The text was updated successfully, but these errors were encountered:
I am looking for a solution to create efficient persistent prefetch of selected (static) resources that could be stored for later use with parallel download, but without blocking other on-demand requests.
I think the Cache API mostly satisfies your requirements. The cached resources are not deleted until you explicitly call cache.delete(). The resource fetch - e.g. cache.addAll() - doesn't block the caller thread. Those methods can be used in both windows and service workers.
2, Inside service worker I haven't found any means of how to set low priority to request (HTTP/2) as not to block other on-demand requests.
I'm not sure if there has been any proposal for this (to fetch level?) But I'm not sure if this capability is something we'd want to expose to service worker API.
Hello everyone
The goal is to speculatively load all static resources as soon as possible and store them permanently (and manage them on-demand) without blocking page that is being viewed.
I am looking for a solution to create efficient persistent prefetch of selected (static) resources that could be stored for later use with parallel download, but without blocking other on-demand requests.
I am looking to manage maybe tens or hundreds of small files - the idea is to have one service with let's say url-to-etag map of all static resources which I could compare with what I already have stored in cache - and update old resources/download missing resources.
As for the googled solution to the problem:
1, Issue with rel="prefetch" or "preload" is, that it is stored in HTTP cache - which will get flushed without me having anything to say into it (and without me being able to say, that it is already deprecated).
I also have no means of knowing when did the resources get preloaded (to store them in cache api) for precache or how to continue downloading resources during navigation (preload).
2, Inside service worker I haven't found any means of how to set low priority to request (HTTP/2) as not to block other on-demand requests. Workaround for this is fetching one resource at a time - which is not as efficient. The other workaround would be to monitor all the traffic (should be impossible from userspace if I am correct).
Did I maybe miss something what could be done?
Sorry if this is not a correct place to write such suggestion. Maybe you could direct me for the future.
The text was updated successfully, but these errors were encountered: