I personally wouldn’t worry about that speed index number and focus on optimizing the right things. If premature optimization is the root of all evil, then prematurely optimizing the wrong thing is the devil himself.
You focused on the bundle size which was not your issue, 1MB is not large let alone huge, it’ll be gziped and cached. Thus what you really need to optimize are the First Meaningful & Contentful Paints, those have a huge impact on the perceived initial load time by the user.
Here is a screenshot of an optimized meteor app audit:
You can see that what has been optimized are those two numbers, it’s really big app but the initial paint takes only 0.8s. This was achieved via SSRing the main page. As far as the user is concerned, the site is blazing fast. To get that fast paint, you need remove anything not critical from the main rendering path (any JS, CSS that could block the rendering), you can either remove them, reduce them or load them later. If you want them to not-block then they need to be loaded at the the end of the body, but do you really need the checkout scripts on initial render?
For SSR, read the Meteor guide carefully, you can SSR your main page regardless of the router but it’s not that trivial and require some work. Your other option is to accept the 4s delay and show loading indicator.
I hope that helps!