-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
[gatsby] v1.9.157 - TypeError: Cannot read property '35783957827783' of undefined when running in production mode... #3568
Comments
cc @szimek |
😭 I checked it multiple times and it always worked for me... Could you check what exactly triggers this line:
? According to the docs, inline scripts should be loaded synchronously and delay |
I suspect it's caused by this script loader https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/cache-dir/static-entry.js#L186-L196. Gatsby preloads all scripts using Maybe it's possible that if everything is loaded super fast, this loading script will load all scripts before the browser parses the script tag with @busticated Could you change this line in your headComponents.push( to postBodyComponents.push( so that it's after the script tag with webpack manifest (which is added using |
@szimek thanks for taking a look 👍 using |
Ok, this was the problem that I couldn't remember 😅 So yeah, the webpack manifest sets So if scripts are loaded in the head and the manifest isn't until the end then we run the risk (increased the longer the HTML body is) of a script loading, expecting We should read the manifest then load scripts which is what it was before moving the manifest to after the body and what @szimek's PR in #3569 restored. There's two primary metrics we're optimizing for. TTFP (time to first paint) and TTI (time to interactivity). Loading the manifest and starting the scripts downloading (async so non-blocking) optimized TTI while slowing TTFP somewhat especially for sites with really large numbers of files in the manifest as all that JS has to be read & parsed before the browser can get to the body. Putting the manifest & scripts at the end hurts TTI as now the HTML has to be fully loaded & parsed before we can start being interactive. It's especially slow for the ~50% of browsers that don't support preloading scripts as we don't even start downloading scripts until the end of the body. Now for smaller pages it's basically the same either way. But there are plenty of sites with HTML documents > 100kb and on poorer connections, these differences start to really matter. In the future, I've been thinking we'll move query results out of webpack which will remove most of the webpack manifest bloat. For a site with a ton of pages, most of the manifest is made up of pointers to individual page json files — most of which are never needed. See this other issue I just put up for that #3574 Once we do that, let's move the manifest + script loading back to the head because even for very large sites, the # of page components won't be that large. Thanks @busticated and @szimek for your help here! |
I ran into a weird error after upgrading to
gatsby v1.9.157
. if i manually revert this change, everything works as expected. likewise, downgrading togatsby v1.9.155
fixes the issue.Description
after running
gatsby build && gatsby serve
then visitinghttp://localhost:9000
, i see the following error sporadically:it appears in
production
mode only and seems to be related to resource loading. it's sporadic but happens on initial page load (roughly 50% of the time). i think the faster the response, the more likely it is that you'll hit the error. the file with the error has the url:webpack:///webpack/bootstrap 98fe446b590db3b33425
35783957827783
referenced in the error message is thechunkId
used in this line within the above mentioned file:script.src = __webpack_require__.p + window["webpackManifest"][chunkId];
Steps to reproduce
gatsby build && gatsby serve
Environment
Gatsby version: 1.9.157
Node.js version: 8.9.4
Operating System: macOS 10.13.2
The text was updated successfully, but these errors were encountered: