Largest Contentful Paint

An observer writes a new line whenever a larger apparent object enters a telescope's view. A small early object remains part of the history even when a larger one becomes the current record. The log is chronological; sorting it by object size would destroy the observation sequence. When the observing session closes, later objects no longer revise that record.

Observatory	Browser
Apparent area inside the view	Eligible visible content area
New record holder	Later larger LCP candidate
Session closes	First input stops collection
Instrument ready but shutter closed	Resource ready but element not rendered

In real terms, LCP is an observation of visible page content, not the biggest file fetched. The analogy breaks down because browser eligibility rules exclude some content, and the telescope has no HTML response, resource discovery or decoding. It also does not make “largest” a promise about what a person considers most important. A visually prominent background can be irrelevant while meaningful text is eligible. Always inspect the recorded element. [S1]

4.1 ExamHall: the overview candidate changes

EXH-1570 investigates the proctor overview; MR !1770 records candidate IDs and the blocked phase before changing image bytes. The fixture paints a small label, waits for its actual observer entry, then inserts a patterned image. Its response remains held until the request arrives. Once released, the image becomes the larger visible candidate. The observer reports the chronological sequence below. [S1]

A separate fresh navigation clicks the background after the first entry appears and before the later image is inserted. The image still loads and renders, but candidate collection is already closed. Stopping measurement does not stop the page from changing. Nor does it erase the earlier observation. This is why a late screenshot cannot reconstruct the loading metric reliably.

4.2 Catalog: four forced boundaries

The experiment holds the document response first. It then sends a small catalog page but creates no image yet. Next it inserts an image and holds its response. Finally it finishes and decodes the image while keeping the element hidden. Only after the last checkpoint does it show the image and wait for its LCP entry. These are explicit boundaries, not simulated stopwatch readings. [S2]

The saved checkpoints separately record document delivery, image request, image completion and candidate presentation. The corresponding investigation labels are TTFB, resource load delay, resource load duration and element render delay. Removing bytes from an already completed image does not release a visibility gate. Conversely, an undiscovered resource cannot benefit from a transfer optimization yet. Text LCP has no separate image download; use the breakdown appropriate to the actual element, rather than inventing an image stage for every page.

4.3 Catalog: discovery is not priority

A catalog hero is already discoverable in markup and carries high priority. A separate later image is either declared by a compatible head preload or created by a held script. The capture records each request before the script barrier opens; it grades request state and order, never a duration or a competing-request race. [S2, S3]

The saved request trace distinguishes the already-discoverable hero from the later image. A separate lazy-loading control uses a distant image and a later scroll boundary. This does not define Chromium's lazy-load distance as a web guarantee, nor promise that every lazy image waits for a scroll. It demonstrates the extra visibility-dependent discovery gate that makes lazy loading a poor default for intended LCP imagery. Render-blocking mechanics remain in perf-critical-rendering-path; this lesson examines which LCP phase contains the wait.