search

xwp / site-performance-tracker

Allows you to detect and track site performance metrics
GNU General Public License v2.0
96 stars 15 forks source link

CLS - Send to debug the element that's prior to the largest shift #27

Closed mehigh closed 2 years ago

mehigh commented 3 years ago

Right now the debug receives the largestSource.node, but most of the times this comes from a paragraph in the article content it makes it harder to identify which of the elements above it is the most problematic https://github.com/xwp/site-performance-tracker/blob/master/js/src/web-vitals-analytics.js#L138 An idea is to look if the target node has an immediate previous sibbling, and if it exists, to deliver that instead to the debug data. This way we have the path to what might be quite the element causing the shift (or at the very least one step closer to it).

dmao commented 3 years ago

Nice idea, but could have target node + immediate previous sibling? Or a way to know that there is not immediate previous sibling?

Something like Screenshot 2021-05-26 at 10 11 54

mehigh commented 3 years ago

Or something like -> the same thing #content>p if there's no previous sibbling or #content>p(div#widgetx) when there is that previous sibbling. The paranthesis would contain the extra information while not changing the current data structure when we don't have the extra available?

dmao commented 3 years ago

I see. When you know what is the parenthesis content, it's fine. But maybe not intuitive when you discover the app. What about #content>p(Previous:div#widgetx)

mehigh commented 3 years ago

That sounds great, @dmao . If you have any capacity to move this forward, that would be awesome!

mehigh commented 2 years ago

Let's not pursue this anymore. We didn't get many needs for this in the past year to worth developing.