Gatsby: Gatsby Default Starter Lighthouse PWA Issue on subpages - Does not provide fallback content when JavaScript is not available

[mrfoster]

The default starter gets top marks on lighthouse for the home page but, although very impressive, it misses out on a few PWA points for sub pages e.g. https://gatsby-starter-default-demo.netlify.com/page-2/.

Lighthouse issue:
Does not provide fallback content when JavaScript is not available
https://developers.google.com/web/tools/lighthouse/audits/no-js

I have noticed that I get the following error if I disable javascript and try to view the page.
~~ ~~Uncaught TypeError: Cannot read property 'teardown' of undefined at Object.o.teardown (VM128 onloadwff.js:58) at VM128 onloadwff.js:58~~ ~~

This also happens on other Gatsby sites that I've checked but I can't find it mentioned anywhere. Is this expected behavior or a bug? I don't mind looking into fixing it and submitting a PR but not sure where to start. Any ideas?

Link to Lighthouse top marks issue:
https://github.com/gatsbyjs/gatsby/issues/6559

[moonmeister]

@mrfoster What server/stack are you running the tests against? gatsby develop/gatsby build && gatsby serve , netlify?? Thanks.

[mrfoster]

@moonmeister All tests have been done using netlify and is apparent on the example page (https://gatsby-starter-default-demo.netlify.com/page-2/]).

Please disregard the javascript error as this is not happening in incognito and I've since realised was being caused by a browser extension.

With javascript disabled, I have observed that sub pages are returned on hard reload but result in an empty page on subsequent normal reloads. This only happens when gatsby-plugin-offline is used.

[moonmeister]

@mrfoster offline stuff is out of my scope of knowledge, that said I know offline workers are javascript...I don't know if it's a bug or what, but maybe disabling js is breaking the offline workers.

[mrfoster]

@moonmeister Thanks, I am not too sure either but it does work fine on the home page. Your comment has led me to simply add a noscript tag which does the job of getting a 100 score and I think we are all way past caring about browsers without javascript.

I added it to gatsby-ssr.js which I guessed was better than overriding html.js.

const React = require('react')

exports.onRenderBody = ({ setPreBodyComponents }) => {
  setPreBodyComponents([
    <noscript key="noscript">Your browser does not support JavaScript!</noscript>,
  ])
}

[sarahannnicholson]

Thank you @mrfoster your solution was very helpful! :)

[danielo515]

I think this should be part of the default template.

[LekoArts]

Fixed with https://github.com/gatsbyjs/gatsby/pull/10945 👍
If you want to modify the message you have to use a custom html.js

[derykmarl]

Semi related (I'm not using the starter but searching brought me here)

I'm seeing this with any page that ends with a trailing slash - e.g. if you have /products/foo.js /products/bar.js and /products/index.js then /products/foo works, /products/bar works. But /products/ (which always ends in a trailing slash as it's a directory) fails the PWA test due to the blank page that comes up.

In Lighthouse 6.1 I'm currently facing a choice between linking internally to pages without a trailing slash and having Lighthouse complain that there's a 301 redirect to the version WITH the trailing slash, or linking internally to pages WITH a trailing slash (i.e. making the trailing slash version canonical, including /products/foo/ and /products/bar/) but having Lighthouse PWA test break on every page on the site.

The workaround by @mrfoster seems to work. But I have concerns about the possibility of Google thinking that the Javascript warning is important content, so would rather move it to the bottom of the body (StackOverflow uses this approach and seems to get away with it) so that it's considered less important. You can change the instances of setPreBodyComponents to setPostBodyComponents to achieve this.