Meteor 3.0, what the best fomular for React + SSR?

I wonder do we have a new method, new library to implement SSR for react app?
My goal is just to improve lighthouse score. (Not for logged in users).

1 Like

Would the Lighthouse score be good enough for your case?
Screenshot 2024-04-05 at 13.20.57

We could invest more in it, but so far what we have done is:

  • SSR is enabled via communitypackages:react-router-ssr.
  • SEO is enhanced with mdg:seo for integration in Galaxy.
  • Static assets and app bundles are delivered through a CDN.
  • We prioritize image optimization, ensuring correct sizing and using the .webp format, with .jpeg or .png as a fallback.



I haven’t seen anything, yet, that works with all the features of React 18 and Meteor 3, namely:

  • React Suspense + dynamic imports
  • React Suspense + async data loading
  • Using renderToPipeableStream
1 Like

Thanks Fred, It looks good enough to me. Do those packages work with Meteor 3?

1 Like

I’m looking for those features too. I hope we will have new server-render package supports them when Meteor 3 officially release.

server-render looks sufficient. The problem with renderToPipeableStream is support with the boilerplate-template package since react now expects to build the entire html (which Meteor currently doesn’t allow).

I had a very crude PoC to make this work but I wasn’t able to continue due to new business requirements we have to prioritize.

The mdg:seo package has an alpha version compatible with Meteor 3.0. However, communitypackages:react-router-ssr does not yet support version 3.

This post might help devs looking at increasing “lighthouse score” (as indicated as the goal for this topic).

Why do you need to increase the lighthouse score? I can think of two things:

  1. Improve usability by improving the first load of pages
  2. Improve SEO ranking (a side effect of #1).

These goals are where pre-rendering is misunderstood by many developers. Pre-rendering (the one WITHOUT client hydration) is used so that Google can correctly index your javascript pages.

But wait, my pre-rendered page gives a very high lighthouse score?

It does not matter if you are not serving that same pre-rendered content to your users.

  1. Back to number one above, it will not help usability if your users do not load and see those pre-rendered pages themselves
  2. Lighthouse score is NOT a ranking factor. Page Speed Insights (PSI) score is the ranking factor.

What is the difference between Lighthouse and PSI? Lighthouse is used by developers so that we can actively improve the performance of our pages for our users. PSI score is a collective field data from actual chrome users. Therefore, if the users are NOT loading and seeing the pre-rendered page, it will not affect the PSI score.

1 Like

This is a bit off topic, but probably worth mentioning anyway. I’ve seen a lot of web projects that have rather complicated setups but actually serve content that rarely changes. So before taking on all that technical complexity that is being discussed here, my first question for web projects would always be: can a static site generator do the job in this particular case? If the answer is even remotely yes, then please do look into using a static site generator before considering other options. Modern tools for managing content in static sites has gotten really good.

Meteor’s own site is maybe an exception here. Dogfooding has real value in technology projects. But whenever the word “hydration” comes into play, there better be a good reason why tehnically much more performant and easier solutions were cast aside.


Could you suggest a static site generator? I searched around and gatsby sounds great.

Next for React and Nuxt for Vue are the popular ones. They both have configuration options which determine how static the built site actually is.

1 Like

@copleykj mentioned on last stream that he will be looking into fast-render and similar packages to update for Meteor 3 this month, but if anyone wants to go in and update then that would be welcome.