Page-data.json 404 - With slow loading

FredrikSigvartsen commented 4 years ago

Description

I'm getting really slow response time on some pages (up to 7 seconds). It looks like it is page-data.json that is causing this:

I think these issues are somehow related, but I don't think the discussions there solves the problem:

Steps to reproduce

See heavy load time in production:

Visit https://www.sealab.no/.
In the navigation, go to Bluethink => BlueThink GO.
You will now experience a few seconds delay. This is page-data.json loading. Use Network in Inspector to see this.

Other pages are okay. And this only happens in production, not with gatsby develop. You can find the source code for the reproduction above here: https://github.com/SEALAB-Software/website Navbar: https://github.com/SEALAB-Software/website/blob/master/src/components/Navbar/Navbar.js Gatsby page template: https://github.com/SEALAB-Software/website/blob/master/src/templates/bluethink-go-page.js

We're using Netlify in production.

Expected result

Expect all pages to load somehow the same.

Actual result

Some pages uses up to 7 seconds to load.

Also, it looks like there is something wrong with Link from gatsby. Some Link-items are adding "../" in href:

<a class="navbar-item is-tab" href="/../bluethink-go">BlueThink™ GO</a>

Environment

  System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    npm: 6.7.0 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 79.0.3945.130
    Firefox: 70.0.1
    Safari: 13.0.4
  npmPackages:
    gatsby: ^2.19.7 => 2.19.7
    gatsby-image: ^2.2.39 => 2.2.39
    gatsby-link: ^2.2.22 => 2.2.28
    gatsby-plugin-google-analytics: ^2.1.23 => 2.1.34
    gatsby-plugin-google-tagmanager: ^2.1.15 => 2.1.24
    gatsby-plugin-netlify: ^2.1.31 => 2.1.31
    gatsby-plugin-netlify-cache: ^1.2.0 => 1.2.0
    gatsby-plugin-netlify-cms: ^4.1.37 => 4.1.37
    gatsby-plugin-purgecss: ^4.0.1 => 4.0.1
    gatsby-plugin-react-helmet: ^3.1.21 => 3.1.21
    gatsby-plugin-react-svg: ^2.1.2 => 2.1.2
    gatsby-plugin-sass: ^2.1.27 => 2.1.27
    gatsby-plugin-sharp: ^2.4.2 => 2.4.3
    gatsby-remark-copy-linked-files: ^2.1.36 => 2.1.36
    gatsby-remark-images: ^3.1.42 => 3.1.42
    gatsby-remark-relative-images: ^0.2.3 => 0.2.3
    gatsby-source-filesystem: ^2.1.46 => 2.1.46
    gatsby-transformer-remark: ^2.6.48 => 2.6.48
    gatsby-transformer-sharp: ^2.3.13 => 2.3.13
  npmGlobalPackages:
    gatsby-cli: 2.7.49

FredrikSigvartsen commented 4 years ago

It looks like this is not an issue with Gatsby at all. The issue lies in gatsby-node.js, where we use fnImagesToRelative:

const { fmImagesToRelative } = require('gatsby-remark-relative-images')

...

exports.onCreateNode = ({ node, actions, getNode }) => {
  const { createNodeField } = actions
  fmImagesToRelative(node) // convert image paths for gatsby images

  if (node.internal.type === `MarkdownRemark`) {
    const value = createFilePath({ node, getNode })
    createNodeField({
      name: `slug`,
      node,
      value,
    })
  }
}

This leads to all paths being an image, and therefore the path is changed to ../name-of-page instead of /name-of-page. I guess until this is fixed by either of these, I will go back to type the paths directly into the code, and not store it in a markdown file.

vladar commented 4 years ago

Thanks so much for opening this issue! As stated, this is slightly tangential to Gatsby, and it seems like you’ve already figured out the source of the problem.

If this is not the case, or if we can help further--please don’t hesitate to reach out or comment on this issue, and we’d love to take another look.

Thanks for using Gatsby :muscle:

gatsbyjs / gatsby