Wix vs Squarespace: A comparison for front end developers

By day (and many nights), I'm a front end developer.

So, when I first felt the urge to make a small photography website, a few thoughts immediately sprang to mind: React, CloudFront, S3, SSL, type checking...

In other words, I'd managed to overcomplicate the problem before I'd even started.

It's easy to look down upon, or even outright ignore, site generation services like Wix and Squarespace. Their low barrier to entry stirs a latent snobbishness in us, a perhaps unspoken feeling that they're for people who don't possess the know-how to do it the "right" way.

Torii Gate, Miyajima

Torii Gate, Miyajima

But underestimating them is a mistake. These services have sunk an entire tier of our industry, and their successors will undoubtedly bring the waters closer to our own feet.

This success is deserved. They make making websites quick and simple. It took me just four hours to spin up a website with a shopping cart, gallery, contact form and Instagram feed.

For those of us who remember FTP, Dreamweaver and .cgi, that's a white-knuckle ride.

In fact it was so quick, I did it twice. Once on Wix, and again on Squarespace. Spoiler: This was not because I loved the Wix experience.

In this comparison I'll take a look at both, specifically two aspects of them that we've learned to care about as front end devs, that I think we fear will fall short of our expectations if we don't control the complete website creation process. Namely, performance, and responsive design.

Performance

Of the two, my biggest concern about using a service was the performance of the website.

Because this is just a side project, with expected visitor counts barely north of zero, there's an argument that performance is a premature optimisation. This is a fair point, but likewise when you're a front end developer whacking their name in caps across the top of the site, you want it to come somewhere in the vicinity of your standards.

Without full control over the code, or the build and deployment processes, we are largely at the mercy of the service in this regard. They're catering for as broad an audience as possible, so I imagined that there'd be some level of bloat.

This turned out to be true, but it's not straightforward. Both services excel and suffer in different areas. To gauge performance I looked at two areas: JavaScript loading strategy and image handling. These struck me as the main two areas of a photography site that could pose a problem.

Shin-Kōbe

Shin-Kōbe

JavaScript

I didn't make the website twice just for blog fodder. The idea was to be MVP-quick, so once I'd made the site with Wix, I hoped I could move on to other tasks.

But, the site Wix generated was quite slow, even on a fibre connection. When I first looked into this, the site was so bloated by JS that I took immediate advantage of their 14-day money-back guarantee.

Zepto, jQuery, React. A hall of fame of JavaScript frameworks all loaded on a single site. Each loaded, in fact, up to three times, either from different CDN domains (incurring lookup penalties) or just slightly different versions.

Lodash, loaded three different times. Each in its 85kb entirety.

While there are some bundles, libraries are all requested individually. Even Redux (a 2kb library) is an entire HTTP request of all of its own. All up there's over 100 network requests to download ~3mb of JS. It's wild.

In comparison, the Squarespace site with all the same functionality is just 6 requests for ~500kb of JS.

Serving so much JS isn't just a bandwidth issue. Lighthouse recorded the JavaScript boot-up time for the Wix site as 15 seconds, whereas Squarespace is just 3.

Images

Common strategies exist for reducing the impact of image files, like progressive and lazy loading.

Ideally, you'd be able to upload your original images to the service and they'd use something like Imgix to serve them back, optimised for the requesting browser.

Squarespace disappoints in this regard. Gallery thumbnails are regularly as large as 3mb, and every thumbnail on the page is requested on load.

By comparison, the Wix Pro Gallery plugin only loads images when they scroll into view. It also progressively loads images of increasing quality so users on slow connections can at least see a low-quality preview.

Okonomiyaki in Hiroshima

Okonomiyaki in Hiroshima

Once the higher quality thumbs load, they're just 1mb max, with no major difference in quality from their Squarespace counterparts.

Even better, Wix allows you to adjust the image quality setting for all images in a gallery, bringing that size down even lower. Squarespace just has a help page that asks you to upload smaller images. When dealing with large galleries, this is an unhelpful help page.

So, Wix has an awful JavaScript strategy, but it has a few thoughtful features that makes it pretty great with images. While Squarespace, conversely, is efficient with JS, but wasteful with images.

But, heavier JS payloads equals heavier CPU usage, and we see that the Wix site took far longer to execute than Squarespace. This is time where the website is unresponsive, which is far more frustrating for a user than missing images.

Squarespace might not handle images intelligently, but at least there's some scope to upload images of a lower size and quality. There's no equivalent way to lessen the impact of Wix's 100+ JS file requests.

Responsive design

Another doubt I carried into this experiment was the grace with which these services could offer templates that were both easy to maintain and be responsive across all screen sizes.

Wix and Squarespace both take different approaches in how they handle desktop and mobile designs. These approaches have major knock-on effects on the simplicity of their respective editors.

Wix: Browser sniffing

Wix handles mobile users by browser sniffing and serving up a different site depending on the user agent.

Laundrette in Osaka

Laundrette in Osaka

I assumed this was so they could serve a "lite" version that took the opportunity to cut down their outrageous JS overheads for the slower connections and devices. But digging into the code there's no evidence that this is so. It's just a slightly different template with adjusted inline styles.

I suspect this approach is a legacy from a time when it wasn't so clear how best to handle mobile users. Or, perhaps from the limitations of the editor, which may have been written years before the dominance of mobile.

Either way, it creates a number of issues that complicates the editor.

For instance, the desktop version has practically zero responsiveness too. Content doesn't flow normally or resize dynamically, instead almost everything is positioned absolutely.

This means adding content or swapping two content blocks can be a delicate act of manual drag-and-drop repositioning, that litter the HTML with inline styles like this:

margin-left: calc((100% - 980px) / 2);

This 980px measurement isn't arbitrary. It's a user-defined value that marks a safe area. Some content blocks positioned or sized beyond this boundary (marked by snap points in the editor) will be cropped if the screen becomes narrower than this width. But then, others won't. It's a mystery that I didn't have the time or patience to uncover.

Another result of all this absolute positioning is that the page footer can't be just another element in the document flow. Its position has to be dynamically calculated, with styles like this:

position: absolute; top: 15240px; height: 215px;

They don't even bother to put the footer at the end of the DOM. Why bother, when it has to be manually positioned? Sadly, this breaks keyboard navigation. Tab through the page and focus will jump to items in the footer before items in the body.

Maybe this is an issue with the specific template I chose, but it seemed to me that the editor is geared around this kind of brittle design. It's a nightmare.

All of the above problems are compounded with the entirely separate mobile design. You'd imagine that, considering single-column layouts are so much easier to make responsive, surely this stand-alone template would stretch out to feel spacier on larger screens.

Robot Restaurant, Tokyo

Robot Restaurant, Tokyo

But even this is handled poorly. The entire site is rendered exactly the same no matter how wide the screen - its simply scaled up or down. On larger screens this can look like your Nan's phone in accessibility mode.

Further, the editor for mobile is a different mode that you have to switch to periodically. Because all positioning is done manually and absolutely, there's usually a nasty surprise or three awaiting in this mirrorverse template. Meaning all the nonsense repositioning you've already endured on the desktop is replicated on mobile. You also have to remember to check every page. This eats well into our limited time budget.

Squarespace: Actual responsive design

The Squarespace templates are truly responsive, and this permeates throughout the whole experience. For instance when using the editor, the site shrinks and grows to accommodate the various menus, so you're constantly exposed to the site at various screen widths.

It copes perfectly well with all these different widths because the templating system is more restrictive. This is a good thing - it simplifies the entire process from top to bottom, for the template author and for us, and we're here for this simplicity.

Rather than dragging and dropping content areas into arbitrary positions, every content block has insertion icons above and below it. Adding content via one of these will ensure the surrounding content reflows as expected.

There's still the opportunity to then move some of these blocks into pre-designated child slots of others (for instance, floating an image to the right, like many of the images in this blog post). The predictability of these slots means Squarespace template authors can make robust and smart templates.

Basically, these limitations means it's a lot harder for us to make it shit. Whereas my Wix attempt was quickly an absolutely-positioned mess, with button widths stretched and squashed seven ways from Sunday.

Ibaraki

Ibaraki

The wrap

In this guide I've considered the two services from the idea of speed and simplicity. They both offer similar levels of customisability and support for stuff like CSS and JavaScript, but I haven't covered those here. If I start to go down the rabbit hole of hacking that stuff on top, it might be time to start looking into rolling my own. I'm not here for the power.

For now, I've been pleasantly surprised by Squarespace. Throwing robust, maintainable pages together is really quite simple. I've spent more time writing this blog post than on the site itself.

There's a few sprinkles that make the finishing touches for the developer. For instance, its blog editor offers Markdown support. It also allows the removal of www. from linked domains, which Wix doesn't.

I've been convinced that for a certain type of project, an instrument as blunt as this isn't something to instinctively turn my nose up at.

As a small aside, it's been a nice experience to have all these tools laid out ready to use. Genuinely beautiful templates, drag and drop gallery uploads, a surprisingly robust blog and content editor.

I'm used to making websites via VS Code, the terminal, and the AWS control panel. I don't expect these things to go away, but as we move towards our componentised future I feel like more of us will spend more time modifying websites via a GUI. The feedback loop is much tighter, and where I originally assumed I'd feel a little divorced from the process I actually found it quite hands-on.

It reminds me a little of game engines like Unreal and Unity. They both allow developers to write components that expose variables. These can be assembled, tweaked and remixed by designers. Maybe there's a hint of things to come there, too.

Akihabara

Akihabara