Improve blocks performance#325

We follow the site builder pattern and have dozens of blocks (28 currently) which the user can use to build their pages:

type: blocks
pretty: true
fieldsets:
  - faq
  - usp
  - logos
  ...

However, we noticed that the panel got increasingly slower. The AJAX request in the panel for the content section (/api/pages/home/sections/content-col-0-fields) takes over 2 seconds. The /validate routes are also slow. When you click “Save” to update the page, it takes over 3 seconds.

I know that we’re going heavy on those blocks, but I measured the performance impact of reading the YAML contents of each file and parsing them and it’s ~0.2 seconds. It seems that the bigger part of the problem comes from Kirby’s logic.

Perhaps there’s a way to only read/parse/load only the blocks that are currently used on the page?

I can’t confirm that, we have 37 blocks and both, the first load and the save is very fast. Even on pages where multiple layouts and 50 or more blocks are already in the content, the loading process is extremely fast.

@Oliver.mayer are you talking about 37 block instances or block types? In other words, do you have 37 YAML blueprints, or fewer blocks with multiple occurrences on a single page?

@Hristiyan Dodov We had 37 different block types. But for test cases, we also have a page where we have 50+ instances at one page. This is because we had extreme performance problems with the old builder plugin and therefore we did several tests with the new one.

I had discussions with Bastian about the speed of the builder in a pre-release version, where we had load times of almost 10 seconds on the first pageload.

But since the builder was rebuilt from scratch our speed problems are completely solved to be honest.

I don’t have a problem with number of block types, but there is a big problem when you add more than 10 blocks on the page. It is terribly slow. Sometimes I have to wait for 10 seconds to save the page. This didn’t happend with Page Builder plugin.

@Branko Matić Issues with 10 blocks already? What types of blocks are we talking here? How many block types do you use on a single page type? And @Hristiyan Dodov & @Oliver.mayer You are both talking about offering 30 block types in a single page blueprint to choose from, right?

As mentioned above, we sometimes have 50 or more on a page. Is there possibly a pattern? For example, very many of type headline or similar?

I just counted on my demo page, 54 blocks in more than 15 layouts. Each block has an individual Vue.js preview. Loading time at save < 1.5 seconds.

We had really big problems with the pagebuilder Plugin about performance, but now with the redesign they are all gone.

Edit: a test installation would help, can you provide one? Maybe it’s the server or the blueprint setup?

@Oliver.mayer But there you are talking about block instances, not block types. But in single page blueprint you define 30+ different block types? How complex are those block types?

@Info Exactly! And the interesting thing is that the blocks are ultra complex. Each block type has at least 15 options that are inserted by an extend.

In addition, many more options are added by the actual block. Also numerous conditional fields are built in. An example in the appendix how many fields there are in some blocks.

I’ve made a reproduction repo here. It appears that the issue comes from a combination of block types and block instances. If just have a lot of block types, but just one instance on the page - the performance seems okay. In the repo, there are 50 custom blocks and 50 instances in a single page, which significantly slows the panel.

It also takes about 2.5 seconds to load for me. But I personally find it ok, there are 50 different blocks that are completely filled with content.

Hi, @Hristiyan Dodov , @Info , @Oliver.mayer
I have made some tests, in my case there are several blocks with structure field and nested blocks. That’s what is making it slow.

my idea on how to speed it up: https://kirby.nolt.io/328