PWA / Service worker breaking production deployments

[ro-savage]

EDIT: Issue appears to be with Firebase only

Service workers aren't refreshing index.html and therefore new deploys are showing old bundles.

This means production websites or really all deployed sites that use a single url/domain can not be updated.

PR #2441 - Is a hotfix (if needed) that just removes the service worker and updates docs to say they have been disabled temporarily.

@gaearon @Timer @jeffposnick @addyosmani

Steps to reproduce

• create-react-app sw-test
• cd sw-test
• npm install
• npm run build
• cd build

Deploy with firebase

• firebase deploy
• Visit site https://[project].firebaseapp.com. Confirm working.
• Change app.js
• npm run build
• cd build
• deploy firebase

Check website

• Visit site again and no changes shown. DevTools shows SW is providing index.html and old bundles.
• Force refresh a few times. No difference.
• Delete service worker.
• Refresh.
• See correctly updated site.

Can someone else confirm this is affecting them?

I am hoping I am doing something wrong and this isn't affecting every production deploy.

[ro-savage]

Additionally, you can not remove the service worker because if you try to unregister in a new deploy, the user will never see the updated bundle.

[gaearon]

cc @jeffposnick

[bunshar]

Looks like something to do with "now". Works for me - Checked with "surge" and localhost

[gaearon]

cc @rauchg

[ro-savage]

Thank you @bunshar !

I tried surge on a new project built from scratch. And it working as expected.

Deployed same app on now and its working as expected.

No idea what happened or what I did different.

Happy to close this and assume I managed to screw something up multiple times and over-react.

I will keep an eye on my projects and see if I can narrow down what happened.

[ro-savage]

Still running into issues on firebase.

Deploying same newly create app to now, surge and firebase.

now and surge are updating. firebase is not. (newly created project: https://cra-sw.firebaseapp.com/)

Will see if its working tomorrow and will contact firebase and see what they say.

[ro-savage]

Just to prove I am not crazy and this is a thing on firebase.

Deploying changes with serve, now, surge and firebase.
Approximately 3 minutes
https://www.youtube.com/watch?v=oYy-WqkgS1Q

[gaearon]

Let’s keep it open and wait for @jeffposnick to help with diagnosing this.

[jeffposnick]

What you're running into with https://cra-sw.firebaseapp.com/ is described in item 5 of the "Offline-First Considerations", and is due to service-worker.js being served with HTTP caching headers.

It's unfortunately a common pain point, since many hosting providers will default to a medium-length cache lifetime for assets like .js files. Updating your web app's assets relies on detecting an updating service-worker.js file, and that is complicated when the browser's cache comes into play. (The cache headers are always ignored if the file is over 24 hours old; it there's more historical detail here.)

The service worker specification was changed to cause HTTP caching of service-worker.js to only happen when a developer explicitly opts-in, and Firefox has already implemented that change in FF53+.

Chrome has unfortunately not caught up, and still honors the HTTP caching headers. I was just asking about the status of this internally yesterday, and I'll point the relevant folks to these discussions, given the larger audience that is likely to inadvertently run into this.

[addyosmani]

cc'ing @davideast from Firebase as an FYI regarding the current cache-control max-age above. Jeff's summary is quite accurate but it would be good to get a check-in on the medium-length lifetime for static assets. Checking back in on #2441, it appears this is now only an issue for Firebase hosted content vs other hosts.

Chrome has unfortunately not caught up, and still honors the HTTP caching headers. I was just asking about the status of this internally yesterday, and I'll point the relevant folks to these discussions, given the larger audience that is likely to inadvertently run into this.

I'm going to chase trying to get some resource behind working on this internally.

[mbleigh]

For those who come across this issue, here is how you should be able to fix it for Firebase Hosting. Edit your firebase.json and add headers like so:

{
  "hosting": {
    "headers": [
      { "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
    ]
  }
}

[antmarot]

Thanks @mbleigh, it works!
There is a typo in your json though: firebase expects a headers array instead of a header object. Here is the adapted json:

{
  "hosting": {
    "headers": [
      { "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
    ]
  }
}

[mbleigh]

Thanks, I updated my snippet to match yours. That's what I get for assuming I remember all of my product's config from the top of my head. 🤦‍♂️

[ro-savage]

@jeffposnick - Thanks for clearing things up. That makes a lot more sense.

I had index.html cache-control set to 0 but all .js files are set to 3600 on the test cw-app and 7200 on my production app. Because you know, cache busting.

@mbleigh @antmarot - That configuration works great for firebase. Thanks.

Does this mean that service-worker.js is being modified with every deployment, so that it points at the correct bundles?
If so, does it make sense to cache-bust the service worker as well?

---

In terms of those steps in the Offline-First Considerations. Force-refresh (and having no-cache on) doesn't seem to fix the issue, maybe Chrome doesn't refresh the service worker?

Looks like maybe it's a Chrome issue?

In fact, I can see chrome saying that service-worker.js is being served from disk cache. Despite cache being disabled and force-refresh. (58.0.3029.110 & Canary 61.0.3117.0)

@addyosmani - Is this deliberate? (Meaning developers need to check 'update on reload' option in Chrome to force no-cache?)

Chrome regular

Chrome Canary

Can also confirm was not working in Firefox 52 but is now working in Firefox 54.

[jeffposnick]

Does this mean that service-worker.js is being modified with every deployment, so that it points at the correct bundles?

Yes, service-worker.js is modified with every deployment. It contains versioning information for all of the URLs it knows about—including URLs like index.html that can't be renamed to include inline hashes (no one will navigate to index.<md5>.html). Someone's written up a very thorough explainer that goes into all the details if you're curious.

If so, does it make sense to cache-bust the service worker as well?

The best practice is to keep the service worker file name constant (i.e. service-worker.js, sw.js or whatnot) instead of including a hash in the file name.

Including a hash in the file name means that you couldn't serve the file that contains the navigator.serviceWorker.register('service-worker.<md5>.js') statement using a cache-first strategy, since if you did serve it cache-first, you'd never pick up the new <md5> value.

Keeping the file name consistent, and relying on the service worker update flow to handle cache updates, means that you can serve all your static content cache-first. But it also means that if your service-worker.js is served with HTTP cache headers enabled, Chrome currently will respect those headers for up to 24 hours, leading to the frustration that you bumped up against in this issue.

[ro-savage]

Thanks for the through explanation @jeffposnick, very useful info.

[eranhirs]

Thanks for the help! 👍

It's very frustrating to find this solution, as I didn't even know about the existence of service workers. (Which is actually pretty cool that it's bundled so good into CRA).

Please add it to the docs to the Troubleshooting section for other users.

[gaearon]

Closing in favor of #2398.

[lusan]

Hi everyone, sorry for asking a similar question in a closed issue, thought it is related to it and the solution might be simple.

I am trying to set cache header for sw with nginx, in the configuration like it has been done in firebase, I tried

location /service-worker.js {
    add_header Cache-Control "no-cache";
    proxy_cache_bypass $http_pragma;
    proxy_cache_revalidate on;
    expires off;
    access_log off;
}

However when I load my page, sw registration fails with the message.

A bad HTTP response code (404) was received when fetching the script. registerServiceWorker.js:71 Error during service worker registration: TypeError: Failed to register a ServiceWorker: A bad HTTP response code (404) was received when fetching the script.

@gaearon @Timer @jeffposnick @addyosmani @mbleigh

Can someone please help me with this?

[j-lee8]

Is anybody still experiencing this issue? I've just created an app via create-react-app and deployed it to Firebase but when I check the Network and Application tabs in dev tools the service worker isn't there? When I do a local serve -s build it runs perfectly, but it doesn't appear to be loaded through Firebase.

Doing a Lighthouse audit it says there is no service worker on the page, yet inside the build dir the service-worker.js is there and it's also inside the asset-manifest.json.

Thanks all!