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

Site speed · CLS

Squarespace CLS — stop the layout jumping

CLS (Cumulative Layout Shift) measures how much visible content jumps around as a page loads1. On Squarespace 7.1, three causes account for most of the score: custom fonts that swap from a fallback and reflow text, embedded iframes (YouTube, social, third-party widgets) that load without explicit dimensions, and late-mounting banners (cookies, chat widgets, promotions) that push content down after first paint. Each has a one-snippet fix via Custom CSS or Code Injection.

Pull all three fixes and a typical 7.1 site moves from CLS 0.15-0.35 into the under-0.1 'good' band. The trade-off on the font fix is a brief flash of unstyled text or a slightly different visual; the other two have no user-visible cost.

What CLS measures

CLS is unitless — it does not measure time or pixels, it measures cumulative shift impact across the lifetime of a page session. Each individual layout shift contributes an impact fraction (how much of the viewport shifted) multiplied by a distance fraction (how far it shifted). Those products sum into the final CLS score. Google considers under 0.1 'good' and over 0.25 'poor'. Most Squarespace 7.1 sites start somewhere between 0.15 and 0.35 before optimisation.

The CLS thresholds

< 0.1

good. The 'no visible jank' threshold. Measured at the 75th percentile of real Chrome users.

web.dev · 2026-Q1
0.1-0.25

needs improvement. Page experience is degraded — users notice the shift.

web.dev · 2026-Q1
> 0.25

poor. Real conversion impact — users mis-click on shifting elements.

web.dev · 2026-Q1

The three Squarespace CLS causes

Nearly every Squarespace CLS complaint reduces to one of three causes. (1) The custom font finishes loading after first paint and text reflows to its real dimensions, pushing content below the text downward. (2) An iframe — YouTube embed, Instagram embed, third-party widget — has no width or height attribute, so its container expands when the iframe contents load. (3) A late-mounting element (cookie banner, chat bubble, promotion bar) inserts itself into the DOM after the page has already rendered, pushing everything else down.

The Lighthouse 'Avoid large layout shifts' diagnostic in PageSpeed Insights4 names the offending elements directly. Run the audit, expand the diagnostic, and you get the exact DOM selectors that contributed the most to the score. Use that list to prioritise which of the three fixes below to apply.

01. Font-swap shift

Custom fonts on Squarespace are served with default loading behaviour: text waits for the font file, then renders. If you have set Squarespace to render with a fallback first, the swap from fallback to brand font reflows text dimensions and pushes lower content down. The fix is font-display: optional (or swap) plus size-adjust on the fallback to match the brand font's metrics. All of it lives in Design > Custom CSS.

CSS Design > Custom CSS — font swap CLS fix 
  @font-face {
font-family: 'Your Brand Font';
font-display: optional;
}
 @font-face {
font-family: 'Fallback Adjusted';
src: local('Arial');
size-adjust: 102%;
ascent-override: 95%;
descent-override: 22%;
}

The size-adjust property2 makes the fallback render at the brand font's dimensions, so when the brand font does arrive, the swap is invisible — no reflow. The exact percentages depend on the brand font; web.dev's documentation links to a tool that generates the values for any font pair.

02. Iframes without dimensions

Squarespace's Embed Block accepts iframes from YouTube, Vimeo, Instagram, Twitter, and arbitrary third-party widgets. When the iframe loads without width and height attributes (or without a wrapping element with explicit dimensions), the browser allocates zero space until the iframe contents arrive, then expands. Lower content jumps. Fix it by adding aspect-ratio to the iframe's container, or width and height attributes directly on the iframe.

HTML Wrap the embed iframe — aspect-ratio reserves space 
 <!-- In the Embed Block or Code Block, wrap the iframe. --> <div style="aspect-ratio: 16/9; width: 100%;"> <iframe src="https://www.youtube.com/embed/VIDEO_ID" width="100%" height="100%" frameborder="0" allow="accelerometer; encrypted-media; gyroscope; picture-in-picture"> </iframe> </div>

03. Late-mounting banners

Cookie consent banners, promotion bars, and chat widgets typically load via third-party scripts and mount into the DOM after the page has first painted. Every late mount that adds content above or below existing content pushes everything else, contributing to CLS. The fix is reserving space in the page at first paint for whatever the script is going to inject. A min-height on the wrapper element, or a placeholder div with the expected dimensions, keeps the layout stable.

For Squarespace's own cookie banner: there is no toggle to make it CLS-free, but the banner mounts at the bottom of the page outside the main content flow on most templates. If your CLS audit specifically names the cookie banner, check whether you have custom code overriding the default positioning.

Measure the result

After applying any of the three fixes, re-run PageSpeed Insights. Lab Data updates instantly — Lighthouse's CLS score should drop within seconds of saving the Custom CSS or Code Injection change. Field Data (real Chrome user data via CrUX) updates over the 28-day rolling window. Most Squarespace sites that apply all three fixes land in the 'good' band (CLS < 0.1) on the next lab run and on field data within four to eight weeks.

If the score does not improve after the fixes, three things are worth checking. (1) Did you save the Custom CSS? Design → Custom CSS → Save. (2) Is there a Squarespace-injected element (form, signup widget) that you have not accounted for? PSI's diagnostic names it. (3) Are you testing the right page? CLS is per-page, not site-wide. The site-speed hub covers the broader audit if the three fixes here are not enough.

Keep reading · § 2.4