Website fails to load completely

[sedubois]

Description

Since I started using Gatsby a couple of months ago, I regularly get issues when visiting the published site. No issue in local development. The issue gets fixed when hitting Ctrl-Shift-R, but I can hardly expect all my visitors to do this every time...

I just see this error in the console:

The bootstrap%2003bd3a01b7024eecaa93:52 file shows this:

// Execute the module function
modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

This is in a file whose description is // install a JSONP callback for chunk loading.

Is this something to do with chunk loading which breaks because of gatsby-plugin-offline? My setup is very similar to the gatsbyjs.org codebase, so I think that the Gatsby site has the same issue, as I reported previously in #3142.

Do you have any idea of the underlying cause and the proper way to fix this? If there's no proper fix, is there a workaround such as disabling service worker entirely?

Unfortunately chunking and caching are still way above my skillset, but this is directly impacting our visitors.

Environment

Gatsby version: 1.9.158 and all my packages/plugins are up to date Node.js version: v8.9.4 (npm v5.6.0)

File contents (if changed):

gatsby-config.js:

``` const siteMetadata = require('./src/data/site-metadata') module.exports = { siteMetadata, mapping: { 'MarkdownRemark.frontmatter.author': `AuthorYaml`, }, plugins: [ { resolve: `gatsby-source-filesystem`, options: { name: `images`, path: `${__dirname}/src/images`, }, }, { resolve: 'gatsby-source-filesystem', options: { name: 'pages', path: `${__dirname}/src/pages`, }, }, { resolve: `gatsby-plugin-typography`, options: { pathToConfigModule: `src/utils/typography`, }, }, { resolve: `gatsby-plugin-canonical-urls`, options: { siteUrl: siteMetadata.siteUrl, }, }, `gatsby-transformer-sharp`, `gatsby-transformer-documentationjs`, `gatsby-transformer-yaml`, { resolve: `gatsby-transformer-remark`, options: { plugins: [ { resolve: `gatsby-remark-images`, options: { maxWidth: 786, backgroundColor: `#ffffff`, }, }, { resolve: `gatsby-remark-responsive-iframe`, options: { wrapperStyle: `margin-bottom: 1.05rem`, }, }, `gatsby-remark-prismjs`, `gatsby-remark-copy-linked-files`, `gatsby-remark-smartypants`, `gatsby-remark-autolink-headers`, ], }, }, { resolve: `gatsby-plugin-nprogress`, options: { color: `#9D7CBF`, showSpinner: false, }, }, `gatsby-plugin-glamor`, `gatsby-plugin-sharp`, `gatsby-plugin-catch-links`, `gatsby-plugin-react-next`, `gatsby-plugin-lodash`, { resolve: `gatsby-plugin-manifest`, options: { name: `Imagine Clarity`, short_name: `Imagine Clarity`, start_url: `/`, background_color: `#f7f0eb`, theme_color: `#5c2965`, display: `minimal-ui`, icons: [ { src: `/android-chrome-192x192.png`, sizes: `192x192`, type: `image/png`, }, { src: `/android-chrome-512x512.png`, sizes: `512x512`, type: `image/png`, }, ], }, }, { resolve: `gatsby-plugin-offline`, options: { navigateFallback: null, navigateFallbackWhitelist: [], }, }, `gatsby-transformer-csv`, { resolve: `gatsby-plugin-intercom-spa`, options: { app_id: process.env.INTERCOM_APP_ID, }, }, `gatsby-plugin-twitter`, `gatsby-plugin-react-helmet`, { resolve: 'gatsby-plugin-i18n', options: { langKeyForNull: 'any', langKeyDefault: siteMetadata.defaultLangKey, useLangKeyLayout: true, pagesPaths: [ '/src/pages' ], markdownRemark: { postPage: 'src/templates/blog-post.js', query: ` { allMarkdownRemark { edges { node { fields { slug langKey } } } } }` } } }, { resolve: `gatsby-plugin-google-analytics`, options: { trackingId: `xxx`, }, }, `gatsby-plugin-sitemap`, { resolve: `gatsby-plugin-feed`, feeds: [ { query: ` { allMarkdownRemark( sort: { order: DESC, fields: [frontmatter___date] } filter: { frontmatter: { draft: { ne: true } } fileAbsolutePath: { regex: "/blog/" } } ) { edges { node { excerpt html frontmatter { title date excerpt author { name } } fields { slug } } } } } `, output: `/blog/rss.xml`, setup: ({ query: { site: { siteMetadata } } }) => { return { title: siteMetadata.title, description: siteMetadata.description, feed_url: siteMetadata.siteUrl + `/blog/rss.xml`, site_url: siteMetadata.siteUrl, generator: `GatsbyJS`, } }, serialize: ({ query: { site, allMarkdownRemark } }) => allMarkdownRemark.edges.map(({ node }) => { return { title: node.frontmatter.title, description: node.frontmatter.excerpt || node.excerpt, url: site.siteMetadata.siteUrl + node.fields.slug, guid: site.siteMetadata.siteUrl + node.fields.slug, custom_elements: [{ 'content:encoded': node.html }], author: node.frontmatter.author.slug, } }), }, ], }, ], } ```

package.json:

``` { "name": "imagine-clarity", "description": "Imagine Clarity", "version": "1.0.0", "author": "Sébastien Dubois ", "dependencies": { "bluebird": "^3.4.6", "gatsby": "^1.9.127", "gatsby-image": "^1.0.5", "gatsby-link": "^1.6.16", "gatsby-plugin-canonical-urls": "^1.0.6", "gatsby-plugin-catch-links": "^1.0.8", "gatsby-plugin-feed": "^1.3.9", "gatsby-plugin-glamor": "^1.6.7", "gatsby-plugin-google-analytics": "^1.0.7", "gatsby-plugin-i18n": "^0.4.0", "gatsby-plugin-intercom-spa": "^0.0.5", "gatsby-plugin-lodash": "^1.0.0", "gatsby-plugin-manifest": "^1.0.7", "gatsby-plugin-nprogress": "^1.0.7", "gatsby-plugin-offline": "^1.0.9", "gatsby-plugin-react-helmet": "^2.0.1", "gatsby-plugin-react-next": "^1.0.0", "gatsby-plugin-sharp": "^1.6.7", "gatsby-plugin-sitemap": "^1.2.5", "gatsby-plugin-twitter": "^1.0.10", "gatsby-plugin-typography": "^1.7.9", "gatsby-remark-autolink-headers": "^1.4.7", "gatsby-remark-copy-linked-files": "^1.5.7", "gatsby-remark-images": "^1.5.11", "gatsby-remark-prismjs": "^1.2.8", "gatsby-remark-responsive-iframe": "^1.4.7", "gatsby-remark-smartypants": "^1.4.7", "gatsby-source-filesystem": "^1.4.12", "gatsby-transformer-csv": "^1.3.5", "gatsby-transformer-documentationjs": "^1.4.6", "gatsby-transformer-remark": "^1.7.7", "gatsby-transformer-sharp": "^1.6.5", "gatsby-transformer-yaml": "^1.5.7", "intl": "^1.2.5", "lodash": "^4.16.6", "mitt": "^1.1.2", "parse-filepath": "^1.0.1", "ptz-i18n": "0.4.0", "react-helmet": "^5.2.0", "react-icons": "^2.2.3", "react-id-swiper": "^1.5.5", "react-intl": "^2.4.0", "react-player": "^1.1.1", "slash": "^1.0.0", "typeface-crimson-text": "^0.0.44", "typography-breakpoint-constants": "^0.15.10", "webfontloader": "^1.6.28" }, "keywords": [ "meditation" ], "license": "MIT", "main": "n/a", "private": true, "scripts": { "dev": "gatsby develop -H localhost", "build": "gatsby build", "start": "gatsby serve", "format": "prettier --trailing-comma es5 --no-semi --single-quote --write 'src/**/*.js'", "test": "echo \"Error: no test specified\" && exit 1" } } ```

gatsby-node.js:

``` const Promise = require(`bluebird`) const path = require(`path`) const slash = require(`slash`) exports.createPages = ({ graphql, boundActionCreators }) => { const { createPage } = boundActionCreators return new Promise((resolve, reject) => { const authorPageTemplate = path.resolve(`src/templates/author-page.js`) // Query for markdown nodes to use in creating pages. resolve( graphql( ` { # allMarkdownRemark( # sort: { order: DESC, fields: [frontmatter___date] } # limit: 1000 # ) { # edges { # node { # fields { # slug # } # frontmatter { # title # draft # canonicalLink # publishedAt # } # } # } # } allAuthorYaml { edges { node { slug } } } } ` ).then(result => { // Create author pages. result.data && result.data.allAuthorYaml.edges.forEach(edge => { createPage({ path: edge.node.slug, component: slash(authorPageTemplate), context: { slug: edge.node.slug, }, }) }) }) ) }) } exports.modifyWebpackConfig = ({ config, stage }) => { if (stage === 'build-html') { config.loader('null', { test: /webfontloader/, loader: 'null-loader' }) } } ```

gatsby-browser.js: not changed

gatsby-ssr.js: not changed

Actual result

The page only loads partially. Presumably, the browser only loads some cached assets but doesn't initialize Javascript properly. Visually the main image will remain blurred instead of loading fully. Or even the first redirect (from / to /en) might also fail, so it doesn't load the content at all. This happens with my Firefox browser but also observed on my Chrome.

Expected behavior

Page shouldn't fail to load.

Steps to reproduce

Happens regularly (but not always) when I deploy. Please let me know if there's something else I can provide to investigate.

Thanks a lot for your time and keep up the good work!

[KyleAMathews]

It's related to https://www.gatsbyjs.org/docs/caching/#javascript

The gatsby-plugin-offline SW is caching JS so sometimes this means that a module will change internally but its name won't so things break... :-( Gatsby v2 (working on this now) which upgrades us to webpack 3 will solve this.

I'd kinda forgotten about this issue w/ the offline plugin. The solution there is we shouldn't cache JS files either. Would you like to put together a PR for that? We can re-enable JS caching in the SW for Gatsby v2.

[ghost]

@KyleAMathews Could it be solved if a parameter is on requests append like ?build1234567 on deployments?

[sjkp]

I had the same error. I believe it is because the window.webpackManifest is written to the bottom of the body. So sometimes it is not initialized, when the components script are loaded and trying to access it. At least I haven't had the issues since I manually changed my html.js so that window.webpackManifest is added within the head tag.

my html.js looks like this

import React from "react"

let stylesStr
if (process.env.NODE_ENV === `production`) {
  try {
    stylesStr = require(`!raw-loader!../public/styles.css`)
  } catch (e) {
    console.log(e)
  }
}

module.exports = class HTML extends React.Component {
  render() {

    let css;
    let mainfest;
    if (process.env.NODE_ENV === `production`) {
      // Add the chunk-manifest at the head section. As the async script loading of 
      // the components failes if the webpack-mainfest is missing.
      const chunkManifest = require(`!raw!../public/chunk-manifest.json`)

      mainfest = (<script
          id="webpack-manifest"
          key="webpack-manifest"
          dangerouslySetInnerHTML={{
            __html: `/*<![CDATA[*/window.webpackManifest=${chunkManifest}/*]]>*/`,
          }}
        />
      )

      css = (
        <style
          id="gatsby-inlined-css"
          dangerouslySetInnerHTML={{ __html: stylesStr }}
        />
      )
    }
    return (
      <html>
        <head>
          <meta charSet="utf-8" />
          <meta httpEquiv="x-ua-compatible" content="ie=edge" />
          <meta
            name="viewport"
            content="width=device-width, initial-scale=1, shrink-to-fit=no"
          />
          {mainfest}
          {this.props.headComponents}
          {css}
       </head>
        <body>
          {this.props.preBodyComponents}
          <div
            key={`body`}
            id="___gatsby"
            dangerouslySetInnerHTML={{ __html: this.props.body }}
          />
          {this.props.postBodyComponents}
        </body>
      </html>
    )
  }
}

I'm aware this in an ugly hack, but I'm not familiar with the gatsby code base to actually make a PR.

[KyleAMathews]

@sjkp that's a separate issue which we solved recently by moving the scripts to below the manifest. They both used to be in the head then the manifest was moved to below the body https://github.com/gatsbyjs/gatsby/pull/3569

[KyleAMathews]

@dotmagic yes but that's worst as then scripts would need downloaded every time. Better to force 301 validations as that's far faster/cheaper.

[KyleAMathews]

Though harder to do with SW sigh

Let's just get Gatsby v2 out ASAP which will fix this for realz.

[julien1619]

Hi @KyleAMathews ! I'm encountering the same issue and I didn't see the fact that JavaScript files shouldn't be cached for now. So my users are stuck with some erroneous files because I set expiry 30d on these (now disabled).

Is there a quick way to specify a parameter like @dotmagic suggested before? Thank you!

[KyleAMathews]

@julien1619 not easy unfortunately — best bet is to post-process HTML files and add the query string programmatically to the script tags. You could use something like https://www.npmjs.com/package/cheerio in Gatsby's onPostBuild extension point https://www.gatsbyjs.org/docs/node-apis/#onPostBuild

[julien1619]

@KyleAMathews Thank you! Finally, I did a more manual change: I replaced all .js" by .js?blabla" in all build files.

[zanedev]

Just ran into this issue also so I disabled SW caching for now :(

[lightstrike]

@zanedev what options did you use to disable caching within the plugin?

[zanedev]

Sorry I mean I removed the offline plugin temporarily until it’s all fixed

[lightstrike]

That's what I ended up doing too. I'll revisit once v2 is official.

[pedrouid]

@lightstrike @zanedev did you need to do anything to unregister the already existing SW?

[zanedev]

@pedrouid I did unfortunately and I didn't realize it until after I had released new features and everyone was freaking out. Not a fun position to be in :) This article helped me figure out how to clear them (near the bottom)

[pedrouid]

@zanedev Thanks! That worked perfectly

[bradennapier]

If caching doesnt work - you should remove it completely from your site and warn against using it - this is terrible. Just took me about 5 hours of staring at my css like wtf why arent these classes even on this div at all until I realized this.

I would point out to anyone here you probably need to manually remove your service worker or your users will just see empty content after you remove the offline plugin

if (typeof navigator !== 'undefined') {
navigator.serviceWorker.getRegistrations().then((registrations) => {
    for (const registration of registrations) {
      registration.unregister();
    }
  });
}

PS

Can you guys try to use Webpack 4 not 3 ? Or better yet just wait until 5 and release up-to-date. If releasing v2 on an already old version of webpack that will be insanely behind since Webpack 5 is about to ship;

[m-allanson]

@bradennapier sorry you had trouble with this, Gatsby v2 is actively being worked on with the aim of getting v2 betas out as quickly as possible.

Until then, note that there's gatsby-plugin-remove-service-worker that can handle unregistering for you. The Gatsby v2 alphas are currently running on webpack 4.

[bradennapier]

@m-allanson thanks!! Awesome good to hear you guys are updated to wp4 already. Appreciate the response. Great work on the overall solution - love Gatsby!

[brmi]

I am having the same issue, but getting this error: Refused to execute script from '<URL>' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

It happens about 15% of the time and the error goes away after reloading the page ~3 times.

Is it the same problem as above? Is there anyway to fix this right now?

This is my gatsby-config.js file:

module.exports = {
  plugins: [
    `gatsby-transformer-yaml`,
    `gatsby-plugin-react-helmet`,
    `gatsby-plugin-sass`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `./src/data/`,
      },
    },
      {
          resolve: 'gatsby-plugin-react-svg',
          options: {
              include: /assets/
          }
      },
      {
        resolve: `gatsby-plugin-netlify`,
        options: {
          headers: {
            "/*.js": [
              "Cache-Control: public, max-age=0, must-revalidate",
            ],
          },
        },
      },
  ],
};

The problem only happens on the production build.

I opened an issue: #6947

[CanRau]

I experienced similar happenings..I'm still on my way preparing to release my upgrade to v2 and don't know if this might also fix this? Anyone knows?

[sedubois]

@CanRau see https://github.com/gatsbyjs/gatsby/issues/3582#issuecomment-358704657, normally webpack v3 fixes it, so yes Gatsby v2 should fix it. (I haven’t upgraded yet)

[CanRau]

thanks for the hint..I guessed it might be fixed but good to read it ;)

[kakadiadarpan]

@sedubois can you try upgrading gatsby and dependencies to their latest stable versions? We released version 2 recently, that might solve the issue for you.

[sedubois]

@kakadiadarpan I propose to close this and will reopen if I encounter issues. (I had to move away from the codebase used in the OP; I will update it to v2 and push to production when possible.)

[madhusudhan1234]

Hi Guys! When I run gatsby build It gives me following error.

Building static HTML for pages{ Error: Cannot find module '!raw-loader!../public/styles.css'

gatsby develop works fine. Could you guys please help me with this?

[CanRau]

Hey @madhusudhan1234 sorry for the late response, were you able to figure it out? Not sure about that !raw-loader! think they're kind of out-dated and might interfere with some updates of webpack?

[varya]

I have the same problem, production build fails. Worked fine just recently, maybe related to some package updates?

[MTyson]

This is occuring on my site right as I used it to demo.

Not good man. Not good at all.