Page doesn't stop loading in latest version of nuxt-edge. This wasn't a problem previously, something broke.
Screenshot: https://1ce.org/1#r1ZaHcdSS
I tried rerunning npm run dev
and restarting the server a few times. The issue persists.
> nuxt --port 3000
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ โ
โ Nuxt.js v2.9.0-26104328.b22e0543 โ
โ Running in development mode (universal) โ
โ โ
โ Listening on: http://localhost:3000/ โ
โ โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
Note: even on removing ALL the code from the index.vue file, this still happens.
Pages should load quickly. The nuxt-links should load when clicked.
Pages NEVER finish loading...even if npm run dev is restarted. This happens whether I use nuxt-edge or nuxt 2.9.2
I have to click 'x' on chrome to make the page stop loading. If I then click on any nuxt-link, it does not load. If I hard-refresh the page, the page does not load and spins forever.
Note: even on removing ALL the code from the index.vue file, this still happens.
This instability is incredibly frustrating.
Eventual message seen on page timeout (I had clicked on /signup nuxt-link and eventually saw this message)
Something went wrong here.
Loading chunk pages/signup failed. (timeout: http://localhost:3000/_nuxt/pages/signup.js)
I have the same bug
After updating, I had the same bug as well. We reverted to previous version and everything works fine.
@Huc91, you mean a 2.8.1 as a previous version =)
@ruslankonev yes 2.8.1
@connecteev @ruslankonev @Huc91 @LuXDAmore @ollejah
Anyone, if you wish to have a quick fix please provide a minimal reproduction that shows this error. Without a reproduction its quite certain that this issue wont be fixed until one of us experience this ourselves. And who knows how long that will take.
@pimlie I hear you but I have not seen that issue come back unfortunately. However, on that dreaded day when I filed this, it was a real problem. Defer to you on whether you and the rest of the folks want to keep this issue open.
Edit: What "fixed" it for me then was restarting my Mac. Should I see this again I will report back.
Hi @pimlie ,
I think my problem is not related to nuxt-links
, after some tests i've found this error:
Probably the issue happen due to the new vue-meta routing (implemented in the new version of Nuxt).
Browsing web pages, it's possible to see that the navigation continues to slow down, 'til Chrome goes to crash.
And DevTools bring me somewhere in the '$metaInfo' code.
Probably it's something happening in an middleware-async
or during the merge of head()
data.
This afternoon i'll try to reproduce the issue in a repo.
@LuXDAmore Thanks, would appreciate a repro very much.
I think @AndrewBogdanovTSS raised a similar suspicion on discord, will try to debug this but a repro would help a lot.
@pimlie, I will join to comment @connecteev, this problem, unfortunately, was repeated with a long-running dev-server, and was "solved" only by rebooting Mac or a long shutdown of the dev server. I can assume that the problem is a memory leak, because at certain points the dev server simply stopped responding, and displaying the status of pending. I also assume that bug is probably related to switching to the event model of HMR or changing the logic of file watching.
@ruslankonev this issue is not limited to a Dev mode, I also have it in production. Try to lock vue-meta
to v. 1.6.0 and let us know if this issue is still reproducible for you
In this GIFs you can see differences happening while browsing through the two versions. The old version is very smooth and fast.
Version _2.8.1_:
Version _2.9.2_
Version _2.9.2_ _after ~ two minutes of browsing_
@ruslankonev this issue is not limited to a Dev mode, I also have it in production. Try to lock
vue-meta
to v. 1.6.0 and let us know if this issue is still reproducible for you
@ruslankonev @pimlie, web browsing returns smooth and fluid with the previous version of vue-meta
(the _1.6.0_).
So probably the issue it's related to this update.
@LuXDAmore Thanks, unfortunately its still not a reproduction I can use to debug this.
Could you make Heap snapshots at start then after some clicking when it became slower and see if there is an obvious grow in eg VueComponents count?
--edit--
Also, the last gif says _uid: 2787
. That would mean that 2787 VueComponents have been created on your page. Does that seem about right to you?
@LuXDAmore Thanks, unfortunately its still not a reproduction I can use to debug this.
Could you make Heap snapshots at start then after some clicking when it became slower and see if there is an obvious grow in eg VueComponents count?
--edit--
Also, the last gif says_uid: 2787
. That would mean that 2787 VueComponents have been created on your page. Does that seem about right to you?
I'm trying to re-create the problem in a repo.
I have a big Heap snapshot after browsing some links (~ 1 GB)..
Later, I'll try to upload a small one here, with the repo.
--edit--
Yes, the component is _re-created_ due to <nuxt :nuxt-child-key="$route.fullPath" />
, in layouts.
I think I've made some progress myself as well, I think I can (partially) reproduce this issue with one of my own projects. Looking at this project, I think your metaInfo issue is actually an effect of the real issue because I also see the number of VueComponents growing and growing (which it shouldnt). It could be that if VueComponents are not correctly destroyed that vue-meta will keep accessing them when the metaInfo needs to be updated which could cause your error.
Still debugging though, so nothing is sure yet.
Yes, probably could be only an effect of the real problem..
I'm trying to reproduce the issue HERE.
I've uploaded the Snapshots i've made, you can find them on my Dropbox
_The "Small test" folder contain the heap snapshot of the codesandbox's test, instead, the "Big project" folder hold the previously mentioned big file ( ~ 1 GB )._
@LuXDAmore Thanks, did you make those dumps in dev or in production mode? There are a lot of detached nodes which I normally only see in dev mode with hot reloading.
Also in the dump I see a component m-button
which also has a computed $metaInfo
prop. Do you really have dynamic head
defined on a button? If so, why? Or are you using nuxt-i18n and did you enable global seo ?
@pimlie Yes, it's in debug mode, do you need one production-mode example?
And no, the m-button
has no computed / key
with any $metaInfo
or head()
: head()
is present only in pages.vue
and / or layouts.vue
.
nuxt-i18n
is not present, our modules are: vue-scrollto/nuxt
, @nuxtjs/browserconfig
, @nuxtjs/apollo
, @nuxtjs/pwa
, cookie-universal-nuxt
, nuxt-compress
, @nuxtjs/sentry
, @nuxtjs/axios
, @nuxtjs/google-tag-manager
, @nuxtjs/recaptcha
and nuxt-jsonld
.
@LuXDAmore Look at this screenshot from your 1.7GB head dump, why did vue-meta add a computed prop $metaInfo
on that m-text
component? Thats really an issue you should look into, do you have a global mixin adding a head
function?
The only prop which should be added by vue-meta on all components is _hasMetaInfo
for backwards compatibility.
@pimlie My customer has a mixin
shared between some pages.vue
(with head()
inside), but it's the only mixin
present in the entire project.
Correct me if I'm wrong, but it's not global (because it's only in some pages.vue
) and it should release memory due to the <nuxt :nuxt-child-key="$route.fullPath" />
, no?
_pages/faq.vue_
import { headForPageWithAlgoliaPagination } from '~/mixins';
mixins: [ headForPageWithAlgoliaPagination ],
There are no other mixins.
There is a design system installed as a plugin (_M-Components_), so it's external, and no meta
, head
or computed
are injected to it by us.
The problem happened only with the new version of vue-meta
.
I can try to remove the mixin and take a look at what happens, ok?
A mixin is a global mixin if somewhere its called with Vue.mixin({ <the-mixin> })
, maybe thats done in the mixin file by mistake?
I looked into possible memory leaks yesterday and I really dont know. As mentioned I found some stuff in an old project but I am not sure if thats caused by vue-meta because the strange things I see I see both with vue-meta v2 as v1. So probably thats just buggy code in that project _OR_ the issue also exists in vue-meta v1 but somehow its more prone to show up in v2.
At this point your guess is as good as mine unfortunately :(
Ok, yes i know, but there are no global-mixins in project.
A mixin is a global mixin if somewhere its called with
Vue.mixin({ <the-mixin> })
, maybe thats done in the mixin file by mistake?
I think it's something happening only in client-side, during SPA browsing..
Due to the slow navigation, seems an issue about complete/resolve-navigation
..
I looked into possible memory leaks yesterday and I really dont know. As mentioned I found some stuff in an old project but I am not sure if thats caused by vue-meta because the strange things I see I see both with vue-meta v2 as v1. So probably thats just buggy code in that project _OR_ the issue also exists in vue-meta v1 but somehow its more prone to show up in v2.
Probably it's inside some nuxt-modules
, i'll try to remove all of them and start over.
@LuXDAmore @AndrewBogdanovTSS
I've released a new beta of vue-meta for v2.3
, you can install it with yarn add [email protected]
Once the computed prop thing is solved for Luca, it would be interesting to see if you still have issues with this beta. There are two new option you can toggle which might be interesting in your cases, see this pr comment for an explanation: https://github.com/nuxt/vue-meta/pull/452#issuecomment-532184844
My comments in that PR still needs to be added to the docs, will do that once the suspicion of a memory leak has been removed.
@LuXDAmore Are you using Nuxt in SPA mode or Universal? If SPA, could this be an issue here as well? Seems unlikely as you mentioned client side
@pimlie Thank you very much for your update, i'll try it later.
I've finally founded my problem, it's the nuxt-jsonld
module.
Disabling the module brought back the normal behavior.
I need that module so i've opened an issue in the repo and updated the reproduction link and i've added that module.
---edit---
@LuXDAmore Are you using Nuxt in SPA mode or Universal? If SPA, could this be an issue here as well? Seems unlikely as you mentioned client side
I'm using nuxt in universal-mode
.
That module uses a global mixin to add head info, that will slow down your site a lot indeed (for the why see the earlier referenced nuxt-i18n seo page).
@AndrewBogdanovTSS do you by any chance also use that module?
I haven't seen this problem since but FWIW I have also never used that nuxt-jsonld module..so it's not that.
@pimlie yes, I also use nuxt-jsonld
@pimlie I've tested [email protected]
with [email protected]
I also inserted
this.$meta().setOptions({ debounceWait: 50 })
into mounted hook of my default layout and everything seems to be working very fast now, even faster than with [email protected]
๐ I will make some futher tests both in dev and in prod in subsequent days, but by now it looks very promising!
Thanks a lot for your help on this issue! ๐
One question I still have, is the default layout mounted hook a good place to set vue-meta configs or it better be set in some other part of the project?
@AndrewBogdanovTSS Why use a mounted hook and not the head method in the default layout? The new addApp
functionality in v2.3
is mostly meant for modules etc which are _not_ Vue components. If you already are in a Vue component, use the head method.
Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:
Issues that are labeled as pending
will not be automatically marked as stale.
@AndrewBogdanovTSS Ah I see, this is where I advised to use the head method. I guess I was thinking about meta info stuff when you mentioned vue-meta configs and not about the options. Sorry about that.
Anyway, since Nuxt v2.10
you can set the non-essential vue-meta options directly in your nuxt.config. Non-essential are the options also marked runtime
in the [vue-meta docs](https://vue-meta.nuxtjs.org/api/#plugin-options.
// nuxt.config.js
...
vueMeta: {
debounceWait: 50
}
looks cool, I will try that now. Thanks, @pimlie
Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:
Issues that are labeled as pending
will not be automatically marked as stale.
Nuxt Version - 2.11.0
Steps to reproduce issue
@Jaynam07 is it happening for you in production mode or only in dev?
@Jaynam07 is it happening for you in production mode or only in dev?
For now I am trying only in dev mode.
It might be related to a live reload module. I've been experiencing this myself when I open multiple local tabs maybe some issue with websockets that dev server is using
Getting Uncaught (in promise) TypeError: Cannot read property 'call' of undefined - runtime js
and also common js on prod.
I had the same problem.
Vue.js devtools chrome extension!!!
I don't have enough info how to resolve it properly but removing it from chrome made my Nuxt app alive.
I had the same issue, after some changes the site didn't load anymore, localhost:3000 was spinning forever. The issue was related with an initial Axios call during startup in combination with a wrong baseURL
setting in nuxt.config.js
.
My quess is that the initial call went wrong (API not reachable) but instead of throwing an exception or running into a timeout, nothing happens so it just seems the app hangs up. After correcting the baseURL, everything runs smooth again.
Thank's @mjzarrin, I had the same problem.... I can confirm removing Vue.js devtools chrome extension is correcting the problem for me too !
In my case, it was the wrong use of a middleware.
Most helpful comment
I had the same problem.
Vue.js devtools chrome extension!!!
I don't have enough info how to resolve it properly but removing it from chrome made my Nuxt app alive.
Vue.js devtools chrome extension