Skip to main content

Website Builder Performance Review

· Updated on · 11 min read

Site builders let you create your own website without writing any code, but the websites they generate aren't always fast. Slow page load times not only affect the experience of your visitors, but can also hurt SEO.

I built a similar website using 14 different website builders and tested their site speed. This post first presents the overall results and then looks at each website maker in detail.

  1. Site builder performance results
  2. Rendering performance
  3. A look at the performance of each site builder
  4. Takeaways for site builder developers
  5. More metrics

Site builder performance results

The table below shows the test results for each website builder. It's sorted by the site's Lighthouse score, which gives an overall assessment of the performance of a web page. (This is also the score you would get from PageSpeed Insights.)

The Performance score isn't always the best metric to evaluate website performance. You can click on the column headings in the table to sort the different site builders by a different metric.

While Versoly has the highest Lighthouse score on mobile, Wix has the highest score on a desktop device. Strikingly renders initial content the fastest, but it takes a long time for the page to become interactive.

Site Builder Score FCP SI LCP TTI CPU Size
Versoly802.11 s3.43 s4.37 s4.38 s672 ms453 KB
Webflow771.74 s3.13 s4.95 s4.96 s1.35 s671 KB
Wix721.67 s2.67 s5.24 s6.69 s3.26 s759 KB
Site123672.61 s3.21 s3.40 s5.57 s2.30 s558 KB
GoDaddy632.30 s3.02 s3.93 s7.02 s3.77 s783 KB
Jimdo583.62 s5.54 s5.70 s4.34 s1.35 s517 KB
Yola542.08 s4.60 s4.62 s3.65 s3.22 s615 KB
Webnode483.75 s4.92 s9.05 s6.26 s2.21 s855 KB
Weebly393.40 s6.74 s7.33 s7.40 s3.74 s996 KB
Wordpress.com342.65 s4.88 s5.54 s15.9 s9.46 s878 KB
Strikingly321.12 s4.01 s22.5 s28.7 s10.6 s2.32 MB
SquareSpace312.09 s8.29 s8.79 s6.97 s3.56 s994 KB
Weblium233.68 s6.44 s6.93 s19.0 s3.67 s1.14 MB
UCraft182.67 s10.6 s15.6 s22.7 s10.4 s3.29 MB

Performance metrics

Lighthouse Performance Score

This is an overall assessment of the website's performance, combining 6 different metrics into a score ranging from 0 to 100.

First Contentful Paint, Speed Index (SI), and Largest Contentful Paint (LCP)

The First Contentful Paint measures when the user first starts seeing page content, such as text or an image.

Speed Index visually measures how quickly the page content reaches its final state.

The Largest Contentful Paint measures when the largest element on the page was rendered. Unlike Speed Index, the LCP will increase even if the newly painted element is similar to the previous element content.

TTI (Time to Interactive)

Time to Interactive measures how quickly the page becomes idle, meaning there isn't much ongoing network or CPU activity. This usually means that any interactive elements on the page are ready to be used by the visitor.

CPU Processing Time

This measures how much time the browser spends on things like running JavaScript code or rendering page content.

Page Size

This measures the overall (compressed) download weight of the page.

Rendering performance

Minimizing the time it takes for page content to appear after navigating to a page is one of the most important aspects of site performance.

The image shows a side by side view of the rendering timelines of all tested website builders.

Filmstrips for all tested website builders

(I added Webflow later, so it's not included in this image.)

A look at the performance of each site builder


Versoly takes a while to render the image, but doesn't run any additional JavaScript processing once the page has loaded.

A different default background color for the image would make it easier to read the text early on.

Versoly performance filmstrip

There are two render-blocking CSS files, both on different domains. That means the existing server connection can't be re-used. The background image does not start loading until the render-blocking CSS has been finished loading.

This request waterfall shows the server connections being made and list the network requests.

Versoly request chart

Versoly only makes 10 requests overall, which is the lowest request count among all tested site builders.


Webflow also starts to render quite quickly, but then takes a while to start downloading the image.

Webflow performance filmstrip

With a size of just 2KB, the initial page HTML loads very quickly. However, there are two render-blocking CSS and JavaScript requests, both on different domains that require a new server connection.

The hero background image is defined in the render-blocking CSS file, and therefore doesn't start to load until after the CSS file.

At 355KB the background image is also fairly large and takes a while to download. It could be worth first serving a low-resolution version of the image before starting the full download.

Webflow request chart


Wix quickly renders the general page layout and then loads the image. It looks like the text doesn't show up until a web font is loaded, however this doesn't seem to be the case when testing with a newer version of Chrome.

Wix performance filmstrip

Compared to Versoly, the Wix site is a lot chunkier with 66 network requests and 2s of JavaScript execution time.

Wix does not have any render-blocking resources apart from the root document, but downloading the 102KB HTML document can take half a second on a slow connection.

Wix request chart


The Site123 page loads fairly quickly, loading two render-blocking CSS files in addition to the document. Once the site has rendered there's isn't much additional work that's done by the CPU.

Site123 performance filmstrip

The background image starts loading immediately after the HTML response has arrived, thanks to a rel="preload" tag.

Site123 request chart


The GoDaddy site contains several render-blocking scripts and stylesheets. The background image loads quickly, as GoDaddy first serves a 1.3KB low-resolution image before serving the higher-resolution version.

GoDaddy performance filmstrip

In total, GoDaddy makes 148 network requests when loading the page. Part of this consists of initializing a service worker, so that the site is available offline after the initial load.

GoDaddy request chart


The initial render for the Jimdo site is quite slow, and it takes over 6s for the image to show up.

Jimdo performance filmstrip

The cause of this is a chain of render-blocking CSS requests. First, Jimdo loads layout.css, which in turn contains an @import statement fetching a font definition.

Jimdo request chart


The Yola site only has partial server-side rendering, most of the work is done by client-side JavaScript. As a result, the page spends 1s running JavaScript before starting to load the background image.

Yola performance filmstrip

The JavaScript application code, as well as multiple CSS files, also block the initial render for a while.

Jimdo request chart


On the Webnode site, no content is rendered for the first 4s.

Webnode performance filmstrip

Again we can see a chain of render-blocking CSS requests. The first Typekit CSS file uses @import to load another CSS file.

Importantly, this CSS file is on a different domain, meaning a new server connection has to be set up. This could be sped up by preconnecting to the domain.

Webnode request chart


Weebly starts rendering after 4s, but text doesn't appear until 5 seconds after opening the page.

Weebly performance filmstrip

This is because the page is waiting to load the web fonts before rendering the text. This delay could be avoided by using the CSS font-display: swap option, which would use a default font until the desired font is available.

Weebly request chart

The site starts to render after about 4s and the image loads after 6s.

Wordpress performance filmstrip

After the initial load it takes a while for the page to become idle. It makes a total of 355 requests, mostly contacting various advertising domains.

Wordpress request chart


Strikingly inlines all necessary CSS into the initial document request. As a result, there are no render-blocking scripts or stylesheets, and Strikingly has the fastest First Contentful Paint with a value of just 1.1s.

Strikingly performance filmstrip

However, the site then continues to download 1.8MB of JavaScript code. All of this needs to load and execute before the page becomes interactive, for example so that visitors can click on the menu icon.

To speed up that process, the bundle size could be reduced and the two scripts could be loaded in parallel.

Strikingly request chart

When testing the site with PageSpeed Insights, Lighthouse actually prematurely ends the test before the page finishes loading and becomes interactive. As a result, it reports a Time to Interactive of just 4.5s, and an overall Performance score of 72.

Strikingly PageSpeed Insights score


SquareSpace starts loading reasonably quickly, but it then takes a long time before the background image shows up.

Squarespace performance filmstrip

This is because the image is not included in HTML that was rendered on the server, and as a result the browser first needs to download and run 609KB of JavaScript code before starting to load the image.

Squarespace request chart


Rendering of the Weblium site is blocked for a while due to various CSS files, including a 172 KB stylesheet with embedded web fonts.

Weblium performance filmstrip

After the initial render, Weblium launches a React app and starts downloading the background image. Later on in the process a 475 KB JavaScript file called legacy.js is loaded and run.

Weblium request chart


The UCraft site starts rendering fairly quickly, but the background image is lazy loaded and depends on JavaScript code to run and trigger the image download.

UCraft performance filmstrip

Once that JavaScript code has run, the page not only downloads the background image but also another 1.16MB that isn't used on the site but appears to be part of the template I used.

UCraft request chart


I tested Mozello as well, but didn't include it in the results because the free plan doesn't support HTTPS. HTTPS is good for security but slightly slows websites down, so it didn't feel like an apples to apples comparison.

Having said that, Mozello's mobile Lighthouse score of 83 was actually the highest overall score. I would expect Mozello sites to be fast even with HTTPS enabled.

With a page weight of 258 KB, Mozello also had the lowest download size. After the initial render there's no further network or CPU activity.

Mozello filmstrip


In each website builder, I created a simple site with two components: a heading section with a background image, and a three column text section. I tried to remove all unnecessary content from the page and disabled parallax on the image background where it was enabled by default.

BizSolutions website

Tests were run in Chrome 84 using Lighthouse 6.3.0, packet-level network throttling, and CPU throttling using Chrome DevTools. The throttling settings were chosen to match the default mobile and desktop configurations in Lighthouse.

Each site was tested 7 times and the median run was picked based on the First Contentful Paint and Time to Interactive metrics.

To ensure consistent measurements, and to avoid ending tests prematurely, the default Lighthouse network idle and CPU idle timeouts were increased from 5s to 10s.

Takeaways for site builder developers

There are a few lessons that can be drawn from this post:

  • avoid render-blocking request chains of more than 2 requests (e.g. using @import in your CSS)
  • when rendering the page on the server, make sure that above-the-fold images are included
  • avoid re-rendering the page using large JavaScript apps

More metrics

This table includes additional performance metrics for each website builder.

You can also find full, up to date performance results in the DebugBear project I used to run these tests.

Site Builder Score #Req CLS TBT Size JS CSS HTML
Versoly8010069 ms453 KB43.1 KB36.1 KB2.15 KB
Webflow77290.03130 ms671 KB54.1 KB14.4 KB2.27 KB
Wix72660.01252 ms759 KB484 KB1.38 KB102 KB
Site12367250802 ms558 KB253 KB62.2 KB8.96 KB
GoDaddy631480.1707 ms783 KB484 KB6.02 KB14.1 KB
Jimdo58160389 ms517 KB267 KB71.4 KB5.93 KB
Yola54240.011.40 s615 KB164 KB6.85 KB8.51 KB
Webnode48290514 ms855 KB148 KB57.0 KB9.68 KB
Weebly39390.02676 ms996 KB429 KB43.2 KB6.68 KB
Wordpress.com343550.011.64 s878 KB197 KB84.0 KB67.7 KB
Strikingly325207.28 s2.32 MB1.80 MB76.5 KB29.9 KB
SquareSpace31150.051.91 s994 KB610 KB72.9 KB18.5 KB
Weblium232101.83 s1.14 MB839 KB199 KB37.2 KB
UCraft18340.126.21 s3.29 MB1.35 MB196 KB20.7 KB

#Req Number of network requests
CLS Cumulative Layout Shift
TBT Total Blocking Time
Sizes Overall page weight and page weight for each resource type

What makes sites built with website builders slow?

Unlike custom-built websites, website builders face a special problem: their developers don't know what the final page will look like. It might be a simple static website with a contact form. Or there might be a blog or a store, or both.

Because many layout elements need to be supported a lot of unnecessary code is loaded. While ideally only the necessary modules should be loaded, this requires more architecture work for the makers of the website builder.

Adding to this each page element needs to be renderable in the site editor, and it's not always easy to split out the editor code from the code for the published site.

Get a monthly email with page speed tips