Website builder performance comparison

Update: In November 2020 I published an updated version of this comparison.

I created a similar website in 11 different website builders and tested each site with Lighthouse.

Metric	Description
Perf, BP, A11Y, SEO	Lighthouse scores for Performance, Best Practices, Accessibility, and SEO
FCP, FMP, SI, TTI	Load timings for First Contentful Paint, First Meaningful paint, Speed Index, and Time to Interactive
CPU	Total CPU usage during page load
Page Size, JS Size	Total page download weight and download weight of JavaScript code.

Name	Perf	BP	A11Y	SEO	FCP	FMP	SI	TTI	CPU	Page Size	JS Size
Yola	79	79	69	90	3.2 s	3.3 s	5.1 s	3.3 s	0.9 s	0.6 MB	0.1 MB
Wordpress.com	64	93	91	100	4.0 s	4.0 s	6.5 s	4.1 s	0.5 s	0.5 MB	85 KB
Weblium	61	93	81	90	2.5 s	2.5 s	7.9 s	5.5 s	1.1 s	0.3 MB	0.3 MB
GoDaddy	54	86	81	90	5.0 s	5.0 s	5.7 s	5.5 s	0.6 s	0.3 MB	0.3 MB
Site123	52	86	69	91	4.4 s	5.0 s	6.6 s	5.5 s	0.6 s	0.7 MB	0.3 MB
Strikingly	51	57	69	91	1.2 s	1.2 s	4.7 s	13 s	2.0 s	1.8 MB	1.2 MB
Jimdo	46	86	73	91	5.4 s	5.4 s	7.5 s	5.4 s	0.4 s	0.4 MB	0.2 MB
Webnode	46	86	100	100	5.7 s	5.7 s	6.7 s	5.7 s	0.7 s	0.8 MB	0.1 MB
Weebly	44	71	84	90	4.8 s	4.8 s	8.0 s	6.0 s	1.2 s	1.1 MB	0.4 MB
Squarespace	41	93	77	91	5.7 s	5.7 s	8.6 s	5.7 s	0.8 s	1.0 MB	0.4 MB
Wix	32	86	74	91	4.3 s	4.3 s	5.3 s	13 s	2.8 s	1.6 MB	1.1 MB

Interpreting the table

First of all, note that the table above is sorted by the Lighthouse performance score. Lighthouse heavily penalizes JavaScript execution, and Time to Interactive is the metric with the greatest impact on the performance score. Accordingly, sites that load and run a lot of JavaScript code do more poorly in this test.

However it's worth considering some other metrics. For example, the First Contentful Paint indicates when the user first starts seeing content. Speed Index indicates how long it takes for the page to become mostly visually stable.

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.

Ensuring a quick first contentful paint

The first contenful paint happens after loading the initial page document when there are no more render-blocking elements. For example, a script tag or a stylesheet can delay the first contentful paint.

In order to achieve faster paint times there should be as few render-blocking elements as possible. Ideally the initial document request contains all the necessary styles for the initial render. If that's not possible, avoid long cascades of requests that depend on each other, and avoid extra network roundtrips.

Monitoring the performance of your website

I'm building a website monitoring tool called DebugBear, it's what I used to collect the data for this analysis. It regularly loads your website, tracks Lighthouse scores and performance metrics, and then presents the results in a way that allows you to take action. Give it a try!