5 ms·

Great write up. I’ve been exploring SWs recently to help with downloading and caching data in the background for faster UI. Question, I’d like to avoid doing l

by sbr464 8y ago

Great write up. I’ve been exploring SWs recently to help with downloading and caching data in the background for faster UI. Question, I’d like to avoid doing large downloads or possibly cap the transfer rate to avoid any potential jank. Is there a best practice or is it possible to monitor the current browser interaction to determine how strategically best to pull data with a SW? Depending on what a user chooses to cache, it’s JSON data (1-10MB) going to a mix of localstorage and indexedDB.

slow_donkey 8y ago
Have you looked into using a fetch event hook? The first thing I thought of was an Axios interceptor if you're using Axios or other http lib. That should allow you to sum up download sizes.
- wbercx 8y ago
  Thanks for this! I've recently been asked how much data our React Native app uses. I totally hadn't thought of using Axios' interceptors to track this. So obvious!
pmlnr 8y ago
May I ask the justification to download 1-10MB JSON on the user's system without the user being aware?
- ahsanejaz 8y ago
  You also cache regular web resources like images. It is for the user's benefit since next visit to the site can be faster.
  - pmlnr 8y ago
    You misunderstand. Service worker traffic is invisible, unlike loading an image and generally speaking can't be governed, unlike visible elements. Loading 1-10MB JSON might drain a significant portion of mobile data. It could take a long time, meaning it may need to re-start it a couple of times, due to, say, a flaky 3G connection. I'm curious on the why - unless this is an announced feature, I don't think this should be an automatic process and should only be done on user demand explicitly.
    - sbr464 8y ago
      I agree with you, there are several settings avail to control what is optimized, it’s typically enabled on faster devices/connections at work. I would be upset as well if a site naively used up a connection in the background.
- sbr464 8y ago
  They are aware, it’s business software, syncing records/templates/frequent info etc. It’s only to improve the experience, and it’s controlled by settings/opt-in etc. It’s also configurable to only operate on faster connections/non mobile IP address etc. The main reason I was asking is if you currently benchmark service worker updates with indexedDB for async/larger updates, they still cause a small amount of jank, (at least on larger requests) even though they may use a different process etc. There’s a github repo with a benchmark, this link is older but if you clone the current version and update to the lastest packages, the results are still similar. https://www.google.com/amp/s/nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/amp/

by sbr464 8y ago

slow_donkey 8y ago

Have you looked into using a fetch event hook? The first thing I thought of was an Axios interceptor if you're using Axios or other http lib. That should allow you to sum up download sizes.

wbercx 8y ago
Thanks for this! I've recently been asked how much data our React Native app uses. I totally hadn't thought of using Axios' interceptors to track this. So obvious!

pmlnr 8y ago

May I ask the justification to download 1-10MB JSON on the user's system without the user being aware?

ahsanejaz 8y ago
You also cache regular web resources like images. It is for the user's benefit since next visit to the site can be faster.
- pmlnr 8y ago
  You misunderstand. Service worker traffic is invisible, unlike loading an image and generally speaking can't be governed, unlike visible elements. Loading 1-10MB JSON might drain a significant portion of mobile data. It could take a long time, meaning it may need to re-start it a couple of times, due to, say, a flaky 3G connection. I'm curious on the why - unless this is an announced feature, I don't think this should be an automatic process and should only be done on user demand explicitly.
  - sbr464 8y ago
    I agree with you, there are several settings avail to control what is optimized, it’s typically enabled on faster devices/connections at work. I would be upset as well if a site naively used up a connection in the background.
sbr464 8y ago
They are aware, it’s business software, syncing records/templates/frequent info etc. It’s only to improve the experience, and it’s controlled by settings/opt-in etc. It’s also configurable to only operate on faster connections/non mobile IP address etc. The main reason I was asking is if you currently benchmark service worker updates with indexedDB for async/larger updates, they still cause a small amount of jank, (at least on larger requests) even though they may use a different process etc. There’s a github repo with a benchmark, this link is older but if you clone the current version and update to the lastest packages, the results are still similar. https://www.google.com/amp/s/nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/amp/