JJ Strength: Squarespace
Speed Optimisation

A Squarespace site can look finished and still feel slow. The design is done, the content is in place, and the page still takes its time to paint. The hero lingers, and a visitor on a phone waits a beat too long before anything useful appears. Speed is not a cosmetic problem. It costs visitors, ranking, and trust, and none of that shows up in how the site looks.

That is the problem this project set out to fix for JJ Strength. It is a site-wide performance optimisation of their Squarespace site, covering the homepage, four service pages, and two blog listing pages, aimed at faster Core Web Vitals, a quicker largest contentful paint, and lower total blocking time. The rule underneath all of it was simple: the design and the way the site works stay exactly as they are.

Put simply, we measured every included page with PageSpeed first, found what was actually slowing it down, then fixed those things underneath the surface. Large hero images were compressed and served properly, fonts and CSS were loaded more efficiently, non-critical scripts were deferred or delayed, and third-party embeds like Calendly and Brevo were tuned so they stopped holding up the page. Every change was tested on mobile and desktop, and the before-and-after numbers were recorded so each gain was proven rather than claimed.

The Starting Point: A Faster Site Without a Redesign

For a speed optimisation to be worth doing, it has to make the site measurably faster without changing how it looks or works. That is harder than it sounds, because careless optimisation is exactly what breaks forms, links, and layouts. The brief set a clear list of requirements:

• Measure before touching anything. Every included page had to be tested with PageSpeed on mobile and desktop first, so there was a real baseline and the exact largest contentful paint element and blocking issues were known before any change.
• Leave the design alone. The site had to look and work exactly as before, with no redesign and nothing broken.
• Fix the real bottlenecks. The work had to target what genuinely slowed each page, hero images, fonts and CSS, blocking scripts, third-party embeds, rather than cosmetic tweaks.
• Bring down largest contentful paint on mobile. Mobile LCP is where Squarespace sites often struggle, so the target was under 2.5 seconds where achievable.
• Reduce total blocking time. Scripts that run before the page is interactive make it feel sluggish, so non-critical ones had to be deferred or delayed.
• Prove it and keep it maintainable. The changes and any custom code had to be documented, with a before-and-after report per page and one revision round included.

The Build: Measure, Fix, Verify, Page by Page

The work runs page by page rather than as one sweeping change, because each page has its own slow spots. Each of the seven pages, the homepage, four service pages, and two blog listing pages, was measured first, then fixed where the data pointed, then retested. The forty individual blog posts were out of scope. Handling a Squarespace site this way, tuning it for speed without redesigning it, is the substance of the Squarespace website development behind this project. Each page followed the same order:

1. The page is tested with PageSpeed on mobile and desktop to set a baseline.
2. The largest contentful paint element and the render-blocking resources are identified.
3. Large images and hero images are compressed, sized correctly, and served efficiently, usually the biggest single lever on LCP.
4. Fonts and CSS are loaded more efficiently so they stop delaying the first paint.
5. Non-critical scripts are deferred or delayed, and Calendly, Brevo, and other embeds are tuned to load without blocking.
6. The page is retested, forms and links are checked, and the before-and-after numbers are recorded.

Squarespace and Cloudflare settings were reviewed and adjusted where they applied, custom code injections were documented so nothing was a mystery later, and one revision round was included so the numbers could be fine-tuned after the first pass.

Technical Architecture

Because this is Squarespace, the architecture is the platform itself plus a short layer of careful tuning on top. There is no custom backend to rebuild here; the work is about how the existing page loads. The parts that carried it:

• Squarespace platform and templates. A template loads fonts, scripts, and CSS that are not all needed up front, which is what slows the first paint. The tuning happens around that, not by replacing it.
• Images and hero media. Large images, especially heroes, are compressed, resized, and served efficiently, which is usually the biggest lever on largest contentful paint.
• Fonts and CSS delivery. Fonts and CSS are loaded more efficiently so they no longer delay the first paint.
• Script handling. Non-critical JavaScript is deferred or delayed, which brings total blocking time down and makes the page interactive sooner.
• Third-party embeds. The Calendly booking embed and the Brevo email embed are tuned to load without holding up rendering, with any custom code injections documented.
• Squarespace and Cloudflare settings. Caching and delivery options are reviewed and adjusted where they apply.

Speed work like this sits within the wider remit of no-code and low-code development, where the platform handles the plumbing and the effort goes into making it load fast without touching what already works. The part worth doing carefully is exactly that restraint: every change was tested on mobile and desktop, including forms and links, so faster never meant broken.

Challenges Solved

The hardest problems were the ones that quietly make a site feel slow. Speeding up without redesigning was the whole brief, so every optimisation improved the page underneath while it kept looking and working the same. Third-party embeds like Calendly and Brevo add scripts that can block rendering, so tuning how and when they load kept their function and removed the delay. Mobile largest contentful paint, where Squarespace sites often struggle, was pulled down by optimising hero images and prioritising the LCP element. Total blocking time, which makes a site feel slow even when it looks loaded, came down by deferring and delaying non-critical scripts.

The through-line was proving every gain with a before-and-after number rather than claiming it, which is what health and wellness brands running on Squarespace need when a slow page costs them bookings without ever looking broken.

The Result

The outcome is a Squarespace site that loads faster across the homepage, service pages, and blog listings, with better Core Web Vitals, a quicker largest contentful paint, and lower total blocking time, while the design looks and works exactly as it did before. The work targeted 90 or above on desktop PageSpeed and mobile LCP under 2.5 seconds where achievable, with every page retested, forms and links verified, and the changes and custom code documented alongside one revision round.

The build works because it measured first and fixed the real bottlenecks, rather than guessing or reaching for a redesign. If you want the same for your own Squarespace site, you can hire remote developers who do this speed work without touching the design, or tell us which pages feel slow and we will measure them and map the fixes.

Frequently Asked Questions

What did the JJ Strength optimisation actually change?

It made the Squarespace site load faster without changing the design. Hero and content images were compressed and served efficiently, fonts and CSS were loaded more efficiently, non-critical scripts were deferred or delayed, and the Calendly and Brevo embeds were tuned so they no longer blocked rendering. The work covered the homepage, four service pages, and two blog listing pages.

Does speeding up a Squarespace site mean redesigning it?

No. The whole point here was to leave the design and functionality exactly as they were. Speed was improved underneath the surface, and every change was tested on mobile and desktop, including forms and links, so nothing looked or worked differently afterwards.

How is the improvement proven?

Every included page is tested with PageSpeed on mobile and desktop before and after the work, so the gains are shown with numbers rather than claimed. The exact largest contentful paint element and the render-blocking issues are identified first, then fixed, and each page is retested.

What usually slows a Squarespace site down?

Large unoptimised hero images, fonts and CSS that load before they are needed, non-critical scripts that block rendering, and third-party embeds that load too early. These push up largest contentful paint and total blocking time, which is where the optimisation focused.

Were the individual blog posts included?

No. The scope was the homepage, four service pages, and two blog listing pages. The forty individual blog posts were out of scope, which kept the work focused on the pages that mattered most and made the before-and-after reporting manageable.