Performance on index collections

I have been looking to similar threads and haven’t found informations about performance when using page collections when handling many subpages.

I have gotten the impression when having one page with many subpages ( e.g. a blog ) after several hundreds or thousands of subpages it will get slower. That’s why the idea usually is to split them into more subfolders even further.

But does that change anything when calling that page in page('blog')->index() ?
Blog is just an example. My use case would be getting an increment number overall my subpages are sorted by dates, but it would still have to go though the index to sort though…


this would get the last “number” but what does it look like performance wise? Does that handle all subpages or taking a shorter route so even if i had 10.000 subpages to be quite efficient?

Otherwise my approach would look very diffrent. E.g. parent date folders will have to created if not existing plus getting the last visible number.

If you have to do this a lot, you might consider using a database for indexing.

1 Like

it’s not called every time, just when a user goes though this kind of process it’ll happen once.
the question for me is just for each call, if 10000 shared among several subpagess are much slower vs 10000 pages within the same child page

Interesting question. But if you really have to go through all pages, no matter if they are all in one or in several subpages, I assume it would probably amount to the same. I think the idea of splitting content up into subfolders would be to reduce the amount of pages that Kirby would have to search through.

On a fast server with SSD drive and if you make use of caching, the result of searching through 10,000 pages should still be quite fast.

actually i wouldn’t have to get though EVERY subpage… any way possible getting the page which has the biggest number on ‘number’ field is fine.

While everything is generated automatically it’s possible that some subfolder (in case of year/date separation) is not existing.

But in my case it’s not always the case, that the latest visible page has the biggest ‘number’ otherwise i’d just go though and get the last visible…