Allow extensions to opt-in to using the web-vitals attribution build via the od_use_web_vitals_attribution_build filter

[swissspidy]

Summary

Fixes #1736

Idea: add a "dot" on relevant elements (e.g. LCP elements). Click on the dot to learn more about the element.

Relevant technical choices

• Allows loading web-vitals attribution build

[swissspidy]

With fresh eyes I was able to fix the anchor positioning and styling a bit. This looks much better now:

Screen.Recording.2025-01-10.at.15.42.34.mov

Of course it needs a lot of tidying up still, but it seems to more or less work.

Now we just need to figure out where to put all of this code. don't necessarily like putting it into its own GitHub repo where it's not easily discoverable.

---

Aside:

There is one test failure now:

1) Test_OD_URL_Metric::test_get_json_schema
root/inpData
Failed asserting that false is true.

🤔

[westonruter]

That means this debug helper can't actually place this "dot" because figure.wp-block-image.aligncenter.size-medium.wp-lightbox-container>img.wp-image-44.hide doesn't exist at the time the document is loaded.

Humm. Yeah. There's a similar issue for what to do if content is added to the page by JS and the slow interaction occurs for an element in that added content. Basically, we can't rely on the interactionTarget to be present at the time the page loads. Then the question is when do we query for them? We could add a MutationObserver which watches for changes to the page, and with some heavy debouncing, re-query the page for the selectors. Then we could find the elements later on during the life of the page.

This, however, won't address the related problem of the hide class being added to the lightbox. Well, at the moment the hide class is added, the element is seen anymore so there is no point to try to show a dot on it! Really what we'd want to is to capture the selector for the element before the user interacted with it, so that we know what potentially will cause a slow interaction?

[swissspidy]

Sounds good. I started extracting the relevant code to https://github.com/swissspidy/od-debug-helper and made this PR all about adding the web-vitals.js attribution build.

What's missing is passing the INP data to OD extensions.

--

Really what we'd want to is to capture the selector for the element before the user interacted with it, so that we know what potentially will cause a slow interaction?

Yes I think so.

[westonruter]

Something else to consider is to not rely on the selector as provided by the attribution build but rather to construct an XPath to the element using the same scheme the plugin uses server-side. This would eliminate reliance on the class names to select the element. It would likely, however, break in other ways, such as when JS adds or removes nodes preceding the node in the tree.

[swissspidy]

Something else to consider is to not rely on the selector as provided by the attribution build but rather to construct an XPath to the element using the same scheme the plugin uses server-side. This would eliminate reliance on the class names to select the element. It would likely, however, break in other ways, such as when JS adds or removes nodes preceding the node in the tree.

Yes, I thought about that too but found it too cumbersome at first. But I now just got Gemini to write a DOM element -> XPath selector for me so now I guess I'll use that one for now :) Then I don't need any JS to query by selector for now.

While it won't address the case of dynamically added elements, I think that's good enough for now for this debug helper.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: swissspidy <swissspidy@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: felixarntz <flixos90@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

Could this go back to being defined inline? The type is picked up for me in PhpStorm:

Suggested change

	/**
	*
	* @param {LCPMetric|LCPMetricWithAttribution} metric
	*/
	( metric ) => {
	( /** @type {LCPMetric|LCPMetricWithAttribution} */ metric ) => {

[swissspidy]

But your PhpStorm clearly only sees LCPMetric, not LCPMetricWithAttribution

[westonruter]

Good point!

What's strange to me is why this typing is even needed.

With 3614c13 I added more typing for the attribution report functions. Then PHPStorm reports that the arg is detected as a LCPMetricWithAttribution:

But TypeScript is giving a warning about it being implicit any:

Nevertheless, onLCP is defined as being either OnLCPFunction or OnLCPWithAttributionFunction:

So I would have thought that this would be later be reflected in the type of the arg here. But instead it is showing up as any, even though the common ReportOpts arg is carried through: