Hello people,
I am building a site using Frontity (Ofcourse), and I just wanted to know if there’s any need or way to use renderToNodeStream(). I want to use the function because the Initial server response time is high and I want to reduce it a bit.
Thanks, as always,
Pranav.
Hi @pranav.v
When you say the initial server response time is high, do you mean the server hosting Frontity or the server delivering the WP REST API? If it’s the latter I don’t think renderToNodeStream will make much difference.
Hey @mburridge,
No, I don’t mean the server delivering the WP REST API. I mean the server hosting Frontity. And I don’t entirely mean the server.
What I meant was:
Consider a scenario, the node server is processing, to send a HTML response to our request, in my opinion, the server first processes the whole of HTML and then sends the response to the client. What I mean to do with renderToNodeStream() is that the server can send in data partially as it is processing, so if the HTML is too big, the response time will be less.
I know it wouldn’t turn the mountains, but I think it might feel different to the user.
Thanks,
Pranav.
Hi @pranav.v
OK, I see now. Thanks for the clarification. I’m going to pass this one to members of our dev team, who will have a deeper understanding of how Frontity works internally than I do, to see if they can help you with this. @David, @luisherranz can you help with answering this?
Uhm, interesting. 
The package in charge of doing the SSR is the server/index.tsx file, in @frontity/core. We are using renderToString() to generate the HTML code, or renderToStaticMarkup() if there is no client chunks (i.e. if no hydration is needed).
But that’s not the whole HTML code - it’s only the one generated by React. The rest of the code is generated using a “template” and written to the body response by the Koa server.
What you mentioned is to use renderToNodeStream() or renderToStaticNodeStream() instead, right? In that case, I think we would need to refactor that part to use streams instead of strings. It doesn’t look that hard, though - you can even return a stream in the body response with Koa.
The only thing I don’t know if there could be any problem regarding serverless. @luisherranz, do you know more about that?
So what I understand is, renderToString() sends the whole HTML string generated by React, and then HTML code for body response(either post data, archive, anything) generated by template is written using event handlers or anything. right?
Yes, I think renderToNodeStream() will be somewhat helpful. I just peeked at server/index.tsx file, in @frontity/core and found that using renderToNodeStream() will not be much of a challenge if we only need to change its output method. Will look to return stream in body response with Koa also.
Thanks, @David,
Pranav.
I think that back a the time we didn’t use renderToNodeStream because react-helmet was not compatible with it. Not sure about react-helmet-async which is the one we are using now, to be honest.
Hey @luisherranz,
No problem. I think it’s all right without renderToNodeStream for now. If we’d need in future, we will implement it.
Thanks,
Pranav.
Sure 
Hi guys,
Is there an update on this. Is it possible to implement renderToNodeStream by any chance?
I keep getting the Reduce initial server response time opportunity on PageSpeed. The first load of the website is quite slow (~3s). I have just done a test removing most of the components from the homepage but I still get the site to load slow and PageSpeed to complain about it.
Is there a solution to that with Frontity?
Thanks