I want to implement SSR in my React Meteor app. The Meteor docs are pretty basic in this respect:
I can imagine that things are not as easy if you have to consider accounts / login and other stuff like i18n. So I looked for tutorials on YouTube, but most of them are pretty old. Same goes for SSR related topics here on Discourse.
Does anyone know good tutorial websites or videos that are more up-to-date?
SSR is a extensive topic.
Do you have a list of goals you want to accomplish in the server?
Thanks for your response.
My goal is pretty simple: I want to improve the loading times of the landing pages our customers can set-up on our platform.
Here’s an example: Linkin Park METEORA|20 Hunt
The Lighthouse performance of this page is pretty poor (55 on Desktop, 28 on Mobile). I definitely have to improve this.
I already achieved a couple of optimizations, e.g. by facading the YouTube videos. And I tried to get the JS bundle down with Loadable Components. But still, the performance is not good.
So I was hoping that SSR would give me a good performance boost on first load.
Hey @waldgeist, have you tried using
No, I haven’t. Thanks a lot for the hint. Totally forgot about it.
I have now integrated the SSR community package. Yet I ran into an error on the server console:
Error running template: undefined
Since the error message is pretty “undefined”, I have no clue where this error might come from?
In general, it seems as if the SSR kicks in, since I had to fix quite a number of issues in my components (referencing Session and window, which are not available on server-side) to even get that far.
I am also wondering if the
index.html has to be available to the server as well? This is not documented in the docs.
I’m using a quite complex app and routing setup, including ConnectedRouter (redux), i18n and another of other contexts. Maybe this is causing the issue?
Ok, I debugged the server and got it working. The reason was that the
router part of the redux store was missing on server-side.
Still, I am having an issue, or rather a general question on SSR: If I load up my app with SSR enabled, it first shows the page for users who are not logged in. Then, after hydrating, the actual logged in page appears, but not with the right styles.
Is there even a way to server-render pages where the user is already logged in?! If could understand if this is not possible, but in this case, the whole SSR thing would be useless in my case.
In addition to that, the problem is even a bit broader. There are pages that would work without login, yet for them the server renders the root page and after a while the actual route page.
If I log the
pathname property of
router, it shows
/ instead of the actual route on server-side.
Edit: This error seems to be coming from
ConnectedRouter. If I keep it out of the routing stack, it works.
Before proceeding, answer these questions first:
- What is your goal for SSR?
- Why do you need to implement SSR for logged-in users?
Implementing SSR for logged-in users has some disadvantages:
- Depending on the data you display for a logged-in user, it might not be possible to cache the page for each user
- That will add a lot of processing server-side for initial pages for each user
If you are just after a high lighthouse score (which means good SEO), then you do not need to do SSR for logged-in users
Yep, I came to the conclusion that SSR for logged-in users is too much. However, I also came to the conclusionthat SSR won’t work in my case anyways. After implementing it, the Lighthouse score was pretty much the same, so no real gain.
I just checked your sample page above. For a guest user, SSR would help the initial experience. Your initial loading is on the slower-side of the fence.
SSR can give users something to do something quickly (and therefore perception of speed). But it doesn’t speed up the actual loading of the app which seems like your bigger concern
Thanks. I have a version here that uses SSR for that page, but the Lighthouse results are still disappointing. And if I consider all the changes to make it happen (and still having problems with the routes working correctly), it didn’t seem to be worth it.