PublishedVerifiedEvery 6 monthsSources7 namedAuthored bySquareRank Team
Cluster 2D · the honest speed read
Squarespace site speed in 2026
Squarespace 7.1's default Core Web Vitals are not great, and the LCP score is where most sites struggle most. The 2026 thresholds — LCP < 2.5s, INP < 200ms, CLS < 0.11 — are reachable on Squarespace, but the platform's defaults work against you. The honest fix is layered: cap hero image dimensions, audit third-party scripts, add explicit dimensions to embedded content. This hub names where the bottlenecks actually live.
Five leaves go deeper into the specific levers — LCP, CLS, mobile, lazy-loading, JavaScript deferral. Each leaf is one tactic. Together they take a typical Squarespace 7.1 homepage from 45-60 PSI into the 75-90 range.
Core Web Vitals is Google's three-metric performance framework, updated every couple of years as the web changes. As of Q1 2026 the three vitals are LCP (Largest Contentful Paint) measuring loading performance, INP (Interaction to Next Paint) measuring responsiveness, and CLS (Cumulative Layout Shift) measuring visual stability. INP replaced FID (First Input Delay) as a Core Web Vital on 12 March 2024 — older Squarespace guides citing FID need updating. Google uses field data from real Chrome users, not lab data, as the ranking signal.
The field-data point matters. PageSpeed Insights4 shows two panels: Field Data (from the Chrome UX Report5, based on real Chrome users hitting your site) and Lab Data (from Lighthouse3, a simulated test in a clean browser environment). The Field Data is what Google's ranking algorithm reads. A perfect Lighthouse lab score with poor field data does not help ranking; a mediocre Lighthouse score with strong field data does.
The 2026 thresholds — verified
< 2.5s
LCP threshold for 'good'. Anything over 4.0s is 'poor'. Measured at the 75th percentile of real Chrome users.
Out of the box, a typical Squarespace 7.1 homepage with a full-bleed hero image and three or four sections scores between 45 and 65 on mobile PSI. The three default bottlenecks are consistent across templates: (1) the hero image is the largest element and loads at full source resolution, blocking LCP; (2) Squarespace's first-party scripts plus any added analytics or chat widgets tax INP; (3) the system font swap during page load causes CLS as text reflows. None of these are configurable from a single toggle — fixing each requires a separate intervention.
The hero-image problem is the worst offender. Squarespace6 serves WebP-optimised variants automatically for images uploaded through the editor, and ships responsive image sizes via the srcset attribute, but the source resolution is what you upload. A 5,000px-wide photo uploaded to a 1,440px-wide hero section still ships ~3MB even after WebP compression. The LCP leaf below covers the dimension cap that fixes this.
§03Thresholds
The three thresholds in 2026
The three thresholds Google's documentation defines as 'good' are LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Each metric is measured at the 75th percentile of real Chrome users — meaning your site has to clear the bar for at least three out of every four sessions to count as good. The 'needs improvement' band sits between good and poor, and the 'poor' threshold is LCP over 4.0s, INP over 500ms, CLS over 0.25. Below 'good' on any one metric is what disqualifies a page from the Core Web Vitals pass.
Google's page-experience documentation2 confirms that Core Web Vitals is part of ranking, but is explicit that the signal is small. The bigger reason to optimise is the user-experience effect, which has a much larger conversion impact than the ranking adjustment. A site that loses 20% of visitors to slow load times loses 20% of conversions; the ranking effect on top is the bonus.
§04LCP
LCP — the hero-image problem
LCP measures how long it takes for the largest visible element above the fold to fully render. 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 dimensions at 1920px wide, ensure the image is preloaded (not lazy-loaded — preloading is the inverse), and let Squarespace's automatic WebP serving handle the format conversion. The LCP leaf below ships the complete tactic.
The dimension cap is the biggest single lever. Squarespace serves a responsive srcset with multiple sizes, but the source resolution determines the largest variant. Caping at 1920px means the largest variant is 1920px, not 5000px, which cuts payload by 4-7x for most hero images without visible quality loss at typical viewport sizes. The LCP leaf covers the exact sizing recommendations per template.
§05INP
INP — the third-party-script tax
INP measures the longest interaction during a session — clicking a button, opening a menu, scrolling a carousel. Squarespace's own first-party scripts are reasonably optimised; the INP problems come from third-party scripts added through Code Injection. Chat widgets (Intercom, Drift, Tidio), analytics layers beyond GA4 (Mixpanel, Heap, Hotjar), and embedded social widgets are the usual culprits. Each adds main-thread work that delays the response to user input.
The fix is auditing what is actually loading and deferring or removing non-critical scripts. The JavaScript leaf covers the audit workflow plus the defer and async attributes that change script load behaviour. The honest constraint: Squarespace's own scripts run synchronously and cannot be deferred — you only control third-party additions.
§06CLS
CLS — fonts and ads moving things around
CLS measures how much content jumps around as the page loads. The three Squarespace CLS culprits are: (1) custom fonts that swap from a fallback to the brand font and reflow text; (2) embedded iframes (YouTube, Instagram, third-party widgets) that load without explicit dimensions; (3) sticky banners or cookie notices that mount into the page after first paint. The CLS leaf below covers each fix, including the rare case where Code Injection HTML drops a div with no width or height set.
The font-swap CLS is the one most Squarespace owners have without realising. The fix is loading the font with font-display: optional or font-display: swap plus a size-adjust property on the fallback — both of which require Custom CSS access. The CLS leaf covers the CSS snippet.
§07Control
What you actually control on Squarespace
Squarespace 7.1 gives you control over image dimensions and quality, the inclusion and ordering of third-party scripts in Code Injection, the use of Custom CSS for font loading and CLS-prevention tweaks, and the noindex toggle for low-value pages that drag down the average performance score. You do not control: Squarespace's first-party script bundle, the platform's CDN configuration, server-side rendering vs hydration timing, the auto-injected DOM elements (cart, navigation, footer), or the Squarespace logo asset. The realistic ceiling is 75-90 PSI mobile on most pages once the levers you do control are pulled.
The five leaves below cover what is in your control, in order of impact: LCP (biggest single lever), CLS (most user-perceptible jank), mobile (where most traffic lives), lazy-load (clean-up), JavaScript (audit-and-prune). Pull all five and you reach the realistic ceiling.
The realistic Squarespace 7.1 ceiling
75-90
typical mobile PSI range after pulling the five levers in this cluster. Real sites, real traffic.
Five leaves go deeper than this hub. Each fixes one specific bottleneck. The LCP leaf is the highest-impact starting point. The CLS leaf catches the most user-visible jank. The mobile leaf names the desktop-vs-mobile gap and what closes it. The lazy-load leaf clarifies what Squarespace already does automatically and where the patch is needed. The JavaScript leaf audits the third-party scripts that quietly tax INP.
Five questions Squarespace owners ask most about site speed and Core Web Vitals — answered in the format AI engines lift from.
Why is my Squarespace site slow?
Two common reasons. (1) Hero images load uncompressed and unoptimised, blocking LCP — Squarespace serves WebP automatically but still ships the full-resolution source unless you cap dimensions. (2) Third-party scripts (chat widgets, analytics, embedded video) tax INP. Both are fixable from inside Squarespace without leaving the platform.
What are good Core Web Vitals scores in 2026?
LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 — verified against web.dev's canonical thresholds in Q1 2026. INP replaced FID as a Core Web Vital in March 2024, so older Squarespace guides citing FID are out of date.
Does Core Web Vitals affect Google ranking?
Yes, but the signal is small. Google's page-experience documentation confirms CWV is part of ranking, but it is one signal among hundreds. The bigger reason to optimise is conversion — slow pages lose visitors before content can convert. The ranking effect is a bonus.
What is INP and how is it different from FID?
INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only measured the first interaction; INP measures the longest interaction during the whole session, which catches slowdowns that happen after the page is interactive — clicking a button, opening a menu, scrolling a carousel.
Does Squarespace let me defer JavaScript or lazy-load images?
Image lazy-loading: yes, automatic for most images. JavaScript deferral: limited. Squarespace's core scripts run synchronously; third-party scripts injected via Code Injection can be loaded with async or defer attributes, but you cannot defer Squarespace's own scripts. The javascript leaf covers what you actually control.
