Field Core Web Vitals and lab PageSpeed answer different questions. Field data tells you what eligible real-user visits experienced over time; lab data gives you a controlled trace you can reproduce today. Use field data to decide whether a user problem is material and lab data to investigate a specific mechanism.
Start by naming the decision
If you are deciding whether users are affected, field data has priority. If you are deciding which request, long task or asset causes a problem, you need a reproducible lab trace.
Check whether field data covers the URL
CrUX may report origin-level or grouped data when a URL lacks enough eligible samples. Do not attribute an origin-wide issue to one template without confirming scope.
Treat lab scores as experiments
Keep device profile, network, location, cache state and test URL stable. One green or red run is not a trend; it is one observation under controlled conditions.
Use metric-specific evidence
LCP, CLS and INP each need different traces. A composite performance score can move because an unrelated audit changed, while the user metric you care about stays flat.
Explain disagreements instead of averaging them
Fast lab but poor field can mean device/network diversity, third-party variability or interactions lab did not reproduce. Poor lab but good field can mean the test profile is harsher than your real audience.
Close the loop with field monitoring
Use lab to validate the technical change immediately, then wait for sufficient real-user data before claiming the population-level issue is resolved.
Use the guide to changing PageSpeed results for repeatability and the “passed but still feels slow” guide when field experience disagrees with a green score.