Fix errors on first load / Change SW strategy

[tryghost]

Fix errors on first load / Change SW strategy

[koreyboone]

@AileenCGN This should work: https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/#cache-then-network

[aileen]

This issue is related to gatsbyjs/gatsby#10036 which is not yet fixed in Gatsby itself.

We keep having issues with Safari with the docs site due to the service worker setup serving stale content. It's not being cleared at all when new content is pushed and it's very difficult to clear stale content manually (no luck with cache clear, deletion of indexed db records, or running with dev tools open and cache disabled).

We should consider changing the service worker strategy to fetch from network with local fallback? That's generally the approach taken for production sites where content is expected to change and would solve the Safari problems and the need to force a refresh in Chrome.

👉 https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/
👉 https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-offline

It appears that we can change the strategy for certain parts of the site, which need to be defined. See default config, that Workbox (underlying SW module used in gatsby-plugin-offline):

const options = {
  importWorkboxFrom: `local`,
  globDirectory: rootDir,
  globPatterns,
  modifyUrlPrefix: {
    // If `pathPrefix` is configured by user, we should replace
    // the default prefix with `pathPrefix`.
    "/": `${pathPrefix}/`,
  },
  cacheId: `gatsby-plugin-offline`,
  // Don't cache-bust JS or CSS files, and anything in the static directory,
  // since these files have unique URLs and their contents will never change
  dontCacheBustUrlsMatching: /(\.js$|\.css$|static\/)/,
  runtimeCaching: [
    {
      // Use cacheFirst since these don't need to be revalidated (same RegExp
      // and same reason as above)
      urlPattern: /(\.js$|\.css$|static\/)/,
      handler: `cacheFirst`,
    },
    {
      // 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`,
    },
  ],
  skipWaiting: true,
  clientsClaim: true,
}

[aileen]

Gatsby offline plugin is updated and closed the issue gatsbyjs/gatsby#10036 (comment)

Will update the dependencies shortly and see if that solved our issues without changing the strategy.

[aileen]

This should - hopefully - be solved now with TryGhost/gatsby-starter-ghost@9ab4a78 and 279bd32 which include dependency updates for the gatsby-plugin-offline.

According to the related issue in Gatsby

old bugs can still appear once the site has updated, due to browsers having the previous SW installed, but future updates should be okay assuming the bug was fixed because by that point, browsers have installed the latest SW.

This is also what I experienced and am therefor optimistic about this fix.

Safari:

• I had visited https://docs.ghost.org before this dependency update.
• After the update the usually experienced "blank page" did not occur and it seemed to load fine.
• The console stated that the sw got installed, which I assume is the fixed one.

It would be good to get some feedback regarding this issue with Safari, which I wasn't able to test:

We keep having issues with Safari with the docs site due to the service worker setup serving stale content. It's not being cleared at all when new content is pushed and it's very difficult to clear stale content manually (no luck with cache clear, deletion of indexed db records, or running with dev tools open and cache disabled).

Chrome:

• I had visited https://docs.ghost.org before this dependency update
• After the update the usually experienced "blank page" did occur, but only for a second.
• The console stated that the sw got installed, which I assume is the fixed one.

[aileen]

I close this issue for now, but we need to keep an 👀 on it. I will reopen it when it turns out to still be causing problems.