Plone page composition and ESI

[datakurre (Asko Soukka)]

@hvelarde

we have never used ESI even as all collective.cover tiles inherit from the ESI one on plone.tiles

So, am I really the only one using ESI with plone.app.blocks and plone.tiles?

[jensens (Jens W. Klein)]

maybe at the moment, yes, but I'm considering using this soon.

[thet (Johannes Raggam)]

@datakurre

and some are for performance: subrequest based Mosaic default composition gets slow very fast, but with ESI, multiple instances can render tiles in parallel, and with some collaboration with Varnish, we can cache tiles safely even for logged-in users

We had massive performance problems due to a memory leak in plone.subrequest before this fix: https://github.com/plone/plone.subrequest/pull/8
But since then, all is O.K.

I understand ESI based rendering as like as JS based fetching could be a performance booster due to asynchronicity as opposed to plone.app.blocks layout based rendering with lots of tiles which are rendered synchronous.
But I don't have big issues with the plone.app.blocks layout based model.

Although, a asynchronous rendering model is very tempting...

[djay (Dylan Jay)]

@datakurre

But there's real danger that we start relying on the special features of the method of our choice, making tiles behave differently or even being incompatible with different rendering methods.

Or should we be honest and explicitly support multiple different methods at the same time in a way that different tiles could be designed and optimized for different methods? But that would make it conceptually more complex. So, the current state is a good compromise?

I think you are right there is a danger and no it would be a bad idea to allow tiles to support incompatible apis.
So I think the question is: how do we prevent the two apis from diverging given the community can "forget" rarely used features?

[djay (Dylan Jay)]

I personally think lots of people are waiting for mosaic to be stable before they use it. We use it just on our own site for example. Only when lots use it, will some need to use optimisations like ESI or JS async loading to improve performance. So it is far too soon to say these aren't worth it IMO.

[gyst (Guido Stevens)]

Just to add another consideration to this already massive thread: in Ploneintranet we found it takes only minimal markup changes to move from a subrequest based tile rendering, to a asynchronous javascript load with pat-inject, which is compatible with Mockup.

So instead of ESI we have an equivalent composition with javascript autoloads, without requiring any backend changes and without requiring any javascript weirdness - just changing some css classes and data attributes.

Apart from parallelization of the tile rendering, this also achieves a "experiential" speedup since the core page is rendered faster by the browser, and then incrementally the page reflows as the separate tiles are being merged in.

[datakurre (Asko Soukka)]

@gyst

Just to add another consideration to this already massive thread: in Ploneintranet we found it takes only minimal markup changes to move from a subrequest based tile rendering, to a asynchronous javascript load with pat-inject, which is compatible with Mockup.

Thanks for reporting that! Nice and encouraging to hear it was that easy

ESI experience is very similar. Varnish starts streaming the page as soon as Plone as rendered the "core page" and only stops for waiting the missing tiles. Long non-cached pages will "stream" from top to bottom without flickering.

But, agreed, ESI does need more work on server, because ESI requires tiles to be unwrapped from html and body tags (and that's not an issue for pat-inject). Besides that it sounds very similar.

[datakurre (Asko Soukka)]

Thanks for comments. I'm planning a blog post about our ESI tiles setup later this week. Any things you'd like to be covered?

I'm planning to shortly revisit with minimal examples, how page composition with plone.app.blocks works. Then describe the current composition transforms: subrequest-based, Castle's multiadapter based, pat-inject (which is also similar to how Mosaic Editor), and finally ESI. Finally, I describe our Varnish ESI setup, and how we achieved cached tiles (and fast Mosaic pages) for logged-in users.