Sans doute pas sans votre propre implémentation de serveur ESI, et même dans ce cas, il est discutable de savoir si cela vaut la peine de subir une baisse de performance.
Si je comprends correctement cet article sur BigPipe, tout ce que le serveur doit faire est a) de flush immédiatement du contenu HTML statique vers le client et b) de démarrer quelques threads de rendu de manière asynchrone et de flush le résultat lorsque le thread a fini de rendre. Le reste est la magie du javascript et n'a rien à voir avec le framework côté serveur.
Symfony est capable de rendre un document HTML simple et d'inclure des balises ESI, donc la première partie est couverte. Mais les ESI dépendent de l'ordre dans lequel les balises sont rencontrées. Cela signifie que même si je suppose que la plupart des serveurs de cache commenceront à traiter toutes les balises ESI de manière asynchrone, ils ne peuvent flush le résultat que dans un ordre spécifique. Cela signifie à son tour que si votre première balise ESI est lente, elle empêchera tout autre "pagelet" d'être flushé vers l'utilisateur.
C'est pourquoi je pense que vous auriez besoin d'un type spécial de serveur de cache qui peut récupérer de manière asynchrone des inclusions tout en ignorant complètement l'endroit où elles apparaissent dans le document.
L'autre gros inconvénient est que chaque balise ESI provoquerait sa propre requête HTTP vers Symfony, ce qui comporte une surcharge de configuration assez importante pour chaque requête.
En conclusion : les ESI sont géniaux si vous voulez retourner une page mise en cache coûteuse à générer avec un tout petit peu de contenu non-cacheable, mais ce n'est probablement pas adapté pour implémenter BigPipe.
