CMS Architecture 101: Static Pages vs. Component Pages

If you’ve ever had to work with a Content Management System (CMS) to build your web presence, one thing you may have been asked by those building it is “How many pages will be static vs component based?” 

Chances are, if you’re not an expert-level CMS developer you weren’t sure how to answer. Sometimes developers forget that people outside of our world aren’t as well-versed in our terminology as we are. You probably found yourself wondering: So what exactly does this question even mean? Why is it being asked? Is one better than the other?

To start with, this is referring to the two main ways you can build your site in most CMS platforms. More specifically, it’s about how those who will be entering and updating content on your site will be doing it and how much control they have over pages. 

Static Pages

A static page, despite its name, doesn’t actually mean that the content can’t be changed at all, just that what can be changed is more limited. 

For a static page, the various parts on the page are set during design and don’t change. The specific content in those parts can but the parts don’t. When editing, you’re just given form fields to change the content in specific parts of the page. 

For example,  you may have a simple page with a hero image, a page tile, some text content, and a button for navigating to another page that looks something like this: 

When editing that page, you’d be able to change those items and those items only. If you wanted to add a second image to the page, or add a callout area below the paragraph, or add more buttons, you would not be able to do so. 

Simply put, you can change what’s in the components that are already on the page, but you can’t add or remove the components of the page itself. 

Component Pages

With a component-based approach to the page, you have more flexibility and control over the content of the page. Instead of five fields to work with when editing as in the previous example, you’d have a larger editor that would allow you to select components from a library and add, relocate, or remove them from the page itself. You can edit the content of those components, and the components on the page itself. 

So if you wanted to add a second image or a new callout area, you could. There is a limit, however, as the components have to exist within your component library. If you suddenly decided to add an accordion to your site when it never had one before, it’s probably not in your component library and you’d not be able to do so. 

Why is this being asked? 

Because it directly relates to the effort required by developers to build your site. Static pages are (generally speaking) “quicker.” They can be put together by developers and set up with only the content that needs to be editable present. 

Component-based pages will take somewhat longer to build, as rather than just building the page to match the design, these pieces have to be “componentized” and made to be reusable. 

This also affects your design time. With static pages, the design of a page can be more bespoke and you can have items vary according to how you want each page to look. With component pages, your design needs to be more generic. The way an accordion looks and works on one page needs to be the same as it does on any other page. The content can vary, but the look, feel, and functionality need to be common between them so you don’t end up with multiple versions of the same component for trivial details (this is known in the biz as “gold plating”). 

So limiting the amount of component vs. static pages in your site can speed up the time required to build it.  

Which is Better: Static or component site pages? 

As with most things, the answer is “it depends”. 

For the most part, your site doesn’t need all of one or the other. Pages that shouldn’t need to change much in the future should be static. Ones that you need more control over should be component based. 

Use a static page when: 

• The site is simple with only a few items on it. 
• The content on it should rarely change. 
• You need a quick time to market. 
• You want to restrict content authors to a specific format or layout. 

Use a component-based page when:

• The page content will change frequently (but not via an integration, i.e. product pages).
• You want to allow content authors more control over what is on the page, including its layout.  

Why don’t we just make all pages component based? 

You could, but the main barrier is the increased time and cost to do so. And after that, there are still a few things to consider. Component-based pages are definitely more flexible for a Content Manager, but they can come with a few caveats: 

• Depending on the CMS platform, they may take slightly longer to load. This isn’t true of all CMS platforms but is of some. Though there are ways of remediating this, however (typically static site generators). 
• A component-based page is more effort to maintain. Instead of just form field entry, you have a more complicated editor (which can take longer to learn and get used to as well). 
• Consistency across your content entry team can be an issue. After a designer has spent a decent amount of effort crafting the designs and layouts of your pages, having others come in and be able to modify the layout and flow of the site can undo what the designer put all that effort into. 
• They can be more prone to “accidents.” With static pages, content editors can’t remove items on the page, only change the content in those items via simple fields. With a component-based page, editors can remove entire components from the site. With a good CMS platform, this shouldn’t be a major problem, as you would be able to revert the changes or catch the mistake via a content review workflow, but it is one more thing to watch out for. 

The Main Takeaways

Overall, neither option here is inherently better than the other. As with most things, it's about using the right tool for the job. For most basic pages, a static-type page will serve just fine. When you want more control over the layout, then using a component-type page will give you that. It’s best to think about what your goals and update plan will be for your pages, and from that to strategically use component pages, with static pages filling in the rest. 

You don't have to figure out your site's architecture alone. Get in touch with CID and let our developers & UX designers help!