feat(insights): Update Web Vital Meter in the landing page with link to performance issues #93520
Conversation
github-actions
bot
added
the
Scope: Frontend
| export const WEB_VITAL_PERFORMANCE_ISSUES: Record< | ||
| WebVitals, | ||
| Array<keyof typeof ISSUE_TYPE_TO_ISSUE_TITLE> | ||
| > = { | ||
| lcp: [ | ||
| 'performance_render_blocking_asset_span', | ||
| 'performance_uncompressed_assets', | ||
| 'performance_http_overhead', | ||
| 'performance_consecutive_http', | ||
| 'performance_n_plus_one_api_calls', | ||
| 'performance_large_http_payload', | ||
| 'performance_p95_endpoint_regression', | ||
| ], | ||
| fcp: [ | ||
| 'performance_render_blocking_asset_span', | ||
| 'performance_uncompressed_assets', | ||
| 'performance_http_overhead', | ||
| 'performance_consecutive_http', | ||
| 'performance_n_plus_one_api_calls', | ||
| 'performance_large_http_payload', | ||
| 'performance_p95_endpoint_regression', | ||
| ], | ||
| inp: [ | ||
| 'performance_http_overhead', | ||
| 'performance_consecutive_http', | ||
| 'performance_n_plus_one_api_calls', | ||
| 'performance_large_http_payload', | ||
| 'performance_p95_endpoint_regression', | ||
| ], | ||
| cls: [], | ||
| ttfb: ['performance_http_overhead'], | ||
| } as const; |
There was a problem hiding this comment.
This makes sense, but I bet people won't remember to update this. I think a more flexible solution here would be to:
- Add a field to the
GroupTypeclass in Python that specifies whether a given group type affects page load performance or not - Add a filter to issue search that allows to search for issues that affect page load
I think that approach is better because when we add more issue detectors (apparently this is planned) and when users start creating their own issue detectors based on metrics we can make sure that those issues also show up in these dropdowns somehow
That's a lot more work, obviously, but worth considering, IMO!
There was a problem hiding this comment.
Hmm, interesting solution. I can look into this! Would you mind if I explored this separately and handle this in separate prs? Should be simple to pivot the frontend once I've dug into this a bit more
There was a problem hiding this comment.
Yeah, I didn't mean for that comment to be a blocker, just thinking ahead since the Issue Platform folks are working in this area right now
static/app/views/insights/browser/webVitals/queries/useWebVitalsIssuesQuery.tsx
Outdated
Show resolved
Hide resolved
static/app/views/insights/browser/webVitals/components/webVitalMetersWithIssues.spec.tsx
Outdated
Show resolved
Hide resolved
static/app/views/insights/browser/webVitals/components/webVitalMetersWithIssues.spec.tsx
Outdated
Show resolved
Hide resolved
static/app/views/insights/browser/webVitals/components/webVitalMetersWithIssues.tsx
Outdated
Show resolved
Hide resolved
static/app/views/insights/browser/webVitals/components/webVitalMetersWithIssues.tsx
Outdated
Show resolved
Hide resolved
| showTooltip = true, | ||
| }: VitalMeterProps) { | ||
| const organization = useOrganization(); | ||
| const [isIssuesButtonHovered, setIsIssuesButtonHovered] = useState(false); |
There was a problem hiding this comment.
Whoa, why manually keep track of hover state?
There was a problem hiding this comment.
This is a little gross but I couldn't find a more elegant way to handle this.
Basically, when hovering over the issue button, by default the InteractionStateLayer on the meter component will activate. This looks a little weird because the meter and the issue button within are highlighted simultaneously:
I added the manual tracking to work around this so I can exclusively highlight the issue button and not the entire meter.
Alternatively, maybe we just stop using InteractionStateLayer (I heard it might be going away) and use something else to handle highlighting.
Let me know if you have any other suggestions!
There was a problem hiding this comment.
Dang! What about doing an event.stopPropagation() on the hover on the button? If that works, it's still better. Also worth adding a code comment to explain why this is happening, since it's surprising!
Update to design with link to related perf issues.
