Razor and ViewComponents

By Optimizely Education
Published: Mar 10, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Hybrid role: Razor and ViewComponents serve as the high-performance in-process head for SSR and administrative previews.
Performance boost: Targeting .NET 10 leverages JIT improvements and tiered compilation to minimize DXP warm-up times.
Block standard: ViewComponents replace partials for block rendering, enabling asynchronous dependency injection and better isolation.
Headless bridge: Even in headless setups, a lightweight Razor engine often powers the editorial preview experience.

As Optimizely CMS 13 (PaaS) pushes further into the composable and headless era, a common question among enterprise developers is: Where do Razor and ViewComponents fit in a world dominated by APIs and React?

The answer lies in the Hybrid Delivery Model. While headless delivery is the future for multi-channel distribution, Razor and ViewComponents remain the primary tools for high-performance server-side rendering (SSR), administrative previews, and the in-process head of your DXP solution.

1. Razor: The Layout Foundation and .NET 10 Orchestration

In CMS 13, Razor (.cshtml) is not just an HTML template. It is the orchestrator of the request. When an in-process delivery head resolves a PageData object, the Razor engine is responsible for the final assembly of the DOM.

1.1 Performance Gains in .NET 10

By targeting .NET 10, Razor views in CMS 13 benefit from major Just-In-Time (JIT) compilation improvements. The tiered compilation and on-stack replacement features of .NET 10 ensure that frequently called views are optimized at the machine-code level, significantly reducing warm-up time for DXP App Service instances after deployment.

1.2 Where Razor Still Dominates

Global Layouts: Managing _Layout.cshtml, including foundational assets such as CSS and JavaScript, and global administrative hooks like <platform-navigation />.
Content-Heavy Marketing Sites: For SEO-critical pages where sub-second Time to First Byte (TTFB) is achieved through native ASP.NET Core caching.
Email Templates: Generating transactional emails where server-side logic is required before dispatching through services such as SendGrid.

2. ViewComponents: The Scalable Choice for Blocks

If Razor is the orchestrator, ViewComponents are the specialized performers. In legacy CMS versions, developers frequently used partial views for almost everything. In a scalable PaaS implementation, however, ViewComponents are now the standard choice for block rendering.

2.1 The Anatomy of a Block ViewComponent

Unlike partials, ViewComponents have a dedicated C# class using InvokeAsync, which allows asynchronous dependency injection and data preparation before the view is even touched.

public class HeroBlockComponent : BlockComponent<HeroBlock>
{
    private readonly IInventoryService _inventoryService;
    private readonly ILogger<HeroBlockComponent> _logger;

    public HeroBlockComponent(IInventoryService inventoryService, ILogger<HeroBlockComponent> logger)
    {
        _inventoryService = inventoryService;
        _logger = logger;
    }

    protected override async Task<IViewComponentResult> InvokeComponentAsync(HeroBlock currentContent)
    {
        _logger.LogInformation("Rendering Hero Block {Id}", currentContent.ContentLink.ID);

        // ViewComponents allow for async cross-service logic during block rendering
        var secondaryModel = await _inventoryService.GetPromoDataAsync(currentContent.CampaignId);
        
        var viewModel = new HeroViewModel(currentContent, secondaryModel);
        return View(viewModel);
    }
}

2.2 Why Developers Choose ViewComponents for Scale

Isolation: Blocks can be tested independently from the broader page context.
Performance: InvokeAsync supports modern async/await patterns, helping prevent thread starvation in the DXP App Service.
Encapsulation: Logical complexity can stay inside the component class, keeping the .cshtml files cleaner.

3. The Preview Page Paradigm in Headless Scenarios

For developers building headless remote websites, such as Next.js applications, Razor still plays an important role behind the scenes. In a modern DXP architecture, the CMS still needs a preview engine. Even if the live site does not use Razor, teams often build a lightweight Razor head specifically for the editorial interface so draft content can be rendered through standard templates. This hybrid approach helps preserve a stable editing experience while the production front end consumes JSON through Optimizely Graph.

4. Modernizing with Tag Helpers

CMS 13 emphasizes Tag Helpers over legacy HtmlHelpers. Tag Helpers provide a more HTML-like authoring experience and reduce the amount of embedded C# inside the view.

Property Helper: Attribute-driven tags provide better integration with modern frontend tooling.
Cloud Platform Navigation: Every CMS 13 PaaS site must use the <platform-navigation /> tag helper to maintain cross-product SSO consistency.

Conclusion

Razor and ViewComponents are far from obsolete in the CMS 13 era. They have simply shifted from being the only delivery path to being the high-performance, in-process specialized path. A strong PaaS implementation uses Razor views for overall site structure and SEO-critical rendering, while relying on ViewComponents for reusable blocks that require asynchronous logic or external service integration. Combined with .NET 10 performance gains and the move toward Tag Helpers, this approach keeps the rendering layer performant, testable, and well-suited to the wider composable Optimizely DXP ecosystem.