There's no limit to how many articles you can create so not sure why making sublists would be any different from say 100 unrelated pages tbh.

But there are no unnecessary parts. Basically, before I got there they just created a single page with 70 tabber pages that are all essentially pages of their own lol. It's all fanon-based stuff related to the wiki so they kept in all on one single page. Eventually, each thing is going on its own article in a new fanon namespace, but I don't time the time nor will to deal with it at the present, so I just want to make it load properly for the time being. I will try doing 3 lists then if around 70k is where pages start loading slowly. Thanks!

Making too much pages can lead others users to for exemple, not finding certains informations.

Well, specifically what we're dealing with is users made up fanon types related to the wiki and they can add examples and stuff. I'm thinking about making a Characters (A-H), Characters (H-P), and Characters (Q-Z)

You choose!

Yes but I want to know what the recommended size limit is lol

Can you share the link of the big page?

I already split it into multiple pages. Really it's just a general question but it doesn't seem like anybody knows.

👆🏼̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶a̶n̶ ̶A̶I̶ ̶r̶e̶p̶l̶y̶.̶

EDIT: AI reply was deleted.

At a certain point, syntax highlighting just becomes too slow to be able to keep up with page size, but if you disable syntax highlighting then you could probably go to the maximum size limit with zero noticeable slowdown. Optimal performance will depend on the size and complexity of the page, as well as your own computer and even how you edit your page (e.g. writing a paragraph is fine, but adding a line can take a few seconds on a long page).

A rough estimate I can give is 75,000 bytes based on a page on my local wiki where updates may take a few seconds but it's still generally responsive enough, using the 2010 wikitext editor with syntax highlighting. Usually with big pages either they're simple enough to edit without syntax highlighting, or I instead edit them in VSCode.

Interesting. So it's the syntax highlighting that causes all that lag. That's really good advice to know for when I edit these types of pages again in the future.

Getting this big page down into 3 of 70,000 bytes really seemed to help. There's only one other page on the wiki over that at 110,000 bytes so I might try to trim that a bit too then. Thanks!