Hook for Consumer-specific Lazy Execution in Milo Pipeline

[JingleH]

I saw in this PR the proposal to fire an event before loadPostLCP(). It was removed at that time, but could we reopen the discussion and explore alternatives?

Context

Consumers may need product-specific logic that runs lazily but before the delayed/deferred phase. Similar to martech, gnav, fonts, etc., this logic doesn't fit well inside every individual blocks' JS. One good place for them in the pipeline would be loadPostLCP(). Although LCP element can be out of the first section and Milo's exact invocation timing may evolve, it is still an attempt for a standard signal for lazy, consumer-specific logic.

Express Examples

1. URL Parameters: We append query parameters to links for promos, tracking, and product deep linking. This is high-priority and should happen before clicks, not in the Delay phase. It's also more "page-level" than "block-level" so we shouldn't need each block to handle it separately.
2. Floating Area: We have a floating area dedicated to primary CTAs that stays visible regardless of users' scroll position. This area shouldn't block LCP but is still high-priority and shouldn't be delayed, as it often contains important information. Especially on mobile, we hide/suppress Marquee CTAs that have the same links/text as ones in the floating area to optimize screen space, and without it, users see no primaryCTA on the page.
   
   . We can't author the floating area as a page's second section because its content is centrally managed via a spreadsheet for bulk operations across thousands of pages.

Proposal

A "postLCP" event could work as a single line of code with minimal burden on Milo. As long as Milo guarantees that it eventually gets fired, consumers can build upon it at their own risks. Alternatively, we can do it through config like config.consumerPostLCPCallback().

Without Milo's support, we'd need a MutationObserver in scripts.js to watch the first section, but that would be much more fragile. We would really appreciate having a defined solution baked in the core.

[vhargrave]

Based on my comments in the PR it's clear that I also support this. Express (and I could imagine other consumers?) has code that they don't want executed immediately pre LCP, but that also should happen pretty soon after the LCP event.
I'm curious if other consumers have been in situations where they would have wanted a postLCP hook or event though?
@npeltier @honstar @auniverseaway @chrischrischris @salonijain3 @Ruchika4 @meganthecoder @JasonHowellSlavin @Blainegunn @seanchoi-dev
cc: @narcis-radu @mokimo @overmyheadandbody @robert-bogos

[chrischrischris]

I don't see an issue with firing a post-lcp event. It's on the devs to make sure that the way they are using the event does not adversely affect page performance. It's recommended to use the deferred event if possible, but the use-cases listed above seem valid.