Nested Blocks

[rahulgupta999]

A few times, content authors have requested to author a block once but use it multiple times inside other blocks. The recent case has been the request for a countdown timer for black Friday. Now this timer block should be authored once but surfaced inside multiple pages (or blocks).

The current mechanism is to create the child block as a fragment and then use it inside the parent block. The drawback is that decoration for the child block needs to be invoked (loadblock) by the parent block. This can impact the LCP if done in a blocking way. if not then we run the risk of CLS. This thread is to collect the ideas (implemented | under-discussion | fresh)
Capturing reference to some related discussions:

a) https://github.com/orgs/adobecom/discussions/2719
b) https://github.com/orgs/adobecom/discussions/2390

[mokimo]

We will soon start discouraging fragments within the LCP elements (marquee, hero-marquee, videos, anything within the first element of the page really) via the preflight which will receive a new performance tab.

There is an authoring trade-off here regarding effort VS performance and so far, we titled towards performance. If you or GWP has concerns in regard to this, please ping Ted Pierson or @jedjedjedM to discuss options

[mokimo]

To iterate on why fragments//blocks within blocks//request chains are bad:

Let's assume you visit the page, generally u'd want to:

• Load the milo utils
• load marquee+dependencies & wait for the slowest request to finish
• show LCP.
  This is a very optimized journey where we batch load everything for the LCP. I currently work on a POC to get the milo rendering pipeline to this:
  

---

Let's look at the current reality:

• Load consumer scripts and utils
• Load milo utils
• Load the fragment code
• Discover helpers within the fragments
• Load the first LCP element, which contains a fragment
• Load placeholders code as they are discovered within the fragment
• Load the placeholders json as the placeholder code discovers them
• Load the marquee and assets
• ((If the marquee would have dependencies, we'd discover them now and load them))
• Load decorate.js

With fragments, we can't know what to load, until we see the content of the fragment and we create a hard dependency to wait for an answer, before we can continue loading

[mokimo]

The same issue would arrise with blocks within blocks. We can't discover them, until we load a block and notice we need to load another block. It becomes a chain of requests and especially for the LCP can become a very time consuming matter

[mokimo]

In this discussion, I highlight estimates for requests https://github.com/orgs/adobecom/discussions/2816 that I observed for different chrome settings. We currently hover a lot around the ~2.5s mark with many of our pages, every additional request shifts us towards orange/red LCP area, and we should treat it as moving into the wrong direction.

How "expensive" is a request?
No Throttle: 50ms x 2 => 100 MS saved 4% of the LCP Budget (2500MS)
Fast 4G: 180ms x2 => 360MS => 14.4% of the LCP Budget
Slow 4G: 600ms => 1200MS => 48% of the LCP Budget

[mokimo]

We will get some specific numbers for fragments with #2805 with CRUM data

[yesil]

To contribute to the thread with some numbers, I observed minor improvements with eager loading of nested blocks.

PR: https://github.com/adobecom/milo/compare/stage...yesil:after-nested?expand=1#diff-28218f239d8d9c4d41e1924854440b50964619e56058fdd0ae243ff5ff6c616d

(PR on top of @rahulgupta999's countdown-timer PR, my changes are only in utils.js)

Catalog (nested mnemonic-list)

Before (LCP: 2.2)
https://pagespeed.web.dev/analysis/https-main--cc--adobecom-hlx-live-products-catalog/r9jyscjhya?form_factor=mobile

After (LCP: 1.9)
https://pagespeed.web.dev/analysis/https-main--cc--adobecom-hlx-live-products-catalog/uexk10cq6a?form_factor=mobile

Test page (nested countdown-timer)

Before (LCP: 1.3)
https://pagespeed.web.dev/analysis/https-before-nested--milo--yesil-hlx-live-drafts-rahulgup-marquee-parent/g3xfu7jqav?form_factor=mobile

After (LCP: 1.2)
https://pagespeed.web.dev/analysis/https-after-nested--milo--yesil-hlx-live-drafts-rahulgup-marquee-parent/rvcmj7geno?form_factor=mobile

[yesil]

Here is the relevant code from the above PR:

[yesil]

looking at the code again, I think the selector could be more specific.

[yesil]

@mokimo I would like to know if loading nested blocks together with section blocks has been already considered and/or is ruled out?
I think this could be a quick win and allow us to remove some logic in marquee w.r.t mnemonic and countdown timer loading.

[mokimo]

IMO nested blocks is pretty much ruled out as EDS discourages it. https://www.aem.live/docs/davidsmodel#rule-2-no-nested-blocks-for-authors

We have autoblocks for a more reusable existing pattern

[yesil]

In the above link, EDS discourages authoring nested blocks but not using them, actually it recommends using fragments.

[vhargrave]

For me this sounds like it should be either a variant of marquee or a feature.
Are we really sure this countdown is going to be used in several blocks? If yes then I'd add it as a feature. You'd add some page metadata with details of the start & end dates and then a little more info where this this countdown should get added.
If it's only going to be used in the marquee, then I'd add it directly there.

[rahulgupta999]

The ask is to use it in
Marquee
Hero-Marquee
Promo Modal

[sharmrj]

This was a request made when doing the poc migration for helpx-internal. I was able to get nested blocks to work on the milo-consumer end without fragments but, as it's already been pointed out, we cannot do nested blocks in milo without a significant performance impact. That said, here's how it works (we emulate how franklin turns table rows into divs)

https://github.com/adobecom/helpx-internal/blob/main/templates/helpxmain-article/helpxmain-article.js#L77-L133

[vhargrave]

That's not the only reason to not do nested blocks. The product team heavily discourages nested blocks due to the not so great authoring experience for authors.