Squarespace Isn't As SEO-Friendly As It Seems

Squarespace is a solid publishing platform that ticks almost every box when it comes to search engine optimization: editable metadata, JSON-LD schema, automatic sitemap generation, etc.

But, all is not well in the land of Squarespace SEO.

Page delivery is brutally slow over a mobile connection. I should know: This website is built with the Sofia theme (and the irony of claiming "Fast" in my brand name isn't lost on me).

Let's take a deeper look at where things are going right and wrong:

The Good

One of the benefits of using Squarespace is that you can launch Google AMP versions of a webpage just by clicking a button. Accelerated Mobile Pages are fast by definition. When a page on this site is followed by the "?format=amp" parameter, it can achieve Lighthouse speed scores between 99-100. Near perfect!

The Bad

The full desktop experience of this website isn't much different from a simple AMP page. Despite my Web 1.0-like design choices (webfonts and styles are used sparingly and there are no images), desktop speed scores are in the 50-89 range. Disappointing.

The Ugly

All Squarespace sites have a JS bundle that blocks the rendering of the page. That's why mobile speed scores clock at a low F (around 35). This one-size-fits-all approach to script delivery is a bottleneck in the critical rendering path, adding seconds of latency.

Let's look how the load time of an article (the best weighted blankets) compares to the AMP version of the same page. As a foil, let's also compare a Squarespace-delivered page (offsite) that contains 55 images and more than 4,000 words of text. The numbers below are from Lighthouse's emulated mobile network:

The Data

  Article AMP Page Foil
First Contentful Paint 5.0 s 0.8 s 4.8 s
Speed Index 5.9 s 1.3 s 6.6 s
Time to Interactive 9.3 s 2.1 s 11.1 s
Main Thread Work 5.0 s 0.9 s 7.4 s
Network Payload 1,004 KB 77KB 11,228 KB

Not surprisingly, the AMP page smokes the canonical version of the same article as well as the image-heavy foil page. But, it is surprising how the size of the network payload only impacts a page's rendering up to a point. The latency of the monstrous 11,228 KB foil page isn't proportionally different compared to the (still too large) 1,004 KB payload of the text-only article.

The critical rendering path is sandbagged by loading unnecessary resources up front.

The Cost of Convenience

There are practical reasons to share libraries and frameworks between templates, but the convenience of deploying features and styles may do more harm than good:

Squarespace has a fine engineering team. When you audit this website’s performance using GTmetrix’s 27-point grading scale, there are 26 A-ratings (and 25 of them are “A+”). There is also one low “F.”

To leave things as they are is to cost all visitors time and all publishers money.

I hope that Squarespace's product team will prioritize a rebuild of their platform’s critical rendering path. To do so will benefit users, publishers and Squarespace itself.

John DeFeo