Future proof SSR?

Hi. I have an e-commerce app that uses flow-router and a mix of Blaze and React.

I have only 1 route, not requiring authentication, that I would like to use SSR on, in order to improve loading time (currently around 10s). I’m in the process of refactoring that page so it uses only React.

Would it be easy to use one of these SSR solutions on only one route, while keeping my existing configuration for the rest of the app?

1 Like

For initial state of collections used all over the app, I like to inject their data in the HTML payload. I synchronize them on time basis.

For the other collection, I basically starts empty and fill them once the subscription is done. I haven’t tried tried yet to use redux-persist but that sound like a good way to avoid reloading all the data, especially when the network does not allow to do so.

For your only one route and with an already setup router, I would use MDG’s webapp. By analysing req.url you could render either your landing page for ‘/’ or a simple spinner for the other.

The Webapp atmosphere page points to a non-existing documentation page. Same on the github repo page. Do you happen to know where these docs have been moved to?

This link should be better: http://docs.meteor.com/packages/webapp.html

1 Like

Perfect, thanks! This is what I was looking for. Did not know that Webapp was part of the official Meteor docs.

Thanks for your response! I never thought to look into webapp.

The route that I want to render server-side is not a landing page, it’s a product page so it does need some data depending on route params. But yes webapp seems like a good start to handle that route differently from the rest of the app, I’ll look into it. Thanks!

“Future proof” in Javascript is a bit like chasing rainbows.

@PolGuixe: For those who asked for a maintained react-router-ssr, I’m using the fork jasonnathan:react-router-ssr which has been updated and is working great with latest React etc.

I’m using:

  • Meteor with DDP
  • react
  • react-router
  • react-router-ssr (handles the data, has been updated for use with Apollo)
  • react-helmet (give me total inheriting control over the document head for SEO)

and I am very happy with it. Fast render times, fast empty-cache first page renders, etc.

You can check out my development site dev.speako.ca for a working (most of the time) example of the result. You should see the first render within 1s and then when a webfont arrives it will repaint once. As the big 1MB script file loads in the background you can still do basic interactions like open the mobile menu thanks to inlined script that coordinates with react as it boots up.

For me in Vancouver on an empty cache served from a $10/m DO droplet:

  • Time to first byte = 73ms
  • Time to download all content needed to render (HTML + CSS, excluding images): 84ms
  • Time from initiating request to rendered DOM (without waiting for webfont): 910ms (includes SSL negotiation)
  • Scores 90%+ on Google Page Speed Insights (lowers your AdWords costs!)

To improve performance, I wrote two more modules that:

  • Strip out all unused CSS selectors and inlines the actually used CSS
  • Loads all scripts async

I feel this solution is as about as future proof as the churny JS world gets these days. All of these packages are currently maintained. All of them have a big active following except react-router-ssr which is the weak link but that whole package is only 450 lines including comments (so not out of the question to include a project scope) and supposedly already plays nice with Apollo.


Super nice :thumbsup:

For our SSR package, I’ve setup a demo on a free tiers: https://demo-xseptfpdip.now.sh/

It scores 91 on mobile and 97 on desktop. Not bad.

The demo content is equivalent to react-router-4 demos with some additions specific to Meteor’s collections & methods. You can also test the REST api capability at /api/ready/.

1 Like

Can you explain what all this Meteor + Express is about? Don’t Meteor and Express overlap in a very messy way? Are you only using Meteor as a backend and Express for the front? Why?

The demo appears sick at the moment.

Meteor provides a connect. Express is a well known server which sits on top of connect. Using both, Meteor & Express allows you to easily creates webhooks, REST endpoints, … Basically, it provides a Picker like capability to Meteor :wink:

We have also added basic routes used for SEO: robots.txt & sitemap.xml, namely.