[USPC] Ultimate Sitecore Performance Championship: View Rendering vs Controller Rendering

And ladies and gentlemen, we are LIVE! Here we are for Fight 2 on this series. If you missed the first one USPC: GetChildren() vs Axes.GetDescendants() make sure you read it since the final result was pretty impressive.

I’m pretty sure that if you are reading this you already know when you should use a view rendering or a controller rendering. View rendering for the simple, controller rendering for the complex.

It’s pretty clear why you can’t use a view rendering for complex… But what about using a controller rendering for a very simple and basic scenario? Is it legit?

We often say that for simple scenarios view renderings are faster, but how much faster they really are? What if controller renderings are actually faster and we keep asking ourselves this question for no reason? My goal here is to answer precisely all those questions using numbers and metrics.

By the way, you can find all the code used to do this blog post on my GitHub account. Feel free to reach me out on Slack or Twitter if you have any question about it.

On The Red Corner… The View Rendering!

The first contender of this evening is the View rendering! He has a very basic and solid game, so doing crazy and fancy things are not his thing. At the same time, it is very known for being the best on what it does. Let’s not underestimate this big boy!

To keep this test fair and consistent, I decided to remove everything that is not totally necessary. So forget about Glass mapper or any other ORM. I want it to be as faster as it can be. For this, here is the code we are using:

using System.Web;
using Sitecore.Mvc.Presentation;
using Sitecore.Web.UI.WebControls;

namespace Coveoticore.Website.Models
{
    public class USPCModel : RenderingModel
    {
        public HtmlString SingleLineText => new HtmlString(FieldRenderer.Render(Item, "SingleLineText"));

        public HtmlString MultiLineText => new HtmlString(FieldRenderer.Render(Item, "MultiLineText"));

        public HtmlString DateTime => new HtmlString(FieldRenderer.Render(Item, "DateTime"));

        public HtmlString Number => new HtmlString(FieldRenderer.Render(Item, "Number"));

        public HtmlString Image => new HtmlString(FieldRenderer.Render(Item, "Image"));
    }
}

@model Coveoticore.Website.Models.USPCModel
@{
    if (Model != null)
    {
        
@Model.SingleLineText"
        
@Model.MultiLineText"
        
@Model.DateTime"
        
@Model.Number"
        
@Model.Image"
    }
}

On The Blue Corner… The Controller Rendering!

Our second contender of this fight is the most popular one, the one and only Controller rendering! This fighter is the opposite of the first one, his strength lays on his versatility and flexibility. You can do pretty much everything you want using it, even if it is known for being a little bit slower than his adversary. That’s what they say, at least…

To keep consistency, we are keeping it as simple as possible as well. Basically, it will only call the RenderingModel.Initialize(Rendering) method which is exactly the same method called by the mvc.getModel pipeline used to populate the model when using a view rendering.

using System.Web.Mvc;
using Coveoticore.Website.Models;
using Sitecore.Mvc.Presentation;

namespace Coveoticore.Website.Controllers
{
    public class CoveoticoreController : Controller
    {
        public ActionResult USPC()
        {
            var model = new USPCModel();
            model.Initialize(RenderingContext.CurrentOrNull.Rendering);
            return View(model);
        }
    }
}

First Round: Cache Enabled

We are going to run a series of tests on both contenders, each one using two different scenarios.

The first one is opening a page with 10 view renderings using 10 different data sources. Let’s see what we get:

The result is pretty surprising. Both contenders have pretty much the same performance, with a tiny advantage for the controller rendering. But honestly, it was so close that I’m going to declare it a draw.

What if we create a more extreme scenario on which a page has 100 different renderings using 100 different data sources?

On this scenario, it looks like the view rendering has a better performance. The difference is not that big, but being 13% faster is definitely something.

Second Round: Harcore Mode (No Cache At All)

To make this fight even more extreme, I decided to run the same both scenarios but disabling completely the cache on my instance.

    <setting name="Caching.Enabled" value="false" />

Yeah, I know this is something totally unreal and you should never do that in a production environment. But hey, this is science, let’s have some fun while doing it!

Those are the results for the 10 renderings scenario:

And here we have the results for the 100 renderings scenario:

Again, the view rendering is 10% faster on average when compared to the controller rendering.

Final Decision

I think that we can all agree that it wasn’t a knockout or submission. If something, it was more like a split decision by points.

We can confirm that indeed view renderings are generally faster than controller renderings when executed on similar scenarios. Especially in extreme scenarios.

But let’s be honest, in a more realistic use case both are pretty much the same. The controller rendering was even slightly faster than its opponent in one of the tested scenarios.

I don’t know about you guys, but for me, the answer is pretty clear: I’m never going to worry about the performance difference between those two again. Pick one you like most and be happy!

Advertisement