Why not use prerender.io? Works fine for me and I’m using flowrouter.
I just cloned it and put it in the packages directory. Those will get precedent over everything else.
The “fix” is pretty much what is in https://github.com/meteorhacks/inject-data/pull/12/commits/dc8bf0cd55ae00832e9f8b5a3da0b024a8a9dc0e, but your needs may be different.
I haven’t looked at this in awhile, so I have lost a lot of context on it.
1 Like
I may be mistaken, but I thought prerender was primarily for SEO.
For me, the big win of SSR is entirely performance related; sending the html from the server with the necessary data to display immediately.
Honestly in today’s times I don’t really get the point of SSR anymore. A modern app should load at the most within 2 seconds with the first paint, PWAs should load in less than a second once loaded at least once. Do we really still need SSR for this? I admit, there’s probably still a minor speed improvement but still.
1 Like
We live in a world where it’s totally cool that Facebooks mobile app is over 200 MB and requires a new update every week while we complain about a 20 KB JQuery dependency.
So that’s the difference! Today I learned.
That’s the difference between a mobile app and a website.
A mobile app can be downloaded when convenient, but a website is downloaded, and a user must wait for it, before they can view the content the first time.
In this case, especially if your app doesn’t require jquery (esp react apps), it’s a double whammy because your user is both waiting for the 30kb download time and the JS parsing time, which for the entire bundle, is significant 800ms-1.2s on my app, more on larger apps, so every bit helps. Removing an unused jquery is a pretty big win imo. It all adds up.
If an app has SSR, then the visitor has useful content to view while the JS bundle downloads and parses and the bundle size doesn’t matter quite as much.
That worked!! Finally found and removed jquery! So happy. It was a dep of flow router’s dep. Thank you @moberegger and @robfallows Hopefully this helps others too!
1 Like
You can get a gauge of how much difference SSR would make for your app. Run it through webpagetest.org and then compare time to the first images loading, since in most cases that is when a useful render has occurred for the user:
html + JS download & parse + websocket connect & data download (if not using fast render) + first images
vs
html + first images
For my app, it would remove 1.6-2s for JS download and parse, making it load in less than half the time. So it’s a big win for me, but it depends whether your users visit your page less frequently and with a clean cache (more like a website) or more like an app that is used regularly for long durations. First load time won’t be as important if it’s the latter. (Edit: JS download and parse + websocket connect and download take 3s in my most recent test. Would be a big win.)
Parse time is something I hadn’t considered. Great point. Also, how did you refactor FlowRouter to work without the JQuery dependency? I’m in the exact same situation as you.
- Create a ‘packages’ directory in your project
- Change into it and run:
git clone https://github.com/meteorhacks/inject-data.git - Open these files and make the following changes https://github.com/meteorhacks/inject-data/pull/12/commits/dc8bf0cd55ae00832e9f8b5a3da0b024a8a9dc0e
- Restart your app. Your inject-data package will take precedence over the offending dependency.
Credit to @moberegger for the solution.
Removing Jquery was an even bigger win than expected for my app. Enjoy!
1 Like
Thanks! Crossing my fingers this gets rid jquery once and for all.
I would also look at the fork made here: https://github.com/abecks/meteor-inject-data/
There was an issue introduced somewhere in 1.4.x that caused fast render to stop working (inject-data being a dependency of fast-render). I can’t remember specifically what it was, but you can take a peak at the commit history and see if those changes are relevant to you.