placeholders' replaceText triggers 2 image loads

[npeltier]

@vladen found out that placeholder decoration [0] was triggering a reload the marquee block image of a new milo page [1] reloading background image, resulting in LCP being the heading after while marquee was the actual good candidate.

For now no great idea how to fix this, but maybe this beautiful community will :)

[0]

async function decoratePlaceholders(area, config) {
  const el = area.querySelector('main') || area;
  const regex = /{{(.*?)}}|%7B%7B(.*?)%7D%7D/g;
  const found = regex.test(el.innerHTML);
  if (!found) return;
  const { replaceText } = await import('../features/placeholders.js');
> el.innerHTML = await replaceText(el.innerHTML, config, regex);
}

https://github.com/adobecom/milo/blob/main/libs/utils/utils.js#L701

[1] https://pagespeed.web.dev/analysis/https-main--cc--adobecom-hlx-live-products-premiere-free-trial-download/oq3jfjeeqz?form_factor=mobile
[2] related analysis ticket https://jira.corp.adobe.com/browse/MWPW-142708

[npeltier]

1. i wonder if in that specific case if in the end using CSS gradient wouldn't be better (i know it's going backward with what we did last time)
2. wonder if we stay with same implementation, if we shouldn't before assigning innerText, test if something has changed, and assign only if answer is yes it's actually already implemented that way

[vladen]

Having conducted a deeper investigation I cannot prove that the mentioned code causes re-redering of the background image and has any impact on LCP.
So far it only causes second load attempt if browser caches are disabled what is irrelevant to LCP.

[vladen]

At the same time, we observe very long delay before rendering the LCP element on the page being studied:
https://pagespeed.web.dev/analysis/https-main--cc--adobecom-hlx-live-products-premiere-free-trial-download/oq3jfjeeqz?form_factor=mobile

The original question, articulated by @npeltier was: "Why H2 from the second visible section is detected as the LCP element by Chromium, instead of elements from the first visible section".

Per this web.dev article, the types of elements considered for Largest Contentful Paint are:

1. <img> elements
2. <image> elements inside an <svg> element
3. <video> elements
4. An element with a background image loaded using the url() function, (as opposed to a CSS gradient)
5. Block-level elements containing text nodes or other inline-level text element children.

Also, LCP measurements use heuristics to exclude certain elements that users are likely to see as "non-contentful":
A. Elements with an opacity of 0, making them invisible to the user.
B. Elements that cover the full viewport, that are likely to be background elements.
C. Placeholder images or other images with a low entropy, that likely don't reflect the true content of the page.

If this heuristics filters the background image out (rule C), then H2 from the section two becomes the largest block element having text content (rule 5):

[vladen]

@npeltier
My conclusion: In accordance with the Milo performance architecture, an LCP element should belong to the first section of the document.