Answers.Body: <p>This turned out to be a badly performing custom element source criteria being loaded on the EVENT_REGISTER_SOURCES event. The query was causing render blocking when loading entries. Entries using matrix fields seems to have the worst performance. Making the criteria more performant allows things to load quicker. It was a bit of a misleading trace, but looking at the DB query profiling more closely identified it. This was being called in a custom module. After removing this module from the bootstrap in the app.php, things loaded much quicker so it narrowed it down to then troubleshoot. A good lesson for the future.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-07T21:25:52.373Z
Answers.LastActivityDate: 2022-07-07T21:25:52.373Z
Answers.UserDisplayName: James White
Body: <p>From a recently migrated Craft CMS 2 site, there are various entries in the Control Panel which take a very long time to load (sometimes over 30 seconds). This is the same in our production environment with debugging off, so it is not overhead from dev mode. Testing on the old Craft CMS 2 site with entries that exist in both, this is not happening.</p>
  <p>Profiling with Yii Toolbar I can see that it's clearly showing rendering the matrix field in the Control Panel is taking up a sizable amount of the request. This is also consistent with testing other entries which do not feature this field and load much quicker. Removing this field is obviously not an option because it provides many matrix blocks for entry content.</p>
  <p>The front end is fine and does not have issues loading entries which take a very long time to load in the Control Panel.</p>
  <p>I cannot see any DB query that's causing such a long load time but any pointers on digging into this issue would be appreciated. Something is clearly hanging the render template call, but again this is limited to the Control Panel and not front end.</p>
  <p>The site is running Craft CMS 3.7.46.</p>
  <p><a href="https://i.sstatic.net/WDkuw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/WDkuw.png" alt="enter image description here" /></a></p>
  
Tags: <templating><matrix><debug>
Title: Debugging slow loading entries with matrix field in Control Panel
ThreadText: # Debugging slow loading entries with matrix field in Control Panel
  
  (Asked by: username_0 on 2022-07-04)
  
  From a recently migrated Craft CMS 2 site, there are various entries in the Control Panel which take a very long time to load (sometimes over 30 seconds). This is the same in our production environment with debugging off, so it is not overhead from dev mode. Testing on the old Craft CMS 2 site with entries that exist in both, this is not happening.
  
  Profiling with Yii Toolbar I can see that it's clearly showing rendering the matrix field in the Control Panel is taking up a sizable amount of the request. This is also consistent with testing other entries which do not feature this field and load much quicker. Removing this field is obviously not an option because it provides many matrix blocks for entry content.
  
  The front end is fine and does not have issues loading entries which take a very long time to load in the Control Panel.
  
  I cannot see any DB query that's causing such a long load time but any pointers on digging into this issue would be appreciated. Something is clearly hanging the render template call, but again this is limited to the Control Panel and not front end.
  
  The site is running Craft CMS 3.7.46.
  
  [![enter image description here](https://i.sstatic.net/WDkuw.png)](https://i.sstatic.net/WDkuw.png)
  
  **Tags:** templating, matrix, debug
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2022-07-07. Score: 0 | Accepted answer
  
  This turned out to be a badly performing custom element source criteria being loaded on the EVENT\_REGISTER\_SOURCES event. The query was causing render blocking when loading entries. Entries using matrix fields seems to have the worst performance. Making the criteria more performant allows things to load quicker. It was a bit of a misleading trace, but looking at the DB query profiling more closely identified it. This was being called in a custom module. After removing this module from the bootstrap in the app.php, things loaded much quicker so it narrowed it down to then troubleshoot. A good lesson for the future.
  
  
  ---
  
  