<p>Is this a problem with only the dashboard, or the front-end also? Although this is a bad answer, waiting a few seconds to load the dashboard shouldn't be a huge deal. You will only need to access it a few times while editing content. On the other hand, there are ways to improve the front-end performance such as <a href="https://docs.craftcms.com/v2/templating/eager-loading-elements.html" rel="nofollow noreferrer">Eager Loading</a>. </p>

<p>You can approach this conceptually by creating a simpler data model. In my opinion, super table inside of a matrix is a sign that you are doing something wrong. There is a reason that matrix in matrix is not supported, probably because of this performance issues like this.</p>

<p>You can also extend the dashboard or something to implement eager loading or cut down on db queries but I don't think it is worth the effort. Maybe you can mention something to Pixel and Tonic and they will improve this in a later version of craft.</p>

CC BY-SA 4.0
2018-06-07T17:02:22.443Z
Problem is only in the dashboard. I agree waiting a few seconds would not be a problem, but waiting 12-13 seconds for the browser to become responsive is too much.
LosHosez
CC BY-SA 4.0
2018-06-07T17:23:37.427Z
Then you might need to rethink how you are entering data. Especially since redactor is very powerful by itself.
Clark Nelson
CC BY-SA 4.0
2018-06-07T17:57:47.513Z
The problem is that creating a grid-like layout requires having two level system that Craft cannot do, which makes plugins like superTable really useful. How else would you add a container row, and a number of columns in to the row, if not by using matrix in matrix?
LosHosez
CC BY-SA 4.0
2018-06-07T18:07:02.160Z
allowing the full range of columns might be over kill. most websites will work with a full width, halves and third columns. I guess craft isn't really designed to work like this. You could give each block a width dropdown with 1-12 to specify num columns.
Clark Nelson
CC BY-SA 4.0
2018-06-08T10:09:21.310Z
Well it might be a bit overkill, but I also think I really need to have a container for the boxes/columns. What if I want to close the grid row after two 33% columns? With your setup the third 33% column would get added after the first two. Maybe a lightswitch "Begin a new row?" would do the trick, but this is troublesome to template when I have to keep track of Bootstrap's `<div class='row'>` and the closing `</div>`. I still would like to get some responses to my original question regarding the amount of db queries and page load time with that many Redactors loading at once.
LosHosez
CC BY-SA 4.0
2018-06-08T15:26:02.543Z
Unfortunately computers have a finite amount of resources. You can't throw a super complex matrix layout with embedded reactor fields (maybe 20-30 from what I can tell) and expect people's computers to be performant. This is not a craft problem, you are structuring the website wrong.
Clark Nelson
CC BY-SA 4.0
2018-06-11T11:25:47.593Z
I have created a different kind of matrix setup which works fine. I agree that the main problem was having so many Redactor-editors on the same page, however the amount of db queries was still a little bit alarming. We have a couple of websites built on top of Craft 2.6 where we were and still are experiencing problems with bad performance, and I would have just thought and hoped, that running Craft 3 solves all my problems. It appears it does not, but life goes on regardless :)
LosHosez
CC BY-SA 4.0
2018-06-07T16:41:33.697Z
2018-06-07T16:41:33.697Z
Clark Nelson
<p>I'm wondering what kind of performance I should expect from Craft 3's Control Panel.</p>

<p>I've created a (clever) structure, where I have matrix field which contains a superTable field.</p>

<ul>
<li>Matrix

<ul>
<li>Row (block type)

<ul>
<li>Column (superTable)

<ul>
<li>Style (dropdown)</li>
<li>Image (an asset)</li>
<li>Text (redactor)</li>
</ul></li>
</ul></li>
</ul></li>
</ul>

<p>The idea being that I can add rows, and inside the rows I can add a number of columns and fill the column with an image and/or text. From this I create a bootstrap grid.</p>

<p>Problem is that editing entries get really slow if and when the entry has larger amount of rows and columns. On the worst page I have 24 rows and loading the page makes 362 db queries and takes well over 10 seconds to load all redactor fields. This is way too slow to be usable.</p>

<p><img src="https://i.sstatic.net/LqWMV.png" alt="Control Panel debugger"></p>

<p><img src="https://i.sstatic.net/VbnOt.png" alt="Chrome debugger"></p>

<p>Then I started again from an empty page, which has fields for:</p>

<ul>
<li>title</li>
<li>categories</li>
<li>hero image</li>
<li>ingress/description</li>
<li>and a button to add rows</li>
</ul>

<p>An empty page creates 116 db queries. Every time I add a new row it adds 9 db queries. Every new column adds 3 db queries. So 10 new rows would create at least 90 new db queries, which is beginning to be problematic.</p>

<p>So is this the amount of db queries that I should expect, ie. is this normal? Is there something fundamentally wrong in the way I created the fields for the page using matrix and a superTable? What can I do to improve the performance?</p>

<p>(Running Craft 3.0.10.2 on Windows/IIS and MariaDB)</p>

CC BY-SA 4.0
2018-06-08T11:28:56.613Z
The amount of queries is normal. That's how these things work but I really doubt this is the critical point. You should take a look at your debug toolbar I expect the occurs on the client's side so the Javascript takes too long to initialize all the redactors
Robin Schambach
<craft3><redactor><plugin-supertable>
Craft 3 CP performance
# Craft 3 CP performance

(Asked by: username_0 on 2018-06-07)

I'm wondering what kind of performance I should expect from Craft 3's Control Panel.

I've created a (clever) structure, where I have matrix field which contains a superTable field.

* Matrix
  + Row (block type)
    - Column (superTable)
      * Style (dropdown)
      * Image (an asset)
      * Text (redactor)

The idea being that I can add rows, and inside the rows I can add a number of columns and fill the column with an image and/or text. From this I create a bootstrap grid.

Problem is that editing entries get really slow if and when the entry has larger amount of rows and columns. On the worst page I have 24 rows and loading the page makes 362 db queries and takes well over 10 seconds to load all redactor fields. This is way too slow to be usable.

![Control Panel debugger](https://i.sstatic.net/LqWMV.png)

![Chrome debugger](https://i.sstatic.net/VbnOt.png)

Then I started again from an empty page, which has fields for:

* title
* categories
* hero image
* ingress/description
* and a button to add rows

An empty page creates 116 db queries. Every time I add a new row it adds 9 db queries. Every new column adds 3 db queries. So 10 new rows would create at least 90 new db queries, which is beginning to be problematic.

So is this the amount of db queries that I should expect, ie. is this normal? Is there something fundamentally wrong in the way I created the fields for the page using matrix and a superTable? What can I do to improve the performance?

(Running Craft 3.0.10.2 on Windows/IIS and MariaDB)

**Tags:** craft3, redactor, plugin-supertable
> **Comments:**
> **username_1**: The amount of queries is normal. That's how these things work but I really doubt this is the critical point. You should take a look at your debug toolbar I expect the occurs on the client's side so the Javascript takes too long to initialize all the redactors  

---

## 1 answers

### Answer by username_2 on 2018-06-07. Score: 3

Is this a problem with only the dashboard, or the front-end also? Although this is a bad answer, waiting a few seconds to load the dashboard shouldn't be a huge deal. You will only need to access it a few times while editing content. On the other hand, there are ways to improve the front-end performance such as [Eager Loading](https://docs.craftcms.com/v2/templating/eager-loading-elements.html).

You can approach this conceptually by creating a simpler data model. In my opinion, super table inside of a matrix is a sign that you are doing something wrong. There is a reason that matrix in matrix is not supported, probably because of this performance issues like this.

You can also extend the dashboard or something to implement eager loading or cut down on db queries but I don't think it is worth the effort. Maybe you can mention something to Pixel and Tonic and they will improve this in a later version of craft.

> **Comments:**
> **username_0**: Problem is only in the dashboard. I agree waiting a few seconds would not be a problem, but waiting 12-13 seconds for the browser to become responsive is too much.  
> **username_2**: Then you might need to rethink how you are entering data. Especially since redactor is very powerful by itself.  
> **username_0**: The problem is that creating a grid-like layout requires having two level system that Craft cannot do, which makes plugins like superTable really useful. How else would you add a container row, and a number of columns in to the row, if not by using matrix in matrix?  
> **username_2**: allowing the full range of columns might be over kill. most websites will work with a full width, halves and third columns. I guess craft isn't really designed to work like this. You could give each block a width dropdown with 1-12 to specify num columns.  
> **username_0**: Well it might be a bit overkill, but I also think I really need to have a container for the boxes/columns. What if I want to close the grid row after two 33% columns? With your setup the third 33% column would get added after the first two. Maybe a lightswitch "Begin a new row?" would do the trick, but this is troublesome to template when I have to keep track of Bootstrap's `<div class='row'>` and the closing `</div>`. I still would like to get some responses to my original question regarding the amount of db queries and page load time with that many Redactors loading at once.  
> **username_2**: Unfortunately computers have a finite amount of resources. You can't throw a super complex matrix layout with embedded reactor fields (maybe 20-30 from what I can tell) and expect people's computers to be performant. This is not a craft problem, you are structuring the website wrong.  
> **username_0**: I have created a different kind of matrix setup which works fine. I agree that the main problem was having so many Redactor-editors on the same page, however the amount of db queries was still a little bit alarming. We have a couple of websites built on top of Craft 2.6 where we were and still are experiencing problems with bad performance, and I would have just thought and hoped, that running Craft 3 solves all my problems. It appears it does not, but life goes on regardless :)  

---

