DEV Community

Cover image for How I Reduced Load Time by 25% on  Squarespace and Why I Couldn't Get More

How I Reduced Load Time by 25% on Squarespace and Why I Couldn't Get More

L.A. based web developer slowly parsing through Stack Overflow. If you like hot web dev tips or stories about being a freelancer, check out my newsletter:
・4 min read

Front Matter

Recently, I got a job that required me to debug a Squarespace site to see why it was loading so slow. I figured I'd share what I did to increase the load speed.


I used Google's built-in tool "Lighthouse". If you don't know where that is, you can find it in the Dev Tools under "Audit".

Disclaimer: All load times are evaluated against a simulated Slow 4G connection.

Why Load Time is a Problem

While you are running the audit, Google will give you a bunch of reasons to keep your site loading quickly. Essentially, the longer it takes, the less likely people are going to stay on your site. Additionally, Google is possibly planning to add a "slow badge" to sites that load slowly. That is really bad for user retention. Check out the article for that here. If you want an even more in-depth article, check this out.

The First Run

If you take a look at the readout below, you can see that the site is loading incredibly slowly (again, this is against a slow 4G).

Analytics of a Google Lighthouse Audit

The Issues and Fixes

The Audit will give you a list of common problems and fixes. Here's what I got.

Render Blocking scripts


When a page is being loaded, the browser loads things from top to bottom in the HTML file. That means any items in the <head> tag will load before the content in the <body> is even painted on the screen. In this case, there were 3 Mbs of scripts being loaded; both Javascript and CSS.

Render blocking warning


I removed all the render-blocking scrips that I could. This included jQuery and

A Note about Squarespace

There are ~6 seconds of load time we can't get back because of how Squarespace is built. They load the universal javascript in the header. There is no way to change this. Refer to this forum article posted in September for further info.

The total size of the "universal" bundles are nearly 1 Mb of data.

Incorrectly Sized Images


The site was loading a total of 2.7 Mbs of data for just the images. The key problems were:

  • A large logo in the header. It comes in at 1500px wide, despite the max width being 1200px.
  • A collection of 4 images in a carousel. Each one is 750px wide.
  • A banner image that is being hidden as soon as the page loads.


There is no fix. The platform handles responsive image resizing automatically. On retina screens, it'll load an image that's 2X the screen size. There isn't much we can do about how the platform is built. We sort of just have to accept that how images are loaded is out of our hands, so to speak.

Enormous Network Payload

The payload size on the first run was 5 Mbs! That's huge! Here are a couple of things I did to reduce it to 2.2 Mbs (which is still pretty big in my book).

Page-Specific Code Injection


They had a small script on every page to change the logo image. For whatever reason, they were pulling in the jQuery script on every page to accomplish this. Also, this was happening in the <head>.


I created a function in the footer that injects in every page that looks for specific pages they want to have a different logo - sans jQuery.

Banner Image


They were loading in a banner image that they were hiding.


Remove the Banner Image altogether.



Typography styles were coming from three sources: Typekit (built into Squarespace), and template style sheets. This meant they were downloading a total of 4 separate typeface families:

  • Europa
  • Promixa Nova
  • Gotham
  • Gotham Screen Smart


Upon final render, the only typefaces that were actually being used were the Gotham set. I changed the default styles in the Squarespace dashboard to Arial, because that is a web-font and doesn't have to be downloaded from anywhere.


Basically, after removing as many render-blocking scripts I could and removing any images that didn't need to be loaded, I managed to squeeze an additional 2s load time off the top. Unfortunately, because of how Squarespace is built, there is no way around the additional load time.

To be fair to Squarespace though, they do a good job of minifying the scripts. Also, considering how advanced their site builder is, I guess it's a fair tradeoff.

Got any other hot tips to reduce load time? Throw them in the comments below!

Discussion (10)

amcaplan profile image
Ariel Caplan

Hi Jared, I'm curious whether you've tried Cloudinary for image hosting? We have lots of ways to optimize images for faster loading without losing visual quality, with very little effort involved. And for smaller sites, chances are you won't end up paying anything for the service.

Here's a good place to start:

codenutt profile image
Jared Author

I am a fan of Cloudinary,but not really an option with Squarespace. As i mentioned in the article, they handle how the images are delivered

amcaplan profile image
Ariel Caplan

OK, I think I misunderstood you earlier. I will point out that you can probably squeeze out some better performance on the images using Cloudinary's transformations in the manner described in - essentially do an upload, q_auto down to a smaller size, then download and reupload to Squarespace.

Not as simple as it usually is to use Cloudinary unfortunately 😞but still might be worth your time if increasing speed is super valuable.

What Squarespace does for images ( is definitely better than nothing, but they don't seem to do the more advanced stuff - reducing size for the same image without perceptibly degrading visual quality.

I'd recommend trying with an image or two, and seeing if you can drop down that 2.7MB by a few hundred kB at least.

Thread Thread
codenutt profile image
Jared Author

Ah, gotcha. Thanks for the tip!

jjboy91 profile image

Awesome, thanks for sharing !
I'm wondering how did you proceed to remove all the render-blocking scripts ?

codenutt profile image
Jared Author

Thank you! In this case, I just removed all the scripts I could from the head section and moved them to the footer. This allows the page to load first, before running scripts. Hope this helps!

henryfphoto profile image
henry f. • Edited

It would be great if I could shave 2s off of my current 6.7s site load time. Google also tells me to eliminate render-blocking resources. Could do the same for my site at a fee? or would you be willing to teach me step by step in squarespace? Thanks for your time!

deathshadow60 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
deathshadow60 • Edited

Shame being squarespace you couldn't fix it being so ineptly coded that the entire markup and CSS likely belongs in the trash, and instead ended up screwing around with things that have far, FAR less to do with any real-world problems.

Laugh being that you probably could have kept the excess images if you could simply have fixed it being an endless stream of separate files and swung a giant axe at the endless pointless derpy "JavaScript for nothing".

... and that's before we talk the walking-talking WCAG violations they have the unmitigated GALL to call websites.

All the techniques you used being more akin to treating a headshot with a .50 cal with one of those useless pinky-sized band-aids that sits in the back of the medicine cabinet for decades because they're too small for any cut warranting a bandage.

There's a reason places like squarespace, wix, weebly, etc are nothing more than scams used to sucker nubes and rubes, and are utterly unfit for building anything more complex than a blog for grandma. Anyone promoting the use of such systems for business being nothing more than a dirtbag snake oil peddling scam artist.

codenutt profile image
Jared Author

Wow, you have some very strong views. I'm not gonna argue with you, but why do you dislike site builders so much?

deathshadow60 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
deathshadow60 • Edited

My primary web dev work of the past ten years -- basically half the time I've been doing it, and a quarter of the time I've spent my life programming -- has been accessibility consulting to banks, public utilities, government agencies, and health care facilities who are in court facing either federal fines, or civil litigation over WCAG failings. See laws like the US ADA, or the UK's EQA and DDA, or the dozens of other laws that certain types of sites are automatically required to adhere to, and now thanks to civil lawsuits it's open season on any business. (See the Supreme Court refusing to hear / overturn the Domino's finding)

... and not ONE of these train wrecks of developer ineptitude can produce a compliant website. Nor can they produce a fast website! Or one that indexes on search well...

But client after client comes up with lame excuses to claim "but millions of people use these systems" or even dumber claims of "it was easier" or "better for collaboration". Unfounded bald-face LIES that are more propaganda at best. They'll blame everyone and everything except the choice of tools, when more often than not it's EXACTLY these derpy tools that got them in trouble in the first place!

And to be brutally frank?

JUST like brain damaged front-end frameworks such as bootcrap, it is painfully and agonizingly apparent if you know the first blasted thing about HTML or CSS, the people who CREATED these systems aren't qualified to write a single line of either! They do not know enough about semantic markup, separation of concerns, accessibility, usability, or even just the most basic reasons HTML even exists to have ANY business building systems for people who know even less than themselves to use.

Don't believe me? Just view-source.

If you know even the most rudimentary aspects of web development, accessibility, and good practices looking at the HTML source of what something like bootcrap, or w3.css, WYSIWYG's, or any of these idiotic "Site builders" have the unmitigated GALL to call a website, you should be so horrified as to warn anyone and everyone away from it.

If you're not disgusted by what you see, you don't know anywhere near as much about HTML or CSS as you think!

They are a scam that prey upon ignorance. Nothing more, nothing less. Not a single claim made about them is based in fact, and they only provide the ILLUSION of simplicity. Even the best of them spit out results that will bite the site owner sooner or later.

Visual design tools and front end frameworks are the top two ways to screw over a business with the 3i of web development; Ignorance, Incompetence, and Ineptitude.

I've NEVER seen a site built with any of this mentally enfeebled trash that was worth a flying purple fish, and didn't need to be thrown in the garbage and started over from scratch to fix deep rooted issues and drag it kicking and screaming into the light.

But just like other scams such as Amway or Mary Kay, good luck convincing people brainwashed by the propaganda of that, given a confirmation bias and cognitive dissonance deeply rooted in apathy, ignorance, and wishful thinking. Hence why dealing with the fans of this rubbish is more akin to dealing with cultists than sane and rational engineers.