Try our conversational search powered by Generative AI!

How to build high performing frontend in DXP with .net 5/6?


Good day!

Today our frontend are built with a mix of razor and react, with a mix of jquery in it (I know). Some part of the react is serverside rendered with but not all. We are also on the .net 4 stack and not .net 5/6

Today we get poor performance when going through googles pagespeed and the higher ups blame that for poor sales (I don't think thats the reason at all, but oh well).

But for that reason we are allowed to rebuild the frontend as the code is 2-4 years and hard to upgrade to newest packages as that haven't been maintained

As a backender I would have done it like this:

  1. Razor pages so we get the server side render working out of the box
  2. Custom JS as sugar and not requirement to get the site working (no frontend framework, but can use libs where it is logical. Eg: Image slider, Axios for api requests etc)

But the frontenders in my team doesn't agree and want to keep using react, but I'm not sure how to server side render react and get it high performing in .net 5/6 and DXP?

So thats bring me to my question. If you could start from scratch, hosting in DXP and using newest Optmizely commerce (.net 5/6), how would you build the frontend?

Edited, Apr 20, 2022 5:49

What are the primary detractors in Google PageSpeed?

We find ourselves using Blazor components in a lot of places where we would previously have used something like React or Vue. However, that may obviously require additional skillsets among the frontend developers (using C#/Razor rather than JS/HTML).

Apr 21, 2022 9:23

Not totaly sure what you ask for, but here is a screenshot of the report

Anyway, thats a little of topic as my question is more general

I liked the Blazor idea, but I can't force the frontenders to learn that :/

I'm considering just making epi headless with url like and have the frontend seperate. Just to make the frontends happy and then they can use react with nextjs

Apr 21, 2022 13:36
Ted - Apr 22, 2022 9:41
Hehe, this could be a lengthy discussion... I guess sometimes it's better to select a tech stack for the skillsets of the people building the solution, rather than for the solution itself, to improve velocity. But I don't think you *need* something other than ASP.NET 5+ (and some client-side framework for more complicated interactivity) to get great performance. I've come across quite a few projects where plenty of overhead has been spent "forcing" it to be headless, even though there's no obvious benefit to it. On-page editing is just one area where it can cause unnecessary complexities.
Sebastian Enberget - Apr 26, 2022 18:48
Yupp it could be, and hoped someone had good insight on a good way forward to make everyone happy :D

Like I said, personaly I would have gone for no frontend framework, but hard to convince the frontend guys for that.
I see the code we have for react today and I'm like... this would be much easier with pure js and html.

Thats what I'm concerned about, that it will be much more overhead going for Opti headless even though they support it instead of going the traditional way with razor pages and js as sugar
I see that Opti haven't release the ContentDelivery Packages for commerce 14 yet so guess none have tried the headless option for commerce14 yet,

HTML from the server and closely connected to the SQL Server database. Work with performance hat on from the start. Use dotTrace, measure and find slow places regularly.

Vanilla JS or Hotwire.

Tailwind CSS.

Add loading="lazy" to most images.

Have a strict CSP and connect its policies to the consent functionality so that you limit any 3rd party resources and make all new 3rd parties go through a process to get on the site.

Make the consent dialog not block the site, check as an example.

Apr 28, 2022 16:04

Wow! I'd love to get my hands on this. Second Johan's suggestions.

You'll want to lazy load images, set async on your js / css. Also make sure you are bundling correctly. You can also run your razor partials async and defer any long running creation of html to individual controllers. 

I would get your team to look at caching as a first pass. Browser caching, output caching, caching complex menus or contentloader reads in episerver cache (ISyncronizedObjectInstanceCache), caching any 3rd party responses. Did I mention caching?

May 13, 2022 0:46

OK thank you very much for this information and you can also contact help desk for further assistance 

May 13, 2022 7:12
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.