Origin Summary
The timing number / value shown is the average of all of the available real world data for that domain, across multiple pages.
This is a rolling 28 day average for the pages for which it has sufficient data.
The bars show aggregated data so you can see how many visitors fall into each category (red = poor, orange = ok, green = good).
As this is an average across all of the data in the Chrome User Experience (CrUX) data set you can see a low average but still have one page that performs poorly / a certain screen size that performs poorly (which is why they include the aggregate bars as the synthetic test is only at one desktop and one mobile resolution or you may only test the home page and other pages perform poorly).
SCORING: This has no bearing on your score and is for information only / to help you identify issues that the synthetic test may not pick up.
Field Data
If the page being tested had more traffic you might get a break-down by page of the real world data (this would show as "Field Data"). You do not have enough traffic yet for this which is why you only get the origin summary.
The same way that origin data is aggregated and averaged if the page has enough data in the CrUX data-set you will see an average time / value for that page only. This is in addition to the origin summary data.
SCORING: This has no bearing on your score and is for information only / to help you identify issues that the synthetic test may not pick up.
Lab Data
This is the data from the synthetic test you just ran. This is where your score comes from.
The origin summary and field data have no bearing at all on the score you see here, they are purely informational.
The score and subsequent action points are generated "on the fly" based on this test run.
SCORING: The score you see when you run an audit is calculated from the data gathered on that run. No Origin data or Field Data is used in this calculation.
Example
In the example you gave LCP in lab data (synthetic) is 6.6s and Origin data (real world) is 3.6s.
To understand how this can be the case let's say you have a page that is in the CrUX dataset that Google has three real-world LCP values for. 2s, 3.9s and 4.9s.
Google would then give you the aggregate bars for that page (2s = good, 3.9s = needs improvement and 4.9s = poor) of 33% green (good), 33% orange (needs improvement) and 33% red (poor) based on the LCP scoring.
These would be your origin summary bars.
The time that is displayed for your origin summary time would be 3.6s - the average of those three values in the CrUX dataset (((2 + 3.9 + 4.9) / 3) = 3.6.
As for your Lab Data at 6.6s the test has loaded the page with throttling applied to represent a 4G connection on a mid-tier mobile phone. It then uses the performance data it gathers to calculate the LCP time.
If you made improvements to the page and re-ran the report the LCP time could drop instantly, as it is based on each run, whereas your origin summary data would take 28 days to completely change to reflect the change.
So if my data is not in the CrUX dataset how can I identify poorly performing pages.
Let's assume you have a page that does well in the Lighthouse synthetic test but it performs poorly in the real world at certain screen sizes.
Let's also assume there isn't enough data for it to show Field Data for that page.
How can you find a page that is ruining your origin summary?
For that you need to gather Real User Metrics (RUM) data.
RUM data is data gathered in the real world as real users use your site and stored on your server for later analysis / problem identification.
There is an easy way to do this yourself, using the Web Vitals Library.
This allows you to gather CLS, FID, LCP, FCP and TTFB data, which is more than enough to identify pages that perform poorly.
You can pipe the data gathered to your own API, or to Google Analytics for analysis.
This is the best way to gather page-specific data when there isn't any / enough data in the CrUX dataset for you to analyse.
