Speed Optimisation for Squarespace Sites: What You Can Actually Control

Education

30 Dec

Every Squarespace client wants a fast site. Every designer gets asked about speed. But here's what most people don't realise: a huge portion of Squarespace's performance is completely out of your hands.

That doesn't mean you're powerless. You can make meaningful improvements. But you need to understand the boundaries first, because optimising for things you can't control is a waste of time.

What You Can't Control, and Why That's Okay

Squarespace is a managed hosting platform. They control the server infrastructure, the CDN, the image processing pipeline, and the core rendering engine. You don't get to touch any of that. Their engineers have optimised it globally, and honestly, it's pretty good.

You can't install caching plugins. You can't minify core HTML or CSS. You can't rewrite server-side code. You can't optimise the database. These things are black boxes.

What this means in practice: your PageSpeed Insights score will always have a ceiling. You might get to 70-80 on mobile and 85-90 on desktop if you're careful. But that 100 score everyone dreams about? Not happening on Squarespace for complex sites. Accept it and move on.

The good news is that Squarespace's infrastructure is reliable and performant. Your site won't be slow because of hosting. It'll be slow because of what you're doing within Squarespace's constraints.

Images: The Biggest Win

Image optimisation is where you can make real improvements. Squarespace compresses images automatically and serves them through their CDN, which is excellent. But that doesn't mean you can just upload massive RAW files and call it a day.

Before uploading, export images as optimised JPEGs or WebP. Use 1.5 times the display size at maximum. If an image is displayed at 800 pixels wide on desktop, export it at 1200 pixels. Squarespace will handle responsive versions from there.

For product photography, keep file sizes under 300KB. For hero images, aim for under 500KB. Your eyes can't tell the difference between a perfectly compressed 200KB image and an uncompressed 2MB image on a website, but your visitors' devices absolutely can.

Squarespace's image loader is actually quite smart. It loads a low-quality placeholder first, then loads the full image as the user scrolls. This keeps initial page load fast. Don't fight it by uploading oversized images.

One thing you can control: image count. Every image is a network request. Pages with 20 hero images load slower than pages with 5. Sometimes it's worth sacrificing visual richness for speed.

Use the Squarespace native Image block rather than custom code whenever possible. It's optimised for their platform. Custom image implementations rarely perform as well.

Third-Party Scripts: The Real Performance Killer

Here's where most Squarespace sites slow down. Chat widgets, analytics, tracking pixels, email tools, social feeds, live chat. Every one of these is a third-party script hitting an external server.

Each script adds latency. Most popular tools are reasonably optimised, but if you're loading five third-party scripts, you've added measurable delay to page load time. Some tools are lazy-loaded (they only run after the page loads), which helps. Others block page rendering.

Before adding any tool, ask: is this essential? A chat widget might be nice, but if it adds 200 milliseconds to load time and only captures one conversation per week, the trade-off isn't worth it.

If you need a tool, check if Squarespace has a native integration or app. Native integrations usually perform better than custom code implementations because Squarespace has optimised them.

For analytics, use GA4 via the Squarespace native setting rather than embedding the full script. It's more efficient.

Audit third-party scripts before handing over to clients. Use your browser's Network tab to see which scripts are taking the longest. If a tool is slower than 500 milliseconds to load, consider alternatives.

Custom Code Weight: How Much Is Too Much?

CSS and JavaScript injected into Squarespace sites add weight. Squarespace already loads quite a bit of their own code, so extra custom code compounds the problem.

Most custom CSS should be under 20KB. If you're writing hundreds of lines of CSS, you're probably overcomplicating your design. Use Squarespace's built-in styling options first. They're optimised and will perform better than custom CSS.

Custom JavaScript should be minimal. Don't write JavaScript to do something Squarespace can already do. If you're adding animations or interactions, consider whether they're worth the performance hit. A fancy scroll animation might look great, but it's JavaScript running on every scroll event.

Minify any custom code you do write. Remove comments, whitespace, and unnecessary characters. A minified version is always smaller.

Consider code-splitting. If you have JavaScript that only runs on specific pages, use Squarespace's code injection targeting to load it only where needed, not site-wide.

Font Loading: The Subtle Performance Dryer

System fonts are fastest. They're already installed on every device. No network request needed. If you use San Francisco, Segoe UI, or Georgia, your site loads immediately.

Custom fonts require downloading. Google Fonts are reasonably fast because Google's infrastructure is good, but there's still a network request. Web fonts from other sources are often much slower.

If you use custom fonts, use variable fonts. A variable font file that covers multiple weights and styles is often smaller than loading multiple font files. Google Fonts supports variable fonts now, which is a solid option.

Use font-display: swap in your font declarations. This tells the browser to show a system font while the custom font loads, so text isn't invisible. This is a legitimate CSS property that improves perceived performance.

Squarespace allows custom fonts via the design settings. Use this instead of @import declarations when possible. Squarespace has probably optimised their font-loading pipeline better than custom code would.

Limit custom fonts to two at most. One for headings, one for body text. Every additional font is another network request.

Lazy Loading and Image Behaviour in Squarespace 7.1

Squarespace 7.1 has native lazy loading for images. Images below the fold don't load until the user scrolls to them. This is automatic and happens without any configuration.

You don't need to do anything special. It works out of the box. This is one of the reasons Squarespace sites perform reasonably well without optimisation.

If you're using custom code to load images, make sure your implementation respects lazy loading principles. Don't load all images upfront in a gallery, for example.

How to Actually Test Site Speed

PageSpeed Insights is the most important tool. It's what Google uses to rank sites, so what it says matters. Test your Squarespace site at pagespeedinsights.web.dev and check both mobile and desktop.

PageSpeed Insights uses real-world mobile and desktop data from Chrome users. It's the most representative of actual user experience.

GTmetrix gives you more detailed waterfall charts. You can see exactly which resources are taking the longest to load and in what order. This helps identify bottlenecks.

WebPageTest is more granular. It simulates different connection speeds and devices, so you can test how your site loads on slow 3G connections and older devices. Useful for understanding worst-case scenarios.

Test multiple pages, not just the homepage. Homepages are often optimised, but internal pages might have issues.

Reading a PageSpeed Insights Report: What Actually Matters

PageSpeed Insights gives you a score from 0-100. For Squarespace sites, aim for 70 or above on mobile, 80 or above on desktop. If you're getting those numbers, you're doing fine.

The report lists opportunities and diagnostics. Not all of them are actionable on Squarespace.

Image optimisation recommendations usually apply. Squarespace compresses, but you can still upload smaller files before uploading.

Unused JavaScript warnings often point to third-party scripts you can't control. Acknowledge the warning and move on.

Render-blocking resources warnings are usually about Squarespace's core code. You can't fix them. Ignore.

Cumulative Layout Shift warnings are about visual stability. This is worth investigating. If elements are moving around as the page loads, that's a layout shift. Usually caused by missing image dimensions or font loading. Fix by setting explicit dimensions on images and using font-display: swap.

First Contentful Paint and Largest Contentful Paint are the time-based metrics that matter most. These reflect actual user experience. If these are under 2-3 seconds, your site is good.

Optimisations That Actually Move the Needle

These improvements consistently result in faster sites and better PageSpeed scores on Squarespace:

One: reduce image count and file size. This alone can improve scores by 10-15 points.

Two: remove unnecessary third-party scripts. If a tool isn't driving measurable value, delete it. Each removal usually improves scores by 5-10 points.

Three: limit custom code. Reduce CSS and JavaScript to what's essential. This usually gives a 5-point improvement.

Four: use system fonts or variable Google Fonts. This typically improves scores by 5 points.

Five: set explicit image dimensions. This reduces cumulative layout shift. Usually a 3-5 point improvement.

These five things are where you focus. They're achievable and result in noticeable improvements.

Setting Expectations With Clients

This is important: tell your clients upfront that Squarespace sites won't get perfect PageSpeed scores. Explain what's achievable (70-85 is excellent) and why perfect scores aren't realistic on this platform.

Explain the trade-off: a rich, visually interesting site with animations and custom fonts will load slower than a minimal site with system fonts and no JavaScript. The client gets to choose where on that spectrum they want to be.

If a client is obsessing about PageSpeed scores, redirect the conversation. What matters is actual user experience and conversions, not a number out of 100. A site with a 75 PageSpeed score that converts well is better than a 95-score site that doesn't.

Test before launch. Run PageSpeed Insights in the final week of development. If you're seeing scores in the 70-80 range, you're in good shape. If you're lower, identify the biggest bottlenecks and tackle those.

The Design vs. Performance Trade-Off

Here's the truth: the most visually interesting sites are rarely the fastest. Adding animations, custom fonts, video backgrounds, and complex layouts makes sites slower. That's physics.

Your job as a designer is to make conscious trade-offs. A full-screen video hero section is beautiful but costs significant performance. A scrolling animation looks great but runs on every scroll. A complex interaction is delightful but requires JavaScript.

Ask yourself: does this design element serve the client's goal? Does it improve conversion rate or user engagement? If the answer is no, remove it. If the answer is yes, keep it and accept the performance cost.

Fast and boring beats slow and beautiful. Choose simplicity when it wins.