What Largest Contentful Paint means for your website

Largest Contentful Paint, LCP, is the time from when a visitor opens your page until the biggest image or block of text on the first screen is drawn, and Google's threshold for good is 2.5 seconds or less (Source: web.dev). It is one number, it describes one moment, and on most contractor sites that moment is the hero photo.

The definition, in Google's words

Google's page on the metric says LCP "reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page" (Source: web.dev). The viewport is the first screen, before any scrolling. Only a few kinds of element are eligible: <img> elements, <image> elements inside an <svg>, <video> elements, an element with a background image loaded with url(), and "block-level elements containing text nodes" (Source: web.dev). The browser watches as the page draws, keeps track of the largest eligible thing it has painted so far, and reports the render time of the winner.

The threshold, in the page's words: "A good LCP value is 2.5 seconds or less" (Source: web.dev). For field data Google recommends looking at the 75th percentile of page loads (Source: web.dev), meaning three out of four visits must clear the line.

Google also explains how this differs from the older "first paint" idea: "FCP measures when any content is painted to screen and LCP when the main content is painted so LCP is intented to be more selective" (Source: web.dev, spelling theirs). A spinner or a header bar can count as first paint. LCP waits for the thing people came to see.

The four stretches of time

Google breaks the number into four parts, and every fix lands in one of them (Source: web.dev, Optimize LCP):

1. Time to First Byte. "The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response." This is the server. A slow host or a heavy platform shows up here before anything else can happen.
2. Resource load delay. "The time between TTFB and when the browser starts loading the LCP resource." The browser has the HTML but has not started fetching the hero image yet, usually because the image is referenced in a stylesheet or a script instead of the HTML.
3. Resource load duration. "The duration of time it takes to load the LCP resource itself." This is where a 4 MB photo pays its bill. Weight is a measurement of this stretch, not a cause of the others.
4. Element render delay. "The time between when the LCP resource finishes loading and the LCP element rendering fully." The image is downloaded, but a script or a web font is holding the page back from painting it.

The rule that cuts the second stretch to near zero is one sentence on Google's page: "it's critical that the resource is discoverable in the initial HTML document response by the browser's preload scanner" (Source: web.dev, Optimize LCP). In practice: the hero image is a plain <img> tag in the HTML, with width and height set and, when it is the main image, fetchpriority="high", which Google describes as a way to "hint to the browser as to which resources are most important" (Source: web.dev, Optimize LCP).

Lab test, not your phone

The number you see in PageSpeed Insights comes from Google's lab test. Google's own description: "Lighthouse simulates the page load conditions of a mid-tier device (Moto G4) device on a mobile network for mobile, and an emulated-desktop with a wired connection for desktop" (Source: Google, About PageSpeed Insights). The same page draws the line between the two kinds of data: "Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience" (Source: Google, About PageSpeed Insights).

So when we say a site's LCP is 7 seconds, we mean Google's lab test on a simulated slow phone and connection measured 7 seconds. Your own phone on your own Wi-Fi is not the test, and most small sites have no field data at all because too few people visit for Google to publish it.

What we measured locally

In September 2026 we ran Google's lab test on 102 Capital Region home-service sites. The median LCP was 7.75 seconds; 98 of the 102 were over Google's 2.5-second line, and 37 were over 10 seconds. The lab test runs on a simulated throttled phone, not real visitor data, and the sample is Capital Region home-service businesses from chamber directories and license rolls, not a random sample. Measured September 2026.

We do not have a number for what visitors do during those seconds. Nobody measured that on these sites, and we will not guess.

How to check your own site

1. Open pagespeed.web.dev on any device and enter your home page address.
2. Leave the Mobile tab selected. Scroll past the score to the metrics. Largest Contentful Paint is listed with its time.
3. Under Diagnostics, open "Largest Contentful Paint element." It names the exact image or heading that was timed. On a contractor site it is usually the hero photo.
4. Note the four sub-part times if the report shows them. The biggest stretch is where the fix goes.

What to do about it

If the timed element is a photo, the fix is mechanical: export it at the size it is displayed, compress it to a modern format, put it in the HTML as a plain image tag with its dimensions, and mark it high priority. If the first stretch is the long one, the host or the platform is the problem and no image work will move it. If the fourth stretch is the long one, a script or a font is in the way.

Our Website Fix is $700, and "images compressed and lazy loaded" is the first of its five items. We measure before and after with the same lab test and send both reports. Details at /services#fix.