Epic #88474

Page tree performance in 9.5

Added by Tymoteusz Motylewski 6 months ago. Updated 10 days ago.

Should have
Target version:
Start date:
Due date:
% Done:


Sprint Focus:
On Location Sprint


The new page tree delivered in v.9.5 has performance issues with bigger instalations e.g. 100k pages
Because of processing the whole page tree in one go.
We should make it possible to fetch one page tree level at once and process only these pages on PHP side.

For the discussion please join the slack channel




Bug #86945: Performance PageTree in WorkspaceResolvedAlexander Opitz

Bug #88097: Page tree data fetching is using a huge amount of memory in PHPNew

Bug #88098: Page tree XHR is fetching huge JSON dataUnder Review

Bug #88943: Pagetree taking extremely long to load for editorsUnder Review

Bug #89687: Page tree sends unnecessary dataResolved


#1 Updated by Wolfangel Cyril 6 months ago

Two idéas :

If i remember well, the 4.5 -> 6.2 team already addressed a similar issue and worked on the pagetree performance. It's probably a regression.

Other thing, maybe we could remove the loading animation would immediatly solve the bug as the 7.X version is doing the action in the background and nobody complained ?

#2 Updated by Johannes Wagner 6 months ago

I have a large and deeply nested page tree. I want to install it in Typo9.5.

You could build the page tree asynchronously as in the previous Typo3 version. There, my page tree is quickly set up using the getNextTreeLevel method.

related question: https://stackoverflow.com/questions/56628254/how-can-the-typo3-backend-page-tree-be-constructed-asynchronously-in-typo3-v9-x

#3 Updated by Tymoteusz Motylewski 6 months ago

  • Description updated (diff)

#4 Updated by Tymoteusz Motylewski 6 months ago

  • Description updated (diff)

#5 Updated by Sybille Peters 3 months ago

  • Sprint Focus set to On Location Sprint

Issues with performance for pagetree can be reproduced with less than 100 000 pages. Of course, this depends on resources used. But a page tree of about 25 000 pages can make backend pretty unmanageable requiring several seconds wait time after inserting a new page, changing the page title or just logging in and trying to access the page tree.

I tested this with an initial 9.5.9 installation with Introduction Package where about 23 000 pages were added (recursively).

A lot of time is spent in here:


foreach ($entryPoints as $page) {
  $items = array_merge($items, $this->pagesToFlatArray($page, (int)$page['uid']));


or specifically in the pagesToFlatArray function.

The items array is filled for all existing pages.

Loading the pages asynchronously would help a lot. If most parts of the page tree are collapsed, the page information is not really required (yet).

It also seems that costly operations are performed for minor changes, e.g. changing the page title of one page and saving.

#6 Updated by Christian Eßl 2 months ago

  • Category set to Pagetree

Also available in: Atom PDF