As the web has become more ubiquitous and vital in our lives, so has the desire for a better user-experience. These days, it's often jarring to still occasionally come across a website that isn't mobile-friendly and requires you to pinch-to-zoom to read its microscopic text on your phone. And your site also needs to be fast: no one has time to sit and wait for a loading spinner. Even if they do, they're likely not going to have enough patience to remain on your website for very long.
For website owners, there exists a variety of best-practices and user-friendly tools. Google Pagespeed Insights has long been a popular tool for evaluating common problems such as the need for image compression or code minification. But this is a very "one-size-fits-all" approach. What Pagespeed Insights does is scan the source code of the page for things that may be indicative of a problem, but these are just best guesses based on common issues. This often means that essential, non-problematic files end up getting flagged as problems.
If it sees a JavaScript file in your website's header (which, in 2017, you're going to have at least one of), it flags it as a potential problem, even if it's an optimized file that's necessary for the website to render. It's the same story with images: large banner images are simply always going to be larger than thumbnails, no matter how much you compress them, but Google will mark anything higher than a few kilobytes as potential for improvement. These suggestions can be helpful, but they're sort of an analogue to the cliche of asking "Have you tried restarting your computer?" each time you're experiencing a technical problem.
But try as you might to shave a few extra bytes off every photo, unless you're hand-coding every aspect of your website from back-end to front-end, you're very likely not going to have control over every stop in the loading pipeline. What if the platform itself is contributing to the problem?
I decided to do a bit of small-scale testing with some of our clients' websites, using 6 different sites: half of them on HubSpot, half on Squarespace. While this wasn't entirely scientific, I was still rather surprised at what I found.
Average time to load, when resource-caching is disabled:
Squarespace websites:
Site 1: 6.2 seconds
Site 2: 5.56 seconds
Site 3: 2.7 seconds
HubSpot websites:
Site 4: 1.74 seconds
Site 5: 1.25 seconds
Site 6: 2.07 seconds
If you're interested in seeing the loading pipeline of your own website, Chrome actually has a built-in developer tool, located within the network tab, that displays every single file and resource on a web page as it loads. For Squarespace, I found that the vast majority of these files are things that are a part of the Squarespace platform and not user-configurable content or customization. I've also come across a lot of user complaints on Squarespace help forums about website speed.
This test is, of course, not conclusive enough to make any sort of broad, sweeping statements about either CMS. I'm not claiming that everyone's Squarespace experience is a slow mess. Nor am I claiming that every HubSpot site will automatically be optimized for a quick experience. Quite the opposite: most modern CMSes give you enough tools to drastically slow down your website if you don't know what you're doing. However, what I do think is important is to do your research on a given CMS's other websites, users, and reviews before settling on one.