GoogleChrome / GoogleChrome/lighthouse

pseudo-elements not directly identifiable by backend node ID

Open
#14,351 2 comments 0 reactions 1 assignee Claimed by @connorjclark View on GitHub
needs-investigation P3
Dominant language
JavaScript
Stars
30.8k
Forks
9.8k
Avg merge
1d 14h
Merged PRs (30d)
20

Description

Node IDs are shared between an element and any of its pseudo-elements. Any time Lighthouse tries to identify an element by `DOMNodeId`/`backendNodeId` it targets the main element, even if the culprit was actually in a pseudo-element.

I believe `DOM.resolveNode` usage is limited to `TraceElements` and `AnchorElements` these days, but it means that element screenshots can be wrong (e.g. if it's `::before` content that had a layout shift, not the main element) and the wrong opportunities suggested (e.g. the LCP image is in an `::after`, not the main element).

Same example as in #14350: https://earthy-picayune-albertonykus.glitch.me/ (the actual LCP is the `::after` Lighthouse logo, but `largest-contentful-paint-element` identifies the whole `.wrapper` element as the LCP).

I'm not sure what a good solution would look like.

For TraceElements, the `DOMNodeId` is all you get, _but_ e.g. for LCP there are more specific `LargestImagePaint::Candidate` and `LargestTextPaint::Candidate` trace events that give frame and root coordinates that could possibly be helpful (or hopelessly out of date by the time `TraceElements` is running). `LargestImagePaint::Candidate` also gives the URL of the image being painted, which could be used in the specific image LCP case once #14350 has a solution.

I haven't really looked into this, but the debugger protocol also lets you manipulate pseudo-elements (e.g. in the Elements panel), so they must be targetable to some extent. Maybe there's more that could be done to dig in with that.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.