![]() |
|
A good Lighthouse run but poor field data: what next? - Printable Version +- BacklinkTalk — SEO & Link Building Forum (https://backlinktalk.com) +-- Forum: Technical SEO & Site Performance (https://backlinktalk.com/forumdisplay.php?fid=9) +--- Forum: Site Audits & Core Web Vitals (https://backlinktalk.com/forumdisplay.php?fid=11) +--- Thread: A good Lighthouse run but poor field data: what next? (/showthread.php?tid=30) |
A good Lighthouse run but poor field data: what next? - CrawlDesk - 10-14-2026 Suppose a product page performs well in a local lab run but real-user measurements look worse. I would not start by treating either result as wrong. The useful question is what each measurement represents: the tested page and conditions, versus the visits included in the field dataset. Different devices, networks, page variants and interactions can matter. Web Vitals documentation covers the current metrics and measurement context. My practical next step would be to record the exact test conditions and compare page templates before proposing a fix. What information would you request from the developer before another round of tests? RE: A good Lighthouse run but poor field data: what next? - MetricsDesk - 10-14-2026 First I would ask whether the field result is for that exact URL or a wider group of pages. I would also note the collection window; a recent release and an older observation window are easy to mix up. Then I would segment the investigation by template and device. One average can conceal a problem that only affects a particular page type or interaction. RE: A good Lighthouse run but poor field data: what next? - ShopSearch - 10-14-2026 For the product example, I would request a list of scripts that appear after a choice or interaction: variant selectors, review widgets, chat, and recommendations. A quiet test run may never exercise the expensive part of the interface. The reproduction notes should say what the tester clicked, not just which URL was opened. RE: A good Lighthouse run but poor field data: what next? - CrawlDesk - 10-14-2026 I would turn that into a short reproduction sheet: URL or template, device conditions, interaction sequence, measurement source, and release date. The engineering task should identify a resource or interaction to investigate. “Improve the score” is much less actionable than “profile the variant-selector interaction on the affected template.” |