Web Performance: A Designer's Guide to the Metrics That Matter

Most Squarespace designers know that site speed matters. Fewer can explain exactly what “speed" means in a way that's technically accurate, or identify which of the dozen performance metrics actually affect search rankings and user experience. The result is a lot of vague anxiety about performance (“is my site fast enough?") without a clear understanding of what to measure, what the numbers mean, or which actions will move the needle.

This article fixes that. By the end, you'll know what Google actually measures, how those measurements work, how Squarespace sites typically score, and what you can do to improve scores without leaving the platform.

Core Web Vitals: The Three That Matter

Google uses three Core Web Vitals as ranking signals. They've been part of the ranking algorithm since 2021 and were updated in 2024. These are the metrics that affect your search visibility.

Largest Contentful Paint (LCP) measures loading performance. Specifically, it measures how long it takes for the largest visible element in the viewport to finish rendering. "Largest visible element" is usually a hero image, a background video, or a large block of text. Google considers an LCP of 2.5 seconds or less to be "good," between 2.5 and 4 seconds as "needs improvement," and above 4 seconds as "poor."

LCP is the metric most directly affected by your design decisions, because the largest element in the viewport is almost always something you chose to put there. A 4MB hero image will produce a slow LCP because the browser needs to download and render all 4MB before the metric is recorded. A text-based hero section with no large image will produce a fast LCP because text renders almost instantly.

What many designers miss is that LCP doesn't measure when the page "finishes" loading. It measures when the largest above-the-fold element is visible. Everything below the fold is irrelevant to LCP. This means you can have a page with fifty images, and if the hero section uses a well-optimised image or text-only layout, your LCP can be excellent even though the full page takes much longer to load completely.

Cumulative Layout Shift (CLS) measures visual stability. It quantifies how much the page content shifts around unexpectedly during loading. If you've ever been reading a webpage and the text suddenly jumped down because an image or ad loaded above it, that's a layout shift. Google considers a CLS score below 0.1 to be "good."

CLS is caused by elements that load without a pre-defined space reserved for them. The most common culprits are images without explicit width and height attributes (the browser doesn't know how much space to reserve until the image loads), web fonts that cause text to reflow when they replace the fallback font (Flash of Unstyled Text, or FOUT), dynamically injected content (ads, popups, cookie banners), and iframes (embedded maps, videos, forms) without set dimensions.

Squarespace handles image dimensions reasonably well, setting width and height attributes on most images. But embedded content (YouTube videos, Google Maps, third-party widgets) can cause CLS if the embed doesn't load with the same dimensions the browser initially reserved. Cookie banners that push content down rather than overlaying it are another common CLS source on Squarespace sites.

Interaction to Next Paint (INP) measures responsiveness. It replaced First Input Delay (FID) in March 2024 as the official responsiveness metric. INP measures the longest delay between a user interaction (tap, click, keypress) and the browser's visual response to that interaction. Google considers an INP below 200 milliseconds to be "good."

INP is primarily affected by JavaScript execution. When the browser is busy executing a script, it can't respond to user interactions. The main thread is blocked, and taps or clicks queue up until the script finishes. On Squarespace sites, the main contributors to poor INP are third-party scripts (analytics, chat widgets, marketing pixels) and, to a lesser extent, Squarespace's own application JavaScript.

INP is the hardest Core Web Vital for Squarespace designers to optimise, because the primary cause (JavaScript execution) is largely outside your control. You can't modify Squarespace's scripts, and removing third-party scripts is often not commercially feasible (the client needs their analytics, their chat widget, their booking integration). The realistic goal is to minimise the JavaScript you add, not to eliminate JavaScript entirely.

How Squarespace Sites Actually Score

Squarespace has historically scored lower on Core Web Vitals than platforms where designers have full control over the code (custom WordPress builds, static sites, headless CMS setups). This is a platform-level reality, not a reflection of individual design quality.

The reasons are structural. Squarespace loads a consistent base of JavaScript and CSS regardless of what features a specific page uses. A simple five-page brochure site loads much of the same codebase as a complex e-commerce site with membership areas and booking integrations. You can't tree-shake unused features or lazy-load platform scripts selectively.

That said, Squarespace has made significant performance improvements over the past two years, including better image optimisation, improved caching, and more aggressive lazy loading. A well-built Squarespace site in 2026 can comfortably achieve "good" scores on all three Core Web Vitals, but it requires conscious effort from the designer. A carelessly built site on the same platform will fail.

Typical score ranges for a reasonably optimised Squarespace site: LCP between 1.5 and 3.5 seconds (depending heavily on hero image size), CLS below 0.1 (achievable with attention to image sizing and limited third-party embeds), and INP between 100 and 300 milliseconds (dependent on third-party script load).

Measuring Performance Correctly

There are two categories of performance data, and understanding the difference matters for how you interpret scores.

Lab data is measured in controlled conditions: a specific device, a specific network speed, a specific location. Google's Lighthouse tool (built into Chrome DevTools and available at PageSpeed Insights) provides lab data. It's useful for diagnosing specific issues and testing changes, but it doesn't reflect real user experience because real users have different devices, different connections, and different locations.

Field data is measured from actual users visiting your site, aggregated in the Chrome User Experience Report (CrUX). Google uses field data for ranking purposes, not lab data. Field data appears in Google Search Console's Core Web Vitals report and in PageSpeed Insights under the "Discover what your real users are experiencing" section.

A critical nuance: your site needs a minimum threshold of traffic before Google has enough field data to assess it. New sites or low-traffic sites may not have field data available. In that case, Google may fall back to general platform-level performance data (how Squarespace sites perform on average) or simply not factor Core Web Vitals into the ranking for that page.

For designer purposes, test with Lighthouse for diagnosis and use PageSpeed Insights for field data. Run Lighthouse in an incognito window with extensions disabled, as browser extensions can significantly affect performance measurements. And always test the mobile score, not just desktop, because Google's ranking algorithm uses the mobile experience.

The Levers You Can Pull

Within Squarespace's constraints, here are the specific actions that have the largest impact on each Core Web Vital.

For LCP:

Image optimisation is the single most impactful change. Compress every image before uploading. Resize to no wider than 2500px (Squarespace generates responsive versions from your upload, but starts from whatever you provide). Use JPEG for photographs and PNG only when transparency is genuinely required. A hero image should be under 200KB after compression. Use tools like Squoosh, TinyPNG, TinyIMG, or ImageOptim.

Consider your hero section design. A text-based hero with a solid colour or gradient background will always have a faster LCP than an image-based hero. If you do use a hero image, ensure it's the right size and properly compressed. Background videos are the worst offenders for LCP and should be used only when they're genuinely essential to the design.

Reduce the number of above-the-fold resources. Every font file, CSS file, and script that loads before the hero content delays LCP. You can't control Squarespace's own resources, but you can limit what you add: fewer custom fonts (use system fonts or limit custom fonts to two files maximum), fewer third-party scripts in the header injection, and no custom CSS that triggers additional asset downloads (like background images loaded via CSS).

For CLS:

Set explicit dimensions on all embedded content. When embedding a YouTube video, Google Map, or third-party widget, wrap it in a container with a fixed aspect ratio so the browser reserves the correct space before the embed loads:

.video-wrapper {
  position: relative;
  padding-bottom: 56.25%; /* 16:9 aspect ratio */
  height: 0;
  overflow: hidden;
}
.video-wrapper iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Ensure cookie banners overlay rather than push content. If using a third-party cookie consent tool, configure it to display as a fixed overlay (typically at the bottom of the screen) rather than inserting itself into the page flow, which would push all content down and cause a layout shift.

Use font-display: swap for custom fonts to prevent invisible text while fonts load. This causes a brief flash of the fallback font, but it eliminates the layout shift that occurs when invisible text suddenly becomes visible as the custom font loads.

For INP:

Audit third-party scripts ruthlessly. Every script in your Code Injection adds to the main thread workload. Remove anything that isn't earning its performance cost. If the client insists on a live chat widget that adds 400ms to every interaction, present the data and let them make an informed decision.

Defer non-essential scripts. If a script doesn't need to execute immediately (and most analytics and marketing scripts don't), move it from the header injection to the footer injection. This doesn't eliminate the performance cost, but it delays it until after the page has rendered and become interactive.

Minimise custom JavaScript. If you're adding custom interactions via Code Injection, keep the code lean. Use CSS transitions and animations (which run on the compositor thread and don't block the main thread) instead of JavaScript-driven animations wherever possible.

The Performance Conversation with Clients

Performance optimisation often requires trade-offs that clients don't naturally understand. "I want a full-screen video hero" is a valid design desire, but it comes with a measurable performance cost. "I want live chat, analytics, a booking widget, a review aggregator, and a marketing pixel" is a valid business desire, but five third-party scripts will make the site noticeably slower.

Your job isn't to refuse these requests. It's to make the trade-offs visible. "Adding this video hero will likely increase our LCP from 2 seconds to 4 seconds, which puts us in the 'needs improvement' range for Google's metrics. Here's what that looks like in practice, and here's an alternative approach that achieves a similar visual effect with half the performance cost."

Performance is not an absolute. It's a balance between speed, visual richness, and functionality. Knowing the metrics, understanding what affects them, and being able to articulate the trade-offs is what elevates a designer from "the site feels a bit slow" to "here's exactly what's happening, here's what it costs us, and here's how to fix it."

---

Related Articles