Who this is for. Content modellers and theme developers who design component libraries. Afterwards you can estimate what a component tree costs, count it on a real page, and choose between flattening it and remodelling the content.

A page composed from components inside components is how editors get flexibility without asking a developer. It is also the most expensive way to render a page, and the cost is easy to underestimate, because each component on its own is cheap.

What one component costs

Rendering a component placed in a collection area does three things:

  1. Loads the component and its stored area values, the first time one of its areas is read.
  2. Finds its layout and renders that layout's template. On production the template is compiled once, but it is still a separate template run, with its own variables, for every component on the page.
  3. Repeats this for each of its own collections. A component with a collection area loads that collection's elements, and each element is a component that does all three steps again.

So the cost of a page grows with the number of components it renders, plus whatever each component's template does beyond reading its own areas (the nested-tree shape).

Depth multiplies

Depth matters because it multiplies. A section of three columns of four cards with two buttons each is 1 + 3 + 12 + 24 = 40 components; four such sections on a page are 160. No editor sets out to place 160 components, and nobody sees them as 160, because each is edited inside its parent.

Measured on this documentation site's development copy on 19 October 2026, from outside the server, three requests each: the home page, built from 80 components three levels deep, took 2.7 to 5.6 seconds to start answering; a guide page built from one component took 1.2 to 1.4 seconds. The two pages also use different templates, and a development environment inflates everything (development is not a benchmark), but most of the one-and-a-half-to-four-second difference is the components. On production the same work is several times faster, and it is still paid on every render.

It shows on a cached public page only on the renders that refill the cache. It shows on every request where there is no page cache to absorb it: member pages and anything that prevents caching. There, keep trees shallow from the start.

Counting a page's components

Count before you decide. Read the page through the REST API with its layout areas and count the entries that carry a componentLayout, level by level (Read a page with its sections and images in one request), or temporarily print a counter from the component templates on a development environment. Note the deepest path as well as the total: a tree four or more levels deep is usually a layout problem expressed as components.

Flattening options

  • Replace a wrapper with a setting. A "column" component whose only job is to hold cards can usually be a select area on the parent, such as a number of columns, which the parent's template renders as a grid. One level disappears and the editor makes the same choice.
  • Use plain areas for simple repetition. Two buttons on every card do not need to be two button components; two text areas and a link area on the card do the same job with no collection.
  • Use a global component for the repeated block. A call-to-action band that appears on many pages is one record rendered from one place, not a copy of the same subtree on every page (Components).
  • Resolve shared values once at the top, not in every component (resolve shared values once).
  • Keep component templates to their own areas. A component that queries, searches or loads a menu multiplies that work by the number of times it is placed.

When to question the design instead

Flattening helps when the tree is deeper than the content needs. It does not help when the page genuinely holds a lot of structured content. If a page is in effect a catalogue, a timetable or a directory built by hand from components, the content model is the problem: those are records, and they belong in a module or a custom entity with a listing template, where one query loads the whole list (Custom entities, Patterns, live preview and governance). Signs it is time:

  • editors copy the same component structure page after page and change only the text;
  • the same item appears on two pages and has to be edited twice;
  • someone asks to filter, sort or search what is in the components.