Turn a Core Web Vitals report into a ranked, specific fix list

You are a web performance engineer translating a Core Web Vitals report into fixes a developer can actually implement, ranked by impact — not a generic performance checklist copy-pasted regardless of what's actually failing.

PAGE TYPE AND STACK: a product listing page on a Shopify store using a third-party theme, roughly 40 products with images per page
CORE WEB VITALS REPORT (LCP, INP, CLS — field data if available, lab data otherwise, note which): PageSpeed Insights field data (CrUX, 28-day): LCP 4.2s (poor), INP 340ms (needs improvement), CLS 0.28 (poor)
KNOWN CONSTRAINTS: can't modify the theme's core template files directly (would break future theme updates), but can add custom CSS/JS via the theme's app-block system

TASK

1. TRIAGE EACH METRIC AGAINST ITS THRESHOLD. State whether LCP, INP, and CLS each fall in the "good," "needs improvement," or "poor" range per Google's published thresholds, and name which metric is furthest from good — that's the one to fix first regardless of which feels most familiar to work on.
2. NAME THE LIKELY ROOT CAUSE per failing metric, specific to a product listing page on a Shopify store using a third-party theme, roughly 40 products with images per page, not a generic list of possible causes:
   - LCP: is the largest element likely an unoptimized hero image, a render-blocking font or stylesheet, a slow server response (TTFB), or client-side rendering delaying when the element even exists in the DOM?
   - INP: is the likely cause a long JavaScript task blocking the main thread on interaction, an oversized event handler doing synchronous work that could be deferred, or third-party scripts (analytics, chat widgets, ad tags) consuming the main thread at the moment of interaction?
   - CLS: is the likely cause images or ads without reserved dimensions, a web font swap causing text reflow, or content injected above existing content after initial load (a banner, a cookie notice) without space reserved for it?
3. RANK FIXES by estimated score recovery versus implementation effort, given can't modify the theme's core template files directly (would break future theme updates), but can add custom CSS/JS via the theme's app-block system. A fix that's high-impact but blocked by a stated constraint (no access to the CDN config, a CMS that doesn't allow custom script loading control) should be flagged as blocked, with the best available workaround, rather than recommended as if unconstrained.
4. DISTINGUISH FIELD FROM LAB DATA if both exist: field data (real user CrUX data) reflects actual user experience and is what affects the Google ranking signal directly; lab data (Lighthouse, PageSpeed Insights single-run) is useful for debugging but can miss real-world variance like slow user networks or older devices. If only lab data is available, say so and note the fixes are a best estimate pending real field data.
5. NAME WHAT WON'T MOVE THE NEEDLE. Explicitly call out any commonly recommended performance fix (minifying an already-small file, further image compression on an already-optimized asset) that would cost dev time here without meaningfully affecting the specific metric that's actually failing.

OUTPUT
A table: Metric | Current status | Likely root cause | Recommended fix | Estimated impact (high/med/low) | Effort (high/med/low). Follow with which fix to do first and why, and the field-vs-lab-data caveat if relevant.