I recently upgraded from Meteor 3.0.4 to Meteor 3.1, and I’ve noticed a significant slowdown in the initial page loading time. It went from a smooth 720 ms to a sluggish 6.75 seconds, which is incredibly frustrating.
My first thought was that the new core Roles package might be the culprit, so I downgraded to the alanning:roles package, but that didn’t help. This issue persists in both my dev environment and on Galaxy. When I revert back to 3.0.4, the loading time improves back to 700ish ms.
My site uses service worker caching, so all pages and files are loaded from the cache. However, something with the 3.1 upgrade seems to cause a significant delay that doesn’t even show up in the Chrome DevTools network tab. Everything appears to load in a couple of milliseconds, followed by a huge pause, and then the page finally loads in about 7 seconds.
I just notice that I can experience the same slow initial page loading on the galaxy beta dashboard as well: https://galaxy-beta.meteor.com/ so it can be easily replicated there.
we’re working in our app with Meteor 3 for some time now and that doesn’t seem to happen to us.
If the files are loaded but the app doesn’t “start” so to speak, it might be a publication / subscription issue maybe? Or a connection issue of one kind or another?
Is it just the UI waiting? Do you actively wait for some things to become “ready” on the client before you draw the UI?
Do the Meteor.startup(() => {}) blocks trigger immediately after load or much later / with the app seemingly starting after 7 seconds (smack a console.log() in there)?
Are you using meteor version 3.1 or below? The issue is happening only on version 3.1. It’s not related to the publication/subscription level, because that’s happening after the First Contentful Paint- FCP and loading the FCP takes around 6-7 seconds. It’s even happening on meteor’s official https://galaxy-beta.meteor.com/ site if you open it up and you can check the network tab for clues. We checked using different browsers, computers, android and ios devices and the issue is happening on all of them.
We only have the ReactDOM.createRoot function in the Meteor.startup, so there is nothing that could block the render. Also the issue is still there if I turn off or on the service worker caching.
According to https://galaxy-beta.meteor.com, it uses version 3.0.4, not 3.1. The issue with Galaxy likely isn’t due to 3.1; it seems to be the app itself, or an issue previously introduced.
For those experiencing this problem, is your site accessible for us to gather more information? You can contact me directly if you’d like to share these privately.
For me on an old and rather slow android tablet behind a decently fast connection the Galaxy beta site just shows a blank white page for about 45-60 seconds and then the page appears. So something is definitely wrong here.
We need more evidence to confirm any potential regression in performance. However, we’ve identified general areas in the app that could be optimized, such as reducing bundle size and addressing implementation complexities. Issues with cache, service workers, and similar components could negatively impact the app if not properly maintained.
In Meteor 3.1, we’ve updated key tools like Node, Mongo, and Express, along with other adjustments on the tool. While we don’t think that could leave significant performance regressions, we can’t discard entirely.
I’ve been discussing this privately with @abyss. Has anyone else noticed this regression? Could someone provide Lighthouse analyses for each version or any other data to help evidence the issue? @pmogollon?
In my case we tested rolling back and nothing changed, the app in question is an internal app and we were not that carefull on making it fast on initial page load. That combined with some internet connection issues can make it appear as something is wrong, the same happens with galaxy-beta, which also on my macbook takes like 9 to 10s to load.
Okay we found the issue and it wasn’t caused by the meteor 3.1.0 upgrade but an icons package update that filled up the initial loading page with stuff. Downgrading the package solved the issue for now. Thanks everyone!
@nachocodoner Interestingly, I just tried https://galaxy-beta.meteor.com/ and the same thing happened in my case. It did not take 45-60 seconds like in @vooteles’s case, presumably because of faster device (a Core i9 laptop), but still a significant amount: 5 to 6 seconds of a white page.
Unfortunately, the records in the Network tab of Chrome DevTools look meaningless, because the page refreshes as the site finally loads. Lighthouse looks fine, but that won’t tell you much, because I suspect there is something with the event loop which happens even before Lighthouse kicks in. Use an Incognito window. If it all looks fine, maybe use a VPN and connect from the UK, because here is where I tested (wild speculation, but what if there is some CDN-related issue?).
Note that the page title loads instantly, so the HTML arrives quickly, but then it stalls. During those first few seconds, the page is frozen, right-clicking on it doesn’t show the context menu, for instance.
Hey everyone, I really appreciate you taking the time to share the challenges you’ve been facing on Galaxy Beta. I understand how frustrating these issues can be, and I want to assure you that we are dedicated to making improvements in load speed, push-to-deploy functionality, and our overall infrastructure.
Just to clarify, Galaxy Beta is currently on version 3.0.4, not 3.1. I found a problem with the RemoteCollectionDriver in the MongoDB package, which is why we haven’t been able to upgrade to 3.1 yet. I want you to know that @leonardoventurini is already working hard to resolve this issue. Thank you for your patience, and feel free to report any issues using our chat inside the Galaxy app or support email support@meteor.com.
