TL;DR
Possibly the gain will be small, if there is any, because Bigpipe does not seem a suitable technique for the scenario proposed in the question.
Performance is a box of surprises
Not it is possible to state whether Bigpipe will positively or even negatively affect the performance of an application without effectively implementing and collecting before and after data.
In addition, any optimization should be done within a relevant context. Users present different habits and usage needs of a system. Bigpipe helps parallelize the display of a composite page, but is the biggest user problem not one of the queries that takes a long time to return? In such a case, you can invest all the resources in optimization techniques and the user will still be dissatisfied because the information that interests him continues to take a long time to appear.
Only start thinking about complex optimization techniques if actually the performance is a problem and a diagnosis has been made so that you have confidence that the appropriate technique has been selected. Never apply optimization techniques without it, as the cost to implement and maintain them is high and will be money thrown down the drain.
Why not use Bigpipe
By system description, there are not several sections in the system that are displayed at the same time.
A parallel implementation that only displays a single page at a time will only generate system overload, i.e., unnecessary processing.
Alternatives
For a system that loads all resources only once, the concern is on the first access the user makes to the homepage.
Well, the first step is to put everything static, such as images, styles and scripts, minified in a CDN to ensure the shortest possible time to download resources.
Once done, measure load time without cache usage. If not satisfactory, you can use some simple techniques:
Flush header Early
Some Engines of templates assemble the whole page and then send it to the user. Others do buferization. The problem is that in this case the browser will have to wait the processing on the server until it receives the header and can start downloading the declared styles and scripts.
Change this so that one occurs flush that send the entire tag <head> in the first milliseconds of the request. That way, while the server thinks, the browser is downloading the resources.
For this to work even better, declare all tags <script> in the header with the attribute async for the browser does not lock the rest of the page while loading the scripts.
Pre-loading in the background
A simple way to give a sense of fluidity is to pre-load the features of the screens on which the user will access while he is doing something.
A very simple example would be to pre-load the static system resources asynchronously while the user is logging in or is looking at the home page.
It’s almost a cheat, but that way when the user accesses a system screen the browser will have the resources cached.
Beware of caching
Systems that need scaling should try as hard as possible to store state. Create services stateless allow distributing the system, avoid delays with code cache (not initialized cache), avoid Stale data (old data being used incorrectly), and so on.
Improperly made caches are a tremendous headache later, a real source of problems, limitations and bugs.
Distributed cache is costly for a small system, after all synchronizing information also costs time, and is complicated for a large system.
A cache is like putting a mutant state on the system and you will always have to worry about whether that state is properly updated and how the update will be done. Often it’s not worth it.
Performance depends on implementation
Regardless of the optimization technique that applies, your implementation will always speak loudly.
A poorly implemented Bigpipe can increase the total time until the event ready for user. A poorly implemented cache can be worse than a database query. An SQL code that does table scan can be worse a REST call to an external service.
These examples are reasons why the major concern is always with a good system implementation and less with specific performance improvement techniques.
Please avoid long discussions in the comments; your talk was moved to the chat
– utluiz
I do not understand why the question was closed. Unless I am mistaken, the answer seems obvious to me. A bigpipe technique mainly serves to decrease the total time in which the page can be viewed by the user, making better use of the parallel and asynchronous loading of page snippets and features like CSS and JS. If the system loads these resources only once and seems not to be divided into logical and independent sections, Bigpipe brings little or no gain.
– utluiz
Good evening @utluiz The question was closed by the fact (my point of view) that "wear or not" is something that has variation from server to server and number of clients and what potential the project intends to achieve, so I believe that the author understands the technique, but there is no way to answer if it would make a difference in his project, because the question was this "or make no difference in performance?", maybe we had to have closed as cannot be reproduced, but in my opinion it was not well by ae. However we can reopen if find interesting. Until tomorrow.
– Guilherme Nascimento
@Guilhermenascimento I agree that the question was very specific for the AP project. But I see it as "can the X technique be used in the Y scenario?", which would be perfectly responsive even in theory. Perhaps if the AP moves the question a little, especially at the end, the thing becomes clearer.
– utluiz
@user3163662, I suggest you slightly change the last paragraph of your question to something like: Would it be applicable to use Bigpipe in this scenario? It could contribute to some difference in performance?. I believe that way the question becomes less opinionated.
– utluiz