When a page contains more than 400 components, page editing
becomes harder. Lists displaying more than 500 teasers will break
the list and generate a server error.
When a website page contains a large number of components (over
400), editing in the author environment becomes significantly
slower. At 600 components, we have observed a great
performance loss for authors.
This will not produce a server error, but produces a terribly
slow authoring experience. (The experience for the site visitor to
published version will not be any worse than to a similarly long
page made of fewer components, though super-long pages are not best
practice in any case. The authoring slowdown will also be dependent
on their browser, and the technical capability (processor speed,
memory, etc.) of their computer.
There is also a fixed limit of the number of times a teaser can
be included in a page. This limit is somewhere between 400 and 500.
So, for example, with just one list component, if you make a list
that will actually try to list 500 teasers on one page, you will
trigger a server error and get an error page instead of your actual
We recommend authors do not put more than 400 components on each
page, and less if you need to plan for growth through any dynamic
We encourage you to follow best practice for website design by
breaking long or very complex pages into several smaller pages.
If a long page is mandatory, build the page as a series of
shared content blocks (maybe 100 components each), and then use a
Shared Reference components to splice them all together on the main
And for very long lists that display teasers (over 400 entries),
break the list into several pages, either manually, or with the