Squarespace makes good-looking sites and gives you almost no control over how they load — no server, no build step, no access to the markup. We ran 38 Squarespace sites through WebSpeed and measured what actually sits on the critical path. The same handful of things came back on nearly every one, and none of them is reachable from the editor.
That doesn’t look like a website address. Enter a domain — for example example.com or https://example.com/page.
No signup. See your before/after PageSpeed score in about a minute.
Stored audits — the original page against the same page served through WebSpeed, on mobile and desktop. Not a demo build: these are the sites as they ship.
Real Google Lighthouse audits, original vs. WebSpeed Fast. The ring is the mobile PageSpeed after; “faster” is the Speed-Index ratio; “lighter” and CO₂ (≈0.15 g/MB per visit, Sustainable Web Design v4) come from the measured byte reduction. SEO / conversion / bounce are projections from the measured LCP improvement, not guarantees. Scores are per-page; yours will differ.
* Core Web Vitals are a Google ranking signal; the biggest lift is leaving the “Poor” zone (score < 50), scaled here by device search share.
** Akamai / SOASTA (2017): a 100 ms delay cost 7% of conversions across ~10 billion retail visits; scaled here to the measured improvement.
*** Akamai / SOASTA (2017): a two-second delay raised bounce rate by 103%; scaled to the measured improvement, site-specific.
Measured, not assumed — this is what our filter logs recorded across the Squarespace sites we have audited, ranked by how many of them had something to fix.
Measured across 38 Squarespace audits · snapshot 2026-07-28
95%of sites
36 of the 38 sites we audited, and our highest-volume correction on this platform by a wide margin. Squarespace's own runtime and the blocks you added run as inline scripts that execute mid-render, so drawing stops each time one fires. On a phone that is the difference between a page that paints and one that stalls half-drawn.
97%of sites
37 of the 38. Squarespace splits its CSS across many small stylesheets, and each one is a separate round-trip the browser has to make before it can finish painting. The individual files are tiny; the queue of requests is not.
338fixes on 33 sites
One of our highest-volume corrections here. Images ship without width and height, so the browser cannot reserve space for them and the text jumps as each one lands — the layout shift Squarespace's polished templates otherwise hide.
124fixes on 36 sites
Squarespace serves your page, its assets, your fonts and your third parties from several origins. We consistently found stale resource hints pointing at origins the page never uses, while the connections that matter were discovered late.
Each one is independent and can be switched off for your domain — nothing here is all-or-nothing.
Inline body scripts are held until rendering is done, then run in order, and parser-blocking files are deferred. Same behaviour, out of the way of the first paint.
Small stylesheets are inlined into the first response and the rest stop blocking, so the browser paints on what it already has instead of waiting out a queue of requests.
We read each image's true aspect ratio server-side and write it into the markup, so the browser reserves the right box before the file lands and the text stops jumping.
Stale hints are dropped, and the origins your page genuinely uses get their DNS, TCP and TLS work started early — so the fetch itself is all that's left when the browser arrives.
The largest above-the-fold image is preloaded at high priority; everything below the fold waits until it approaches the viewport.
Core Web Vitals have been a confirmed Google ranking signal since 2021. The biggest win is leaving the "Poor" band, where faster competitors get preferred.
— Google Search CentralConversion tracks load time closely — on Akamai’s retail numbers a delay of just 100 ms cost 7% of conversions. Shaving seconds is the cheapest funnel work available.
— Akamai / SOASTA, 2017Close a two-second gap and bounce rate roughly halves — Akamai measured those same two seconds raising it by 103%. A page that paints early keeps the visit a slow one loses outright.
— Akamai / SOASTA, 2017Transfer weight maps to emissions at roughly 0.15 g of CO₂ per MB. Cutting bytes is the one optimization that shows up on a sustainability report.
— Sustainable Web Design v4Each figure links to the page that publishes it. The studies measure what delay costs; read here as what speed returns. Industry benchmarks, not a guarantee for a specific site — the per-site numbers are the audits above, and yours is a free check away.
The platform’s own help pages offer the usual list: compress your images, use fewer fonts, keep your pages short. It is not wrong, and it is also the only advice a Squarespace owner can act on, because everything else is out of reach.
So we went and measured 38 of them. Two findings came back on all but one or two, and neither is reachable from the editor.
Scripts run while the page is still drawing. 36 of the 38 sites we audited shipped inline scripts that execute mid-render — the platform’s own runtime plus the blocks you added — and this was our highest-volume correction on Squarespace by a wide margin. Each script that runs is a pause in the drawing of the page.
The CSS arrives as a pile of small files. 37 of the 38. Squarespace splits its stylesheets into many small requests, and the browser has to work through the queue before it can finish the first paint. No single file is heavy; the number of round-trips is the cost.
Underneath those two sit the familiar rest: images without dimensions, so the layout shifts as they land; resource hints pointing at origins the page never uses; the first-screen image fetched at the same priority as everything else.
Squarespace is among the most closed platforms we audit, and that is usually described as a gap in what support can change. It is really a limit on operations.
Speeding up a page is mostly deferring, reordering and dropping things the platform already emits — and every one of those verbs needs access to the markup. On Squarespace you cannot defer a script the runtime injected, combine stylesheets the platform split, or remove a connection hint you did not write. So the honest Squarespace speed guide ends where they all do: keep your pages light, and wait for the platform.
A reverse proxy moves where the work happens. Your Squarespace site keeps serving the page it always did; WebSpeed receives that page, rewrites its critical path, and hands the result to the visitor. Nothing inside Squarespace changes, so there is nothing for a platform update to undo and nothing for your team to relearn.
Most of what we do is invisible — the page looks the same and loads faster. There is a single exception worth stating up front, because it is specific to Squarespace and to how proxies work.
Squarespace offers typography through Adobe Fonts, and an Adobe Fonts kit is licensed to a named list of domains. The kit checks, in the browser, whether the current domain is on that list — and served through a different host it isn’t, so the fonts don’t load. The fix is yours and it takes two minutes: add the serving host to your kit’s published-domains list in your Adobe Fonts account, and we tell you exactly what to add. Fonts you host on Squarespace itself, or pull from Google Fonts, are unaffected. And if you would rather not touch the kit, the on-site integration keeps your original domain and the question never comes up.
We would rather you read that here than meet it in your own audit.
It needs nothing but the URL:
No — that is the point. WebSpeed runs in front of your existing site. You keep the editor, the hosting and your workflow; only what the browser receives changes.
Yes. We never touch the site inside the platform. Your team keeps editing in Squarespace exactly as before, and every publish flows through unchanged.
This is the one thing to know before you start, and we would rather say it plainly. Adobe Fonts are licensed to a specific list of domains and the kit checks the domain in the browser, so served through a different host they will not load until that host is added to your kit's published-domains list — a two-minute change you make in your Adobe Fonts account, and we tell you exactly what to add. Fonts you host on Squarespace itself, or use from Google Fonts, are unaffected. If you would rather not touch the kit at all, the on-site integration keeps your original domain and sidesteps this entirely.
Our measurements agree with them on the visual polish — the problem is not how the site looks, it is what the browser has to do before it can show it. On nearly every site we audited that was scripts running during render and CSS split across many requests. Those do not show up in the editor, and they are exactly what the audit measures.
No, and on Squarespace you largely could not: the usual route is the proxy, where traffic is routed through WebSpeed with a DNS change and nothing is installed anywhere.
It should not — every optimization here is about when and in what order things load, not what they are. The one exception is Adobe Fonts, covered above. The audit shows you the before and after so you can check the result yourself before deciding anything.
Paste your URL for a free PageSpeed comparison on mobile and desktop. No signup, about a minute.
That doesn’t look like a website address. Enter a domain — for example example.com or https://example.com/page.
No signup. See your before/after PageSpeed score in about a minute.