Skip to content
50% OFF $299 $599
Lock in
§ 2.4.1 ARTICLE

Site speed · LCP

Squarespace LCP — the hero-image fix

LCP (Largest Contentful Paint) is Google's metric for how fast the largest visible element renders1. On a typical Squarespace 7.1 homepage, that element is the hero image — and the hero image is usually the slowest element on the page. The fix has three parts: cap the source resolution at ~1920px wide, preload the image with a <link rel="preload"> hint2, and let Squarespace's automatic WebP serving3 handle the format compression.

Pull all three and a typical 7.1 hero LCP moves from 4.0-6.5s into the 1.5-2.5s range on mobile. The actual number depends on the photo, the template, and the user's network — but the direction is consistent.

What LCP measures

LCP measures the time from when a user starts navigating to a page until the largest visible content element finishes rendering. The 'largest' element is whichever takes up the most viewport pixels — usually a hero image, sometimes a large headline block. Google considers under 2.5 seconds 'good' and over 4.0 seconds 'poor'. The measurement is taken at the 75th percentile of real Chrome users hitting the page, meaning your site has to clear 2.5s for at least three out of every four visits to count as good.

The 'largest contentful' part is critical. LCP is not about the fastest paint or the time to interactive — it is specifically about the largest visible element, which is almost always the part of the page a user notices first. Optimising LCP means optimising whatever is the largest above-the-fold thing on your page1.

The LCP thresholds

< 2.5s

good. Your goal. Measured at the 75th percentile of real Chrome users hitting the page.

web.dev · 2026-Q1
2.5-4.0s

needs improvement. Page experience is degraded but not actively blocking.

web.dev · 2026-Q1
> 4.0s

poor. Real conversion impact, search-experience signal triggers downgrade.

web.dev · 2026-Q1

The hero-image bottleneck

On 7.1 templates with a full-bleed hero, the hero image is the LCP element in roughly nine out of ten cases. Squarespace serves the hero as a responsive picture element with multiple sizes — small for mobile, larger for desktop — but the largest variant is sized off the original upload. A photo uploaded at 5,000px wide gets compressed to WebP but still ships as a ~3MB file at the desktop size. The fix is reducing the source dimensions before upload so the WebP variant is smaller.

01. Cap source dimensions before upload

Before uploading the hero, open it in any image editor — Photoshop, Affinity, Photopea (free, browser-based), even Preview on macOS — and resize to a max width of 1920 pixels. For full-bleed hero sections, 1920px wide handles every common desktop viewport without visible quality loss. For non-hero images smaller than the viewport, target roughly 2x the rendered width to handle retina displays.

Squarespace's auto-WebP3 will compress further on its own — typical reduction is 30-50% versus the original JPEG/PNG. Capping the source first compounds with that, often cutting payload by 4-7x total for hero images that started at 4,000px+ wide.

02. Preload the hero image

The browser does not know the hero image is the LCP candidate until it has parsed the HTML and CSS deep enough to find it. A preload hint in the page head tells the browser to start fetching the image immediately, in parallel with everything else. Add the link tag via Settings > Advanced > Code Injection (Header). The result is typically a 200-600ms LCP improvement on the page where the preload is added.

html Settings > Advanced > Code Injection — Header panel 
 <link rel="preload" as="image" href="https://images.squarespace-cdn.com/content/v1/.../hero.jpg?format=2500w" imagesrcset="https://images.squarespace-cdn.com/.../hero.jpg?format=750w 750w,
                   https://images.squarespace-cdn.com/.../hero.jpg?format=1500w 1500w,
                   https://images.squarespace-cdn.com/.../hero.jpg?format=2500w 2500w" imagesizes="100vw">

Get the URL from the rendered hero — right-click, copy image address, paste into a new tab to confirm it loads. The imagesrcset attribute mirrors what Squarespace's own picture element serves, so the browser picks the right variant for the viewport without downloading the wrong size.

03. Let Squarespace's WebP do its job

Squarespace automatically serves WebP variants of any image uploaded through the editor. The Squarespace help reference confirms WebP is the default served format where the browser supports it, with JPEG/PNG fallbacks for older browsers. AVIF is not currently supported across the platform as of Q2 2026 — verified against Squarespace's own help doc. You cannot force AVIF; you can rely on WebP.

Two things break the auto-WebP behaviour: (1) images uploaded via Custom CSS as background-image URLs are served as-is (no WebP conversion) — use Squarespace's Image Block or section background images, not CSS backgrounds, for the hero; (2) GIFs are not converted to WebP — Squarespace serves them as GIFs. For animated content, MP4 or WebM via the Video Block is consistently smaller than the GIF equivalent.

Fonts and render-blocking CSS

The second-largest LCP contributor on Squarespace 7.1 sites is custom fonts. The default loading behaviour blocks text rendering until the font file finishes downloading — meaning the LCP element (which might be a large headline rather than an image) cannot render until the font arrives. The fix is one line of Custom CSS: font-display: swap on the @font-face declaration, or font-display: optional if you would rather hold the fallback and skip the swap altogether.

CSS Custom CSS — font-display fix for LCP 
   @font-face {
font-family: 'Your Brand Font';
font-display: swap;
}

The trade-off: swap shows a flash of unstyled text while the font loads, which can cause a small CLS bump. optional skips the swap entirely — if the font has not arrived in 100ms, the user keeps the fallback for the session. Choose optional for the cleanest visual result; choose swap when brand-font visibility is critical.

Measure the result

After implementing all three hero fixes plus the font fix, re-run PageSpeed Insights immediately. Lab Data — the Lighthouse simulated test — updates instantly and is the fast-feedback signal. Field Data — the CrUX real-user data — updates over a rolling 28-day window, so the impact on the ranking signal takes about four weeks of real traffic to fully reflect.

What to expect: most 7.1 homepages with the four fixes applied move from 45-65 mobile PSI into 75-90 mobile PSI within 4-8 weeks. Desktop typically reaches 95-100. If your numbers do not move, the bottleneck is elsewhere — usually third-party scripts (Code Injection bloat) covered on the JavaScript leaf or layout shifts covered on the CLS leaf.

Keep reading · § 2.4