Website builder performance comparison
I created a similar website in 11 different website builders and analyzed 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.2s | 3.3s | 5.1s | 3.3s | 0.9s | 0.6MB | 0.1MB |
| Wordpress.com | 64 | 93 | 91 | 100 | 4.0s | 4.0s | 6.5s | 4.1s | 0.5s | 0.5MB | 85KB |
| Weblium | 61 | 93 | 81 | 90 | 2.5s | 2.5s | 7.9s | 5.5s | 1.1s | 0.3MB | 0.3MB |
| GoDaddy | 54 | 86 | 81 | 90 | 5.0s | 5.0s | 5.7s | 5.5s | 0.6s | 0.3MB | 0.3MB |
| Site123 | 52 | 86 | 69 | 91 | 4.4s | 5.0s | 6.6s | 5.5s | 0.6s | 0.7MB | 0.3MB |
| Strikingly | 51 | 57 | 69 | 91 | 1.2s | 1.2s | 4.7s | 13s | 2.0s | 1.8MB | 1.2MB |
| Jimdo | 46 | 86 | 73 | 91 | 5.4s | 5.4s | 7.5s | 5.4s | 0.4s | 0.4MB | 0.2MB |
| Webnode | 46 | 86 | 100 | 100 | 5.7s | 5.7s | 6.7s | 5.7s | 0.7s | 0.8MB | 0.1MB |
| Weebly | 44 | 71 | 84 | 90 | 4.8s | 4.8s | 8.0s | 6.0s | 1.2s | 1.1MB | 0.4MB |
| Squarespace | 41 | 93 | 77 | 91 | 5.7s | 5.7s | 8.6s | 5.7s | 0.8s | 1.0MB | 0.4MB |
| Wix | 32 | 86 | 74 | 91 | 4.3s | 4.3s | 5.3s | 13s | 2.8s | 1.6MB | 1.1MB |
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!