The advice, and what it covers
Squarespace’s help pages on loading speed are about what the owner puts on the page. They recommend images of 500 KB or less, fewer blocks per page, excerpts instead of full posts, fewer animations. That is sound advice, and it covers the part of the page the owner can change.
We wanted to know how large that part is. We took 155 Squarespace homepages measured between 18 and 29 September 2026 and sorted every byte by where it came from: Squarespace’s own servers, the owner’s uploads, fonts, and everyone else.
Where the bytes come from
| Part of a Squarespace homepage | Median share of the page’s bytes |
|---|---|
| Squarespace’s own JavaScript | 42% |
| Images | 29% |
| Third-party requests (analytics, pixels, embeds) | 7% |
The platform’s JavaScript was the largest part: a median of 1066 KB in 38 files, against 0.8 MB of images. It made up 83% of all the script on the page; third parties accounted for the remaining 17%. On 88 of the 155 homepages it weighed more than all of the images combined.
The range is narrow. At the 10th percentile it was 792 KB and at the 90th 1381 KB, which is what you would expect of code that ships with the platform rather than code a site owner chose.
What the owner controls
Images, the page’s length and the third-party tags are the owner’s, and Squarespace’s advice addresses all three. On the median page they were the smaller share.
That does not make the advice wrong. An oversized hero photo is still the single easiest thing to fix, and it lands on the Largest Contentful Paint directly. It does mean that a Squarespace page with perfectly compressed images still carries about a megabyte of script that its owner cannot remove, defer or replace.
Fonts
90 of the 155 homepages (58%) loaded fonts from Adobe Fonts, a median of 6 files and 135 KB. Pages using it carried a median of 200 KB of fonts in total against 87 KB on pages that didn’t.
What the weight costs
Less than the size suggests, as far as our data can show. The median original scored 52 on mobile and 73 on desktop, with about 300 ms of Total Blocking Time. Splitting the 7.1 sites into thirds by platform JavaScript, the heaviest third blocked the main thread for longer (373 ms against 285) and scored a few points lower (50 against 55). The direction holds; the gap is small next to how much one page’s score moves between runs.
So the honest reading is narrow. A Squarespace homepage is mostly Squarespace, and the part an owner can tune is the minority of it. How much faster the page would be without that runtime is not something a comparison between Squarespace sites can answer, because every one of them has it.
Method and limits
Every completed Squarespace audit that passed our measurement gate (finished, no failed run, the accelerated copy rendered faithfully, no redirect leak), latest measurement per host, all taken 18–29 September 2026: 155 homepages. Bytes are transfer sizes from the Lighthouse network log of the original page on mobile, not the accelerated one. A file counts as the platform's when it is served from Squarespace's own hosts (assets.squarespace.com, static1.squarespace.com, *.squarespace-cdn.com, sqspcdn.com); fonts count as Adobe Fonts when served from use.typekit.net. The template version (7.0 or 7.1) is read from the stored HTML. Shares are medians per page, so they don't add up to 100%.
Measured on 29 Sept 2026 across 155 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- Homepages only, as submitted to us or found by our discovery feed. Not a random sample of Squarespace sites, and a homepage with a video header or a long gallery will not look like a blog post.
- The weight of the platform's JavaScript only weakly tracks the score. Inside the 7.1 group, splitting pages into thirds by that weight moved Total Blocking Time from 285 to 296 to 373 ms and the mobile score from 55 to 51 to 50. The direction is consistent; the size of the effect is too small to price, so we don't.
- Bytes on the wire after compression, not the size of the code the browser has to parse, which is several times larger for JavaScript.
- Adobe Fonts pages showed a later first paint (5.3 against 4.6 s) only inside the 7.1 group, and the score difference was not significant, so we describe the fonts as weight only.
- One lab profile (Lighthouse mobile, throttled). A visitor on fast broadband will feel the same bytes less.
Sources
- Reducing your page size for faster loading — Squarespace Help Center
Pages with many images can load slowly, especially on mobile devices and slower connections.
- Formatting images for display on the web — Squarespace Help Center
To help your site load quickly, we recommend uploading images of 500 KB or less.
- Reduce JavaScript execution time — Chrome for Developers
JavaScript gets parsed and compiled on the main thread. When the main thread is busy, the page can't respond to user input.
Free to quote and reuse under CC BY 4.0 — credit WebSpeed and link to this page.