You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new per-page-manifest feature replaces the global pages-manifest with a page-data.json for each page. The pages-manifest meant that the browser had all the component and dataPath information it needed, and could therefore prefetch component and query results in parallel. Since we no longer have the global list of all page metadata, we now have to first request the page-data.json for the page, retrieve the component name, and then request the component. So we now have to wait for 2 prefetch requests to execute serially before we have all the information required to quickly navigate to a page. This performance impact will only be felt by users on slow connections, but it's still a regression.
Proposed Change
During html rendering, detect all pages that are linked to by the page currently being rendered, and for each linked page, find its component, and add a prefetch link. Basically, we want the same functionality as Gatsby.Link.componentDidMount, but during html generation.
Implementation Ideas
Use react-side-effect. This would involve creating an alternate Gatsby Link that worked on the server. On componentDidMount, it would write the to URL to a Set, which we could use to figure out which pages/components need prefetching
Just an added thought here that a proposed solution should support adding the appropriate links to headers for hosting plugins like gatsby-plugin-netlify.
We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Gatsby community! 💪💜
gatsbotbot
added
the
stale?
Issue that may be closed soon due to the original author not responding any more.
label
Jun 19, 2019
It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks again for being part of the Gatsby community!
Background
The new per-page-manifest feature replaces the global
pages-manifest
with apage-data.json
for each page. The pages-manifest meant that the browser had all the component and dataPath information it needed, and could therefore prefetch component and query results in parallel. Since we no longer have the global list of all page metadata, we now have to first request thepage-data.json
for the page, retrieve the component name, and then request the component. So we now have to wait for 2 prefetch requests to execute serially before we have all the information required to quickly navigate to a page. This performance impact will only be felt by users on slow connections, but it's still a regression.Proposed Change
During html rendering, detect all pages that are linked to by the page currently being rendered, and for each linked page, find its component, and add a prefetch link. Basically, we want the same functionality as Gatsby.Link.componentDidMount, but during html generation.
Implementation Ideas
Gatsby Link
that worked on the server. OncomponentDidMount
, it would write theto
URL to a Set, which we could use to figure out which pages/components need prefetchingRelated Issues
The text was updated successfully, but these errors were encountered: