How Fast Is Your Squarespace Site? A Real Performance Audit
Why Speed Matters More Than You Think
Every second matters. Google's research is brutal on this point: the probability of a visitor bouncing increases by 32% as page load time goes from one second to three seconds. At five seconds, bounce probability jumps by 90%. At ten seconds, it's 123%. A one-second site has a conversion rate roughly three times higher than a five-second site. The BBC found that for every additional second of load time, they lost 10% of their visitors.
Speed isn't just a nice-to-have. It's a business metric. Every second your site is slow, you're losing visitors who will never come back. Google knows this, which is why they've made Core Web Vitals (a measurement of how fast your site feels to users) an official ranking factor. A slow site doesn't just feel bad. It ranks worse. It converts worse. It makes less money.
The uncomfortable truth is that most people don't know how slow their website actually is. You've always viewed it on your own device, on your own Wi-Fi, with half the assets already cached from previous visits. The first-time visitor on a 4G connection in a patchy signal area sees a completely different version of your website. And that's the version that matters, because every new visitor is a first-time visitor.
The Case Study: A Wedding Florist in the Cotswolds
The Patient
A boutique wedding florist, two-person operation, established six years. Excellent reputation locally, plenty of word-of-mouth referrals, but increasingly dependent on web enquiries as the business grew beyond its immediate network. They'd built a beautiful Squarespace site on the Bedford template, migrated to Fluid Engine in 2023, and the work was genuinely gorgeous. Lush photography, elegant design, professional throughout.
But something wasn't converting. They were getting traffic—Google Analytics showed hundreds of visitors per month—but very few were filling in the enquiry form. The florist's complaint was simple: "Our website looks beautiful but nobody's booking. Something feels off."
The Diagnosis
We ran the site through Google PageSpeed Insights and the numbers told the story immediately.
Desktop score: 38 out of 100
Mobile score: 14 out of 100
Largest Contentful Paint (LCP) on mobile: 11.2 seconds
Time to Interactive on mobile: 13.8 seconds
Total page weight: 27.4 MB
For context, Google considers an LCP of 2.5 seconds or under to be "good." Anything over 4 seconds is "poor." This site's main content took over eleven seconds to appear on a phone. The average user would have given up and left three times over before seeing the first image.
Here's what was happening under the hood: the florist was asking potential clients—people actively planning a wedding and ready to spend thousands of pounds on flowers—to wait nearly twelve seconds on their phone. Most of them weren't waiting. They were tapping back and clicking the next search result.
What We Found When We Opened the Bonnet
Images. This was the primary culprit. The homepage featured a full-bleed hero image that was 6.8 MB. It had been uploaded directly from Lightroom at full resolution, 5,472 pixels wide, because the florist wanted her work to look perfect. Understandable, but catastrophic for load times. Below the hero were eight portfolio images in a grid, averaging 3.2 MB each. The portfolio page had another twenty-four images at similar sizes. Total image weight across just the homepage and portfolio: over 87 MB.
Custom fonts. The site used three custom web fonts loaded via Adobe Fonts—one for headings, one for body text, one for accent text. Each font file was loading synchronously, meaning the browser had to download all three before it could render any text on the page. Combined font weight: 1.4 MB.
Third-party scripts. The site had six external scripts running: Google Analytics, Facebook Pixel, a cookie consent banner, an Instagram feed embed, a review widget, and a chat widget that loaded on every page despite the client never once using it. Each script made its own HTTP request and loaded its own JavaScript and CSS. Combined overhead: approximately 2.1 MB, plus the latency of six separate server requests.
Unused sections. The homepage had fourteen sections. Three of them were set to "hidden" in the Squarespace editor but were still loading their assets—including images—in the background. Two sections at the bottom contained large background videos that auto-played on desktop but were invisible on mobile. The videos were still downloading on mobile, they just weren't being displayed. Combined weight of hidden and unnecessary assets: 4.3 MB.
No lazy loading optimisation. Squarespace does implement native lazy loading for images, but several portfolio images were placed high enough on the page that they loaded immediately rather than deferring. The site was trying to download the entire visual library upfront, regardless of whether the visitor would ever scroll that far.
The Treatment
The fix took a day and a half. Here's exactly what we did.
Image compression and resizing (2.5 hours). We downloaded every image, resized them to a maximum of 2,500 pixels on the longest edge (more than sufficient for any screen, including retina displays), and ran them through compression. The hero image went from 6.8 MB to 285 KB, a 96% reduction, with no visible quality loss. We re-uploaded every image on the site. Squarespace's built-in image processing helps, but starting with properly sized and compressed source files makes a significant difference.
Font optimisation (45 minutes). We reduced the custom fonts from three to two, dropping the accent font and using the heading font at a different weight instead. We switched from Adobe Fonts to self-hosted WOFF2 files loaded with font-display: swap, which tells the browser to show a fallback font immediately and swap in the custom font once it's ready. This eliminated the invisible text flash that was making the site feel broken during loading.
Script audit (1 hour). We removed the chat widget entirely—it hadn't been used in over a year. We removed the Instagram feed embed and replaced it with a simple linked grid of static images, updated monthly, cutting one external script and its associated API calls. We configured Google Analytics and Facebook Pixel to load asynchronously. We replaced the third-party review widget with a simple testimonial section using native Squarespace blocks and real quotes from Google reviews. Net reduction: four external scripts removed, two reconfigured.
Section cleanup (30 minutes). We deleted the three hidden sections that were still loading assets. We removed the background videos from the two bottom sections. We restructured the homepage from fourteen sections to nine, losing no meaningful content but eliminating significant overhead.
CSS for mobile performance (45 minutes). We added custom CSS to reduce heading font sizes on mobile (they'd been rendering at desktop scale, pushing content below the fold) and to tighten section padding. We set image focal points across the site so that background images cropped intelligently on mobile rather than losing their subjects.
The Results
The next day, after Squarespace's CDN had cached the changes, we re-tested.
Desktop score: 38 → 91
Mobile score: 14 → 72
LCP: 11.2 seconds → 2.1 seconds
Time to Interactive: 13.8 seconds → 3.4 seconds
Total page weight: 27.4 MB → 2.8 MB
The mobile score of 72 is worth noting. Getting a Squarespace site above 70 on mobile is genuinely difficult because the platform loads its own JavaScript framework, site-wide styles, and various system scripts that you can't remove. A score in the 70s is about as good as it gets without moving to a completely custom build. For context, many well-known commercial websites score between 40 and 60 on mobile.
What Changed in the Real World
Three months later, we checked in with the florist. Here's what happened.
Enquiry form submissions: up 34% compared to the same period the previous year. The florist hadn't changed her marketing, hadn't increased her social media activity, hadn't altered her pricing. The only variable was site speed.
Average session duration: up from 48 seconds to 1 minute 52 seconds. Visitors were actually staying long enough to browse the portfolio rather than bouncing before it loaded.
Bounce rate: down from 71% to 43%. This is the starkest number. Nearly three-quarters of previous visitors were leaving without interacting with the site. That figure nearly halved.
Google search position: moved from position 8 to position 3 for her primary keyword. Page speed isn't the only ranking factor, but Google has been explicit since 2020 that Core Web Vitals are a signal.
Mobile traffic proportion: stayed constant at roughly 68%. What changed was what those mobile visitors did. They were no longer bouncing. They were converting.
How to Test Your Own Site (The DIY Approach)
Step 1: Run the Speed Test
Go to pagespeed.web.dev and enter your URL. This is Google's official speed testing tool, and it's what Google uses to evaluate sites for ranking purposes. Look at the mobile score first (that's what Google uses for ranking in 2026).
Below 50: Your site has a speed problem that is actively costing you visitors and enquiries.
50-70: There's meaningful room for improvement.
Above 70 on Squarespace: You're in solid territory. Getting above 70 on Squarespace is genuinely difficult.
Step 2: Check Your Images
Go to any page in your Squarespace editor, click on an image, and look at the file info. If any image is over 500 KB for a hero banner, or over 200 KB for an in-page image, it needs compressing. Tools like TinyIMG (which integrates directly with Squarespace), Squoosh, or ShortPixel can do this in seconds.
Step 3: Count Your Third-Party Scripts
Go to Settings > Advanced > Code Injection and see what's there. Check your page-level code injections too. Every external script is an HTTP request your visitor's browser has to make. If you have scripts for services you no longer use, or widgets you added two years ago and forgot about, remove them.
Common culprits:
Chat widgets that you never answer
Instagram feed embeds
Third-party review widgets
Old analytics tracking
Email capture widgets from abandoned campaigns
Step 4: Test on an Actual Phone
Not the phone in your pocket connected to your office Wi-Fi. Ask a friend to open your site on their phone on mobile data and watch it load. Time it. If they look at you with polite impatience before your site loads, you have work to do.
Common Squarespace Speed Issues and Quick Fixes
Large, unoptimised images. Most common culprit. Solution: compress and resize every image to 2,000-2,500 pixels max on the longest edge before uploading.
Multiple custom fonts loading synchronously. Solution: use one or two custom fonts maximum, switch to self-hosted WOFF2 files if possible, and use font-display: swap to show fallback fonts while custom fonts load.
Hidden sections still loading assets. Solution: delete hidden sections entirely instead of just hiding them in the editor.
Auto-playing videos that are invisible on mobile. Solution: use static images instead, or use the video embed for videos that visitors explicitly click to watch.
Too many external scripts. Solution: ruthlessly audit and remove scripts you don't actively use. Replace third-party widgets with native Squarespace blocks where possible.
Oversized fonts on mobile. Solution: add mobile-specific CSS rules to reduce font sizes and padding on small screens.
The Bigger Picture
The florist didn't need a complete redesign. She didn't need new content, a new brand, or a new platform. She needed the site she already had to actually load. The difference between a mobile score of 14 and a score of 72 was a day and a half of optimisation work that paid for itself in the first month and has been paying for itself ever since.
Speed isn't glamorous. It doesn't show up in mood boards or brand guidelines. But it's the thing that determines whether anyone ever sees the beautiful design you built. Three seconds. That's all you get before a visitor loses patience and leaves. Make those three seconds count.