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:
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 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.
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:
|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:
Google's speed algorithms judge the default mobile web page, not the AMP version;
40% of users will leave a page that takes more than 3 seconds to load; and
And, the economic value of faster response times has been proven since 1982.
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.