# Partial page loads and CrUX: what field data quietly drops

A PageSpeed Insights or Lighthouse run is built to finish. The synthetic client opens the URL, waits for paints, and returns a tidy story for that controlled pass. Chrome User Experience Report (CrUX) field percentiles answer a different question: they aggregate many real Chrome visits, including ones that never complete the “full page load” narrative agencies sell after a green lab screenshot.

In CrUX conversations, “partial page loads” usually means experiences that abandon early, start in the background, restore from back/forward cache, or sit on one SPA document while the user thinks they changed pages. Field data does not quietly swap in a slower Lighthouse. It keeps, and filters, populations the lab never saw. So when lab is green and Search Console stays amber on the same URL, the clocks are often both honest. The retainer failure is claiming they measure the same thing.

For the fuller include/exclude map and soft-navigation note, keep [Partial Page Loads in CrUX: What Field Data Includes (and Excludes)](https://apogeewatcher.com/blog/partial-page-loads-crux-field-data-includes-excludes?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops) open (Apogee Watcher). For the broader lab-versus-field split, use [When to Use Synthetic vs Real User Monitoring](https://apogeewatcher.com/blog/when-to-use-synthetic-vs-real-user-monitoring-performance?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops). What follows stays on the quieter failure: what drops out of the client sentence when those populations stay unnamed.

## What “quietly drops” means for CrUX field data

CrUX does not ship a public metric labelled “partial session.” The phrase is shorthand for real experiences that diverge from a completed, foreground, full-document navigation of the kind Lighthouse scripts. Chrome’s [CrUX methodology](https://developer.chrome.com/docs/crux/methodology) starts from eligible user experiences, then aggregates them. An experience is metrics collected during a page view, not a synthetic script that always waits for a quiet network.

What drops out of the client story is usually clarity, not a secret second database. Teams paste one lab colour into a deck and treat field colour as “the same test, lagged,” so incomplete visits, visibility filters, and navigation-type sampling look like contradictions instead of different populations. Naming the gap is cheaper than another weekend of theme tweaks aimed at a clock that was never wrong.

## Experiences lab never sees that still move p75

Field percentiles can move because of visits a lab profile will not reproduce:

1. **Abandoned or interrupted loads.** The user leaves, closes the tab, or loses connectivity before the lab-style quiet window. Early paints or interactions that did fire can still land in the distribution.
2. **Background and visibility.** Pages opened in a background tab, or hidden before Largest Contentful Paint (LCP) settles, follow different LCP rules than a focused synthetic run. Tools that feed CrUX do not treat an entirely background load as a normal foreground story.
3. **Non-**`navigate` **restorations.** Back/forward cache and prerender activations feel like real visits to users, but not every timer is collected the same way as a cold document load.
4. **SPA soft navigations.** Route changes that look like new pages may still be attributed to the initial document URL in classic CrUX Core Web Vitals until soft-navigation metrics are used in reporting tools.

Lab colour and field colour can both be right while the deck pretends they are the same experiment. The quiet drop is the unfinished or filtered experience that still sits inside p75 without a caption; once you name that mix, the amber field chart stops looking like a personal insult to last week’s deploy.

## Timers and samples that quietly leave the story

**Interaction cut-off for LCP candidates.** Once the user taps, scrolls, or presses a key, browsers stop treating later paints as new LCP candidates for analysis. Real sessions often interact early, so the field stop can arrive sooner than in a synthetic run that sits idle until the largest element paints. That alone can separate a calm lab LCP from a noisier field distribution on the same template.

**TTFB versus LCP sample sets.** Chrome’s [CrUX navigation types](https://developer.chrome.com/blog/crux-navigation-types) show how often visits are ordinary navigates, cached loads, reloads, back/forward, bfcache restores, or prerenders. Core Web Vitals such as LCP are measured for bfcache restores in ways that match user perception of a new visit, but Time to First Byte in CrUX is collected on full page loads, not on every restore path. Treating every field metric as if it sampled the same navigations is a reporting error that quietly drops TTFB from half the story.

**Eligibility is a different silence.** Origins or URLs with no CrUX rows yet are not “partial loads”; they are missing samples or discoverability. Partial-load nuance only applies once field rows exist, so mixing “no data” with “partial sessions” in the same bullet confuses the next ticket.

## Lab vs field Core Web Vitals when loads are incomplete

| Clock | What it usually represents | What quietly drops from the comparison |
| --- | --- | --- |
| Lighthouse / PSI lab | One (or few) controlled full navigations | Busy shoppers, background tabs, early abandons, bfcache restores |
| CrUX / Search Console field | Aggregate of eligible real experiences | A single “finished load” narrative; equal sampling across every timer |
| Agency slide with one colour | A verdict | The population mix and navigation types behind the percentile |

Green lab after a deploy does not oblige amber field to flip this week. Field lag, sample mix, and partial experiences can all hold the chart while the synthetic budget stays clean. Scheduled lab history still matters for dated before/after; it just cannot stand in for CrUX population data.

## What to stop saying in client reports

Prefer not to say the field score “disagrees with Lighthouse,” as if one tool failed. Lab measured a controlled full load; field aggregates real visits that may abandon, restore, or start hidden. Prefer not to promise that a theme or plugin change will move CrUX on the same calendar as the next lab screenshot. Keep a dated lab schedule on the journey URLs you sell, and label Search Console as a different clock with lag.

When the attributed wait or journey mismatch needs a deeper map, hand the client the Watcher include/exclude guide rather than inventing a third colour. When the question is whether to trust synthetic or field for a decision, use the synthetic-versus-RUM framing instead of arguing about which screenshot is “true.” Both links earn a place in the pack; neither replaces naming the clocks on the slide.

## FAQ

**Does CrUX drop incomplete visits entirely?**\
Not as a single on/off switch. Some incomplete or awkward experiences still contribute metrics that fired; others are filtered (for example LCP rules around background loads). The quiet problem for agencies is mixing those populations with a finished lab run without a label.

**Why can TTFB and LCP tell different field stories on the same origin?**\
Navigation types differ. LCP can be measured on restores that still feel like visits, while TTFB in CrUX focuses on full page loads. Compare like with like before blaming hosting; the mismatch is often sampling, not a broken origin.

**Is a green lab score useless when field is amber?**\
No. Lab remains useful for regression and dated before/after under comparable conditions. It is simply a weak proof that field percentiles must move on the same calendar as your next screenshot.

**Where should we dig next?**\
Start with [Partial Page Loads in CrUX](https://apogeewatcher.com/blog/partial-page-loads-crux-field-data-includes-excludes?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops) for the include/exclude detail, then [Synthetic vs Real User Monitoring](https://apogeewatcher.com/blog/when-to-use-synthetic-vs-real-user-monitoring-performance?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops) for which clock owns the decision.

## Label the clocks before you sell the fix

If you are the technical lead writing the next Core Web Vitals pack, freeze the “Lighthouse says fixed” sentence until the deck names lab versus field. Incomplete loads and navigation types will keep moving p75 whether or not the theme deploy was clean. Leaving that unsaid burns trust faster than an amber chart; the tidy lab story from the opening still only covers the visits that finished under your script.

[Check a URL](https://apogeewatcher.com/check?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops) while you assemble the before pack, or [start a Watcher trial](https://apogeewatcher.com/sign-up?utm_source=hashnode&utm_medium=referral&utm_campaign=crux-partial-quietly-drops) when you need dated lab history beside the field panel. Keep the Watcher CrUX partial-load guide beside the slide so the quiet drops stay named. The next amber chart is easier to defend when the population mix was already in the footnotes.

## References

- [CrUX methodology](https://developer.chrome.com/docs/crux/methodology) (Chrome Developers)
- [CrUX navigation types](https://developer.chrome.com/blog/crux-navigation-types) (Chrome Developers)
- [Partial Page Loads in CrUX: What Field Data Includes (and Excludes)](https://apogeewatcher.com/blog/partial-page-loads-crux-field-data-includes-excludes) (Apogee Watcher)
- [When to Use Synthetic vs Real User Monitoring](https://apogeewatcher.com/blog/when-to-use-synthetic-vs-real-user-monitoring-performance) (Apogee Watcher)