[gatsby-plugin-offline] Default behavior serves stale data

[baobabKoodaa]

Summary

Default configuration for gatsby-plugin-offline serves stale data to users even when network is available.

Relevant information

Imagine a user who visits a website once a week. If the website has default gatsby-plugin-offline configuration, the user will always see 1 week old version of the website on their first pageload. Gatsby-plugin-offline is configured in such a way that it first serves stale content from its cache and then updates the cache in the background (so subsequent pageloads get a fresher version).

I've been trying for hours but I can't seem to change this behavior. I tried changing staleWhileRevalidate to networkFirst after reading this and this. It seems I got the syntax wrong somehow, since the behavior is still the same. I can't find a complete working example anywhere.

I don't think it's ever reasonable for a user to see a version that may be several days old. So I guess my question is twofold,

1. Should the default configuration be changed?
2. Can someone provide a complete working example of a reasonable configuration for gatsby-plugin-offline? I think a reasonable behavior would be to use network when it's available, but use cache in case of timeout/fail. And of course assets in /static and *.js etc. should be always served from cache.

[JustFly1984]

@baobabKoodaa
I use this function in gatsby-browser.js to notify user about new version

export const onServiceWorkerUpdateFound = () => {
  if (isBrowser) {
    const answer = window.confirm(
      `This application has been updated. ` +
      `Reload to display the latest version?`
    )

    if (answer === true) {
      window.location.reload()
    }
  }
}

but I do not like the behavior. It is often shows a lot of errors in browser console from the cache after page reload.

[JustFly1984]

#11842

[wardpeet]

@baobabKoodaa it's not as easy as it seems. The default that we use is cache-first as we can do a lot of optimisations for you.

These are all approaches that are available:

• Cache only
• Network only
• Cache first, falling back to network (current approach)
• Network first falling back to cache

Cache first approach is the fastest. You probably can create your own gatsby-plugin-offline with another approach. I'm unsure we want to take this on in the default plugin. Perhaps we could look into opt-out scenarios. Another idea could be to look in to background fetch (not supported everywhere yet) to update these pages from time to time.

[KyleAMathews]

It'd be nice to support network first as an option. It's still be faster than without a SW and offer the nice guarantee that pages will always be fresh.

It could even be the default in the future actually as it's less surprising for folks.

[gi-alec]

I have to admit, its a bit awkward to have to tell management to reset their cache to see the new feature 4x a week. Offline first isn't understood by most people. I love the speed, but for smaller sites that are iterating on rapidly changing designs, the positives don't outweigh the negatives.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[JustFly1984]

not stale lol

[alanonthegit]

+1 for network first

[benwiley4000]

Any word on this? No one is going to understand what I'm talking about if I pop a dialog telling them to upgrade to the new version of a website.

[JustFly1984]

• 1 for network first

[wardpeet]

Add the option to gatsby-plugin-offline to enable network first approach.

We love if someone would take this on! 💪

[stfnsr]

I was surprised by the current behavior as well, and would love to give this a shot 🙂

[wardpeet]

@stfnsr that's awesome! If you need any assistance just let us know. A pair programming session might work or join us in our weekly meeting.

My guess is to make

gatsby/packages/gatsby-plugin-offline/src/gatsby-node.js

Line 91 in b4e370f

handler: `cacheFirst`,

configurable with an option where we can easily switch it to networkFirst.

You should be able to test this without changing the offline plugin.

// gatsby-config.js
{
  plugins: [
    {
      resolve: `gatsby-plugin-offline`,
      options: {
        runtimeCaching: [
          {
            // Use cacheFirst since these don't need to be revalidated (same RegExp
            // and same reason as above)
            urlPattern: /(\.js$|\.css$|static\/)/,
            handler: `networkFirst`,
          },
          {
            // Add runtime caching of various other page resources
            urlPattern: /^https?:.*\.(png|jpg|jpeg|webp|svg|gif|tiff|js|woff|woff2|json|css)$/,
            handler: `staleWhileRevalidate`,
          },
          {
            // Google Fonts CSS (doesn't end in .css so we need to specify it)
            urlPattern: /^https?:\/\/fonts\.googleapis\.com\/css/,
            handler: `staleWhileRevalidate`,
          },
        ],
      },
    }
  ]
}

I'm no offline-plugin expert so i'll cc @davidbailey00 which is 😄.

[stfnsr]

@wardpeet thanks for pointing me in this direction - would be great if this approach would be sufficient, i was expecting to have to delve into the depths of serviceworkers ^^
Where can i find more info about the weekly meeting? The link on the community page seems to be dead?
The pair programming session sounds great - will definitely consider this at a later point :)

Regarding the offline plugin:
Is the snippet you posted an alternative syntax for plugin configuration? I was only aware of { resolve: 'gatsby-plugin-offline', options: { ... }}

I tried to switch the workbox strategy to networkFirst (and even to networkOnly) (which worked, according to workbox' console logs), but the behaviour was still not what i would expect - it took 2 to 3 reloads until changes were visible.
Will have to poke around further 🤔

[wardpeet]

😮 https://gatsby.dev/core-maintainers thanks for pointing out 😄 I'll let you know when it's fixed.

I tried to switch the workbox strategy to networkFirst (and even to networkOnly) (which worked, according to workbox' console logs), but the behaviour was still not what i would expect - it took 2 to 3 reloads until changes were visible.

Could you try to remove the service worker or update on reload. I think the sw isn't updating but I might be wrong.

[stfnsr]

Ah, i didn't know that option. I tried to fully deregister the service worker though (with gatsby-plugin-remove-serviceworker), and tried it in a freshly cloned default starter project as well.
From what I'm seeing in the Application tab, after i change something in the (specifically, the "Hi people" headline), build the site and reload the browser, the content is still the old one, but a new/updated serviceworker is registered. With the next reload, the new content is there.

[wardpeet]

Is the snippet you posted an alternative syntax for plugin configuration? I was only aware of { resolve: 'gatsby-plugin-offline', options: { ... }}

It's just me being bad at giving advice 😄 I've been to deep on babel configs lately which uses that syntax. I've edited the above comment with correct syntax

Let me know if the config above works then we can add an option to the offline plugin. We recently shipped a new way of getting page data #14359 so this might help as well with stale data.

[stfnsr]

Let me know if the config above works then we can add an option to the offline plugin. We recently shipped a new way of getting page data #14359 so this might help as well with stale data.

Ah sorry, i might have been unclear here:

From what I'm seeing in the Application tab, after i change something in the (specifically, the "Hi people" headline), build the site and reload the browser, the content is still the old one, but a new/updated serviceworker is registered. With the next reload, the new content is there

This was referring to the situation after trying the config above, even when starting from a completely fresh project that has never been run with offline-first.
So, did not work.
I'd like to use this as an opportunity to dig deeper into serviceworkers, my suspicion right now is that it could have something to do with the routes being precached?

[jhoffmcd]

I would love to see the option for network then cache too. For now I will have to disable this because there are too many inquiries with my team on why we are showing stale pages. I would really love to keep using this long term though 🤞

[JustFly1984]

I also definitely would love network, then cache. Meanwhile we silently reload the page after update.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JustFly1984]

not stale

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JustFly1984]

not stale!

[skhaz]

not stale

[daiky00]

@wardpeet any updates on this?

[vsolanogo]

after a week of developmet there were 2gb of cache data i saw in 'clear storage' tab. Some pages didn't work and were displayed as white screen untill i cleared storage. If i remove this plugin from project i will see 'static query(loading...)' after replacing old build with new one. The page on my mobile phone were also like empty white-screen. I've tried everything to force chrome through nignx headers to download fresh data but nothing works, it uses cache first anyway.

[admirabilis]

I thought the problem was fixed after reading some articles (links below) and creating the following configuration:

    {
      resolve: `gatsby-plugin-offline`,
      options: {
        workboxConfig: {
          runtimeCaching: [
            // no need for revalidation (unique uris with static content)
            {
              urlPattern: /(\.js$|\.css$|static\/)/,
              handler: `CacheFirst`,
            },
            // *data.json and static query results are not content hashed
            {
              urlPattern: /^https?:.*\/page-data\/.*\.json/,
              handler: `NetworkFirst`,
              options: {
                networkTimeoutSeconds: 3,
              },
            },
            // add runtime caching for resources that change less often
            {
              urlPattern: /^https?:.*\.(png|jpg|jpeg|webp|svg|gif|tiff|js|woff|woff2|json|css)$/,
              handler: `StaleWhileRevalidate`,
            },
            // Google Fonts CSS (doesn't end in .css so we must specify it)
            {
              urlPattern: /^https?:\/\/fonts\.googleapis\.com\/css/,
              handler: `StaleWhileRevalidate`,
            },
            // serve up-to-date content and fallback to cache when posible
            {
              urlPattern: /\/$/,
              handler: `NetworkFirst`,
              options: {
                networkTimeoutSeconds: 3,
              },
            },
          ],
        },
      },
    },

But, ultimately, the website had all sorts of new strange behaviour. So, in the end, I just replaced this plugin with gatsby-plugin-remove-serviceworker.

Well, thinking about it now, maybe I should have first removed the old workers, and then created the new configuration, I don't know.

Links:

• https://stackoverflow.com/questions/54724646/gatsbyjs-service-worker-configuration-doesnt-respect-networkfirst-keeps-serv
• https://www.gatsbyjs.com/plugins/gatsby-plugin-offline/#overriding-workbox-configuration
• https://www.gatsbyjs.com/docs/caching/
• https://medium.com/@krukmat/workbox-improving-the-pwa-4a5f5bda8c9d

[aaronadamsCA]

after a week of developmet there were 2gb of cache data i saw in 'clear storage' tab. Some pages didn't work and were displayed as white screen untill i cleared storage. If i remove this plugin from project i will see 'static query(loading...)' after replacing old build with new one. The page on my mobile phone were also like empty white-screen. I've tried everything to force chrome through nignx headers to download fresh data but nothing works, it uses cache first anyway.

@vsolanogo Make sure you installed gatsby-plugin-remove-serviceworker, this is required when removing gatsby-plugin-offline.

[Anmol368]

export const onServiceWorkerUpdateFound = () => {
if (isBrowser) {
const answer = window.confirm(
This application has been updated. +
Reload to display the latest version?
)

if (answer === true) {
  window.location.reload()
}

}
}

[demeralde]

Disappointed this still hasn't been fixed. IMO it mostly makes this plugin useless if it's serving stale data. It should just work outside of the box with little-to-no configuration.

[wahidshafique]

to continue the thread, I ran into this very issue about its seemingly non-optimal defaults. I'd like fresh content to be the preferred default, save for things like images or other static content. However it seems to be the other way around here. Reading some comments above made me just uninstall the thing

[LekoArts]

Hi!

I'm closing this as a stale issue as in the meantime Gatsby 4 and related packages were released. You can check our Framework Version Support Page to see which versions currently receive active support. If this is a feature request, please create a discussion as we moved feature requests from issues to GitHub Discussions.

Please try the mentioned issue on the latest version (using the next tag) and if you still see this problem, open a new bug report. It must include a minimal reproduction.

Thanks!