Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use network-first strategy for start_url #406

Open
pi0 opened this issue Nov 30, 2020 · 5 comments
Open

use network-first strategy for start_url #406

pi0 opened this issue Nov 30, 2020 · 5 comments
Labels

Comments

@pi0
Copy link
Member

pi0 commented Nov 30, 2020

Since Lighthouse made it mandatory to respond to start_url when offline, we are pre-caching it (3.2.1). A build-time revision added by 3.3.0 / #386 but since revision is per-build, cached version for start_url may get stalled with target: 'server' since workbox does not supports NetworkFirst strategy for precache assets.

This is a known issue for users that use target: 'server':

  • If start_url is not customized or is distinct it might cache ATH version until next build
  • If start_url is customized to /, it might caching landing until next build
@pi0 pi0 changed the title don't precache start_url use network-first strategy for start_url Nov 30, 2020
@pi0 pi0 added the bug label Nov 30, 2020
@voxivoid
Copy link

any news regarding this issue? every time we do a new deploy the start_url gets stalled and then we get a lot of loading chunk errors because it tries to access files that do not exist anymore on the server

@FreekVR
Copy link

FreekVR commented Apr 21, 2021

Yeah, we're having this problem too, it seems there's still some nuxt hydration going on on page load, but no new data is being loaded from fetch() etc. so we're getting stale data on the homepage until the next deployment. The default ?standalone=true just moves the issue to that route instead, in that case anyone who has installed it as a PWA will get a stale homepage most of the time.

@niklaswolf
Copy link

Does anybody have a good workaround or ideas for this?
This seems like a pretty major issue for users that install the app as PWA.

A real "bad" workaround could be to trigger a new build/deployment, when changes on the home-page are detected. This of course is highly dependent on where the content of this page is coming from. Of course this is not a solution to this problem and not an option for most people either...

@korchaka666
Copy link

Guys, how did you solve this problem? And if so, how?

@mathix420
Copy link

@korchaka666 I managed to find a workaround that seems to work fine for me.

I have created a plugin: ~/plugins/pwa-update.js

export default async () => {
  const workbox = await window.$workbox

  if (!workbox) {
    // Workbox couldn't be loaded
    return
  }

  function eventHandler(event) {
    if (!event.isUpdate) {
      // The PWA is on the latest version
      return
    }

    // This modal will tell the user that a new version is available
    // The user can then click a button to update the PWA (see below)
    window.$nuxt.$store.commit('modal/push', { name: 'update' })
  }

  workbox.addEventListener('installed', eventHandler)
  workbox.addEventListener('waiting', eventHandler)
}

In nuxt.config.js:

// ...
plugins: [
    { src: '~/plugins/pwa-update.js', mode: 'client' },
]
// ...

The modal:

<template>
  <section>
    <h3>A new version is available!</h3>
    <button @click="refresh">Click to update</button>
  </section>
</template>

<script>
export default {
  methods: {
    refresh() {
      window.location.reload()
    },
  },
}
</script>

It's a bit harsh as the whole project is reloaded, but it's working. 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants