Rendering Choices

By Optimizely Education
Published: Feb 9, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Razor Pages: Full-page templates when logic is page-focused.
MVC controllers + views: Page rendering with orchestration and explicit actions.
ViewComponents: Reusable server-rendered components with encapsulated logic.
Blocks: Editor-composable content pieces (rendered via partials or ViewComponents).
Opal widgets: UI inside the CMS editor surface (not public site rendering).

Overview

Optimizely CMS 12 (PaaS) supports multiple rendering choices for developer-built UI and content presentation. Each option has trade-offs in scope, reusability, complexity, and where it runs (public website vs CMS UI).

Decision guide

Where does this UI run? Public site (Razor/MVC/blocks/ViewComponents) vs CMS editor/admin UI (Opal widgets).
Is it a full page route or a piece inside a page? Full page = page template. Inside a page = block/partial/ViewComponent.
Do you need server-side logic for the piece? If yes, prefer a ViewComponent. If no, a partial/DisplayTemplate may be enough.
Does an editor need to reuse/compose it? If yes, model it as a block, then choose how to render it.

Rule of thumb

Pick the simplest option that fits the job. Complexity is not a flex, it's a recurring subscription.

Rendering options

This section explains what each option is, when to choose it, and the typical drawbacks in CMS 12 PaaS.

Razor Pages

When to choose:

When the template behaves like a full standalone page handler.
When you want convention-driven page rendering with minimal boilerplate.

What it is:

A Razor Page is a .cshtml file with an associated .cshtml.cs page model. CMS 12 can treat this as a template and bind routed content accordingly.

// Sample Razor Page Model
public class ExamplePageModel : RazorPageModel<ExampleContent>
{
    public void OnGet()
    {
        // Page logic
    }
}

Drawbacks:

Not ideal for reusable pieces that compose into larger pages.
Not designed for block rendering inside a ContentArea.

MVC controllers + views

When to choose:

When page rendering needs orchestration (build view models, load related content, handle variations).
When you want clear separation of concerns (controller logic vs view markup).
When you reuse controller behavior across page types (base controller patterns).

public class StandardPageController : PageController<StandardPage>
{
    public IActionResult Index(StandardPage currentPage)
    {
        return View(currentPage);
    }
}

Drawbacks:

More boilerplate than Razor Pages.
Can be overkill for very simple templates.

ViewComponents

When to choose:

When rendering reusable components or blocks with logic.
When you need clean encapsulation of rendering logic that runs inside pages.

In CMS 12:

Blocks often render through ViewComponents. If a block needs logic (for example, load related content), a ViewComponent is the right tool.

public class TeaserBlockViewComponent : BlockComponent<TeaserBlock>
{
    protected override IViewComponentResult InvokeComponent(TeaserBlock currentBlock)
    {
        return View(currentBlock);
    }
}

Drawbacks:

Slightly more setup than a simple partial view.
If there is no logic, a partial/DisplayTemplate may be simpler.

Blocks

When to choose:

When editors need reusable pieces that can be composed into pages.
When working with ContentArea and editorial page assembly.

What blocks are:

Blocks are smaller content types (often inheriting from BlockData) that render inside pages. They are content models, not standalone pages.

Rendering blocks

Partial view / DisplayTemplate: Best when you only need markup + simple formatting.
ViewComponent: Best when you need logic to load/compute/build a view model.

Important distinction:

Block type: Content definition.
Block rendering: Presentation choice (partial/DisplayTemplate vs ViewComponent).

Opal widgets

When to choose:

When you need custom UI inside the CMS editor/admin interface.
Not for public-facing website rendering.

What Opal widgets are:

Opal widgets extend the CMS UI: panels, dashboard tools, workflow helpers, or custom editing experiences. They run inside the editor surface, not on the public site.

Do not mix these up

Blocks + Razor/MVC/ViewComponents render the public website. Opal widgets enhance the CMS editor/admin experience.

How to choose among these

1. Public website rendering

Use Razor Pages for simple page templates with page-focused logic.
Use MVC controllers + views for complex orchestration and explicit control.
Use ViewComponents for reusable UI segments with logic.
Use Blocks when editors need composable, reusable content pieces.

2. CMS editor/admin UI

Use Opal widgets when enhancing CMS screens and editor productivity.

Conclusion

The right choice depends on scope (page vs component), whether rendering needs logic, how much reuse you need, and whether the UI lives on the public site or inside the CMS editor. Keep it simple: page templates for pages, blocks for editorial composition, ViewComponents for logic-driven pieces, and Opal widgets only for CMS UI extensions.