Skip to content
50% OFF $299 $599
Lock in
§ 6.0.10 ARTICLE
Published Threshold≤ 2.5s good Sources2 named Authored bySquareRank Team

Glossary · § 6.0.10 · Defined term

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) is the time from a page's navigation start to the render of the largest visible image or text block1. It's a Core Web Vital. Google considers a page to have "good" LCP when the 75th-percentile real-user measurement is 2.5 seconds or faster. "Needs improvement" runs to 4 seconds. Beyond 4 seconds is "poor".

LCP usually fires on a hero image, a hero text block, or the largest article image above the fold. On a typical Squarespace 7.1 site, the LCP element is the hero section's background image. That single image is responsible for whether the LCP score passes or fails for most pages on the site.

Definition

Largest Contentful Paint (LCP) is the time from a page's navigation start to the render of the largest visible image or text block. It's a Core Web Vital — Google considers a page to have 'good' LCP when the 75th-percentile real-user measurement is 2.5 seconds or faster.

The "Contentful" qualifier matters. LCP does not count layout chrome (background colours, decorative SVGs that aren't visible content). It counts content elements: <img>, video poster frames, background images via CSS background-image, and block-level text. The largest element by rendered area on the viewport, of those qualifying types, is the LCP element.

What counts as 'largest'

LCP measures the largest qualifying element visible in the initial viewport. On most Squarespace pages this is the hero background image; on text-heavy pages without a hero it's the main article H1 or first paragraph. The largest element can change during page load — LCP updates as larger elements paint — and the final value is whatever is largest when user interaction ends measurement.

One quirk: an image must be loaded and rendered to count. If a hero image lazy-loads after first paint, the LCP candidate while that load is pending is whatever else is visible (the H1, the menu). When the hero arrives, it usually becomes the new LCP element. This is why eager-loading the hero image (or preloading it via <link rel="preload">) typically improves LCP — you swap the lazy-loaded LCP candidate for an eager one.

What slows LCP down

The web.dev guide breaks LCP into four sub-parts: TTFB (server response time), resource load delay (time before the LCP resource starts loading), resource load duration (time to fully load the LCP resource), and element render delay (time after load before the element actually paints). Diagnosing LCP problems means figuring out which sub-part dominates.

On Squarespace specifically: TTFB is usually fine (Squarespace's CDN is fast); resource load delay is the most common offender (hero images discovered late by the browser); resource load duration is the second offender (large hero images); element render delay is rarely the bottleneck. The Squarespace LCP install pattern targets the first two2.

LCP on Squarespace specifically

Three install patterns. (1) Compress hero images to ≤ 200 KB before upload — Squarespace's auto-optimisation does not reach this aggressively. (2) Use Squarespace's responsive image system (the platform serves multiple sizes; this works by default). (3) For the home page hero specifically, consider Code-Injecting a preload link in the page header so the browser discovers the image earlier.

A practical sequence: install PageSpeed Insights for the URL, check the LCP element and the four sub-parts, focus optimisation on whichever sub-part dominates. For ~80% of Squarespace sites the answer will be: resize and compress the hero image. For the remaining ~20%, the answer is third-party script removal (chat widgets, popup tools that block the main thread during hero load). The full install treatment lives at Squarespace LCP fix.

LCP is one Core Web Vital. Adjacent terms below.

Keep reading · § 6.0.10