See the following discussions:
I think you need to approach the site structure a little bit differently, because that many subpages (articles) per page (blog) is just very much for a file-based system in general (not just for the Panel).
The rule of thumb for Kirby subpage performance is: If you know that a page will have very many subpages (how many depends on the site, server and type of page) and you can restructure the content so that the many pages are split up into multiple containers, do that.
Example for your use-ca…
Has anyone built a big site with a few thousand pages? If my testing with Kirby 2.1 goes well I will use it on big projects.
Let’s say I have this:
10 000 item pages
Tags or categories to every page
List pages by a tag for example /books
Pagination with 20 pages per page
20 fields per item page
The item pages will remove and add 20 item pages each day
Questions
Kirby needs to go through all 10 000 item pages to find out which pages uses what tags, right? How fast / slow is that? Any tests?…
I could find a couple of things on Kirby’s performance in the forum. Too many subpages is not a good idea. But I couldn’t find anything on the amount of files a page can have. Are too many files for a page a bottleneck? And does the size of the original files matter for directory reading performance? Let’s say an unoptimized image is uploaded and weighs in 1.5MB, does that impact performance compared to an optimized 350kb version for instance.
Conclusion: It depends on your site. What I recommend is to create as many pages as you expect using a script and check if the site is slower afterwards. Nothing better than a realistic benchmark of your own site.
1 Like
