[Idea]: Provide support for server-side rendering

[lauriii]

In the previous discussions we have decided that Drupal shouldn't require Node as a hosting dependency. During the same conversations we had an idea that we could make Node a soft requirement for hosting, so that site owners who have Node available, could get benefits from server-side rendering. However, our infrastructure in its current state doesn't support server-side rendering and our code bases server-side support isn't being actively tested.

Proposed solution

Provide infrastructure for rendering the application in server side. Provide tests ensuring that both, universal and client-only rendering works.

[justafish]

With our current stack I don't think this would be difficult to do (redux-saga makes it p straightforward), but I'm not sure that just rendering on the server-side would be very beneficial to us as all our interactions still require JavaScript. I think this would only be useful if we also made those interactions work without JavaScript, and I'm not too keen on doing that for this application.

[dawehner]

I do agree with @justafish that we need to have some benefit resulting out of that. Right now at least I think we would have a bigger benefit by investing in other pieces of the application.

[dawehner]

Should we close this issue?

[martinfrances107]

I have some disquiet about out current performance.

Even at an early stage of development, I place value on periodically checking out a third parties view of our performance. The gold standard at the moment is Chrome's lighthouse [ although that is a a whole subject in itself - so please feel free to interject]. Time to first meaningful paint is a really difficult standard to pass.

I am happy with just having the inkling that one day we will get there. BUT at the moment our scores are so well off the mark - that I don't see how we will get there without some server side rendering.

I am juggling with too many issue I want to fix..at the moment. Can we keep this open - just as a marker.

[justafish]

@martinfrances107 The problem with that is the user will still experience a delay to the app becoming usable, and will click around with no response, which is frustrating for them and makes the app seem slow/buggy.

[martinfrances107]

@justafish having electronic communications, without the context of body language is always tricky -- so I hope this comes across as a friendly conversation.

The problem with that is the user will still experience a delay to the app becoming usable,

To repeat your concerns and mine ... Can I set-out the issues formally.

Regarding the potentially new cold cache response performance.

The increased size of the DOM and the increased server response time is a new step/cost in the critical path. and in the context of lighthouse - it will

A) Degrade the "First iterative" time
B) Improving "First meaningful paint" time.

So depending on the particulars of specific website -- in the milliseconds between the user seeing the button and reaching for it he or she may get a good or bad experience ... it all depends

What further complicates this is the developer must deal with the vastly different response characteristics of 3g and of a fibre to the home link... and the warm cache response is a whole new story.

Google's Lighthouse tries to grapple with all these sometime contradictory aspects into a basket of performance measurements called the "Perceptual Speed Index" (PSI )

In short my formal response to your posed problem is

"I don't know whether A or B is more important"

Your criticism does change the thrust of the issue... I should a do a little research into identifying why our PSI is so atrocious.

Anyway I hope helps to more fully describe my unease.

PS:

Maybe the D8 routing delay is a fundamental weakness... and limits its application for web apps
that is the thing that bothers me a night...