The genius of Sitecore XM cloud and next.js

Edward Kapuscinski

The genius of Sitecore XM cloud and next.js

I have always been a healthy technology skeptic, and I like to think my skepticism is well warranted. Thanks to this nature, my retirement plans weren’t changed by “Crypto Winter” like some of my colleagues’ plans, but I did eventually come around on the benefits of .NET over my beloved ASP and VB. Over the past few years, headless site development and the rise of the modern JavaScript framework has been a regular subject of this skepticism.

I could see why tools like React and Angular were great for building interactive web applications, but I wasn’t convinced that they, along with the development paradigms they required, were all that great for building the types of web experiences my practice’s customers needed. I am, however, very happy to report that I have become enthusiastic about the evolution of those tools into what I consider the best tool to build web experiences with today: Next.JS.

Next.JS represents an evolution of how best to render and deliver websites to users. It builds on top of decades of understanding of the interactions between users, web browsers, web servers, and content repositories to provide a framework that is truly “fit for purpose” for the multitude of jobs that modern websites need to perform.

The beginning: Static sites

Let me first explain a bit about how things have worked in the past. Historically, web servers responded to a visitor’s request for a URL by generating a “page” as a response and sending it to their browser as HTML to be rendered. The things that happened as part of the building of that response may have varied, but this was the basic paradigm. At first, that processing was very simple: A server would look for a “flat” or “static” HTML document in its file system and just send it along without any processing.

A host of early content management systems emerged to help manage these static sites after they became too complex for developers to manually handle with tools like Adobe Dreamweaver. These CMS tools were good, but all the logic required for building a site was executed when content was published. This was good for performance but not for interactivity.

Introducing interactivity & server-side rendering

As the demands for site functionality and management grew, server-side rendering was introduced to the process. This started with simple things like “server side includes” that allowed site developers to include snippets of code dynamically into HTML files but grew to be fully featured applications like Cold Fusion, Microsoft .NET, Apache Tomcat, PHP, and a host of other options. These tools meant that developers could perform all sorts of functions, like allowing for interactive behaviors through form submissions or pulling content from content managed databases, merging it with templates, and serving it to users.

These tools, however, were also computationally expensive: They required servers to do a host of processing between the time a request was received and a response was generated. As the complexity of a site increased, the amount of computation required to serve that site increased. That could get expensive and, at the same time, could be a problem if a site was suddenly getting far more traffic than normal. Many of us remember sites getting “Slashdotted” or “receiving the Reddit hug” and crashing hard.

On top of this, there was still an issue in that all the logic happened on the server. Once the response was generated and sent to a browser, that was it until the browser made another request. This was fine for serving up news articles but created clunky user interfaces for interactivity. Imagine playing chess online if you had to refresh a page for every move.

The web as we know it

Along came AJAX to solve this problem. AJAX used JavaScript code that was executed inside a user’s browser to dynamically manipulate the HTML they were viewing after it had been rendered. This meant that a server could keep track of each move on a chess board and update both players’ screens at the same time. This was revolutionary! But it was still clunky to develop in a world where server-side code was written in one language (like .NET) and browser-side code was written in another (like the game-changing jQuery library for JavaScript).

Then modern JavaScript frameworks, like React and Angular, came along. Instead of developers developing separate server-side and client-side applications, all that functionality could be developed with a single tool. The mass availability of these tools — and developers with skillsets in them— gave rise to the web as we currently know it, one full of interactive applications like fully featured versions of formerly desktop-only applications, like Microsoft Office and Google Docs, and a whole host of other services, like Facebook and Twitter.

This approach, however, came with a new set of problems. For one, it often “breaks how the web works” if developers aren’t careful. For example, have you ever tried sharing an individual Facebook post in an email? It’s tough to find the “real” URL for anything anymore. Additionally, these frameworks place an enormous amount of trust in the devices accessing them to do the work. Ever wonder why your phone battery drains quickly with certain websites? It’s likely because your phone is doing all the logic to render certain sites. These platforms solved some of the problems with creating great web experiences, but not all of them.

Paradigm shift to Next.JS

Enter Next.JS. Next.JS extends React, a very popular modern JavaScript framework, to fully handle all the common capabilities needed to intelligently deliver modern websites.

The folks behind Next.JS seem to have thought “How do we bring what we’ve been doing into the modern world?” and then did it.Let me start with the first thing that attracted me to the technology and demonstrated its potency and value. A Next.JS application can render content at three separate times: before a request (like an old-school CMS product); at a request (like a modern CMS); and after a request (like a modern web application).

This is game-changing. Optimizing when code is executed allows for incredibly performant web applications, and that matters a great bit in the modern world.

Let’s talk about what this means using the example of a Sitecore-managed product detail page. The page will have CMS-managed product information, pricing information that changes hourly from a PIM, and real-time product availability that’s in an ERP system.In the old paradigm, the user would request the page and the IIS server would get to work building a response.

First, it would have to do all the Sitecore stuff (getting a layout, getting content for the page components, checking permissions, all the stuff we love that Sitecore handles for us). One of those page components would have to reach out and get the pricing information, making the whole thing wait while that happens. Finally, it would serve up the response of the built page that contains some HTML that’s then manipulated in the user’s browser using jQuery to constantly reach out and check product availability with that ERP system and modify the HTML the visitor is seeing with the current stock availability. So a few seconds after requesting the page, everything’s ready for a visitor. Just in time for them to realize they found the item cheaper somewhere else …

So how does Next.JS make this far better? This is assuming, of course, that you’ve coupled a Vercel-hosted Next.JS site with Sitecore XM Cloud and that your developers have done everything the smart way. When you hit “publish” on the product in Sitecore, it starts the rendering process by pre-generating all the static parts of that product page and pushing them to Vercel’s hosting network. When a user requests the page, the statically generated components are ready to go, just like with those ultra-performant “flat” sites of yore.

But what about that “up to the hour” pricing info? Well, that part of the page, and that part of the page only, can be rendered at request time. And the availability part? All handled seamlessly by a Next.JS component that does its work client-side. Because all this is done at the time when it makes the most sense to do it, and the processing for the most complex part is done only once, no matter how many times the page is requested, the performance of the overall experience is far better for users.

The ability to use one programming language to do all this is impressive enough, but Next.JS goes a few steps further.

Not every page is as complex as the one I just described. Some pages are just pages with flat HTML content being delivered to users. Next.JS has us covered there, too, though with a pair of impressive approaches.The first is in the way it handles hyperlinks.

Hyperlinks are the fundamental thing that really made the web work: the ability to navigate from one page to another. However, not much has changed with them since the dawn of the web, until now. The normal thing that happens when you click a link on a site is that it tells your web browser to make a request to a server for another page and to start loading the response for that request.

In Next.JS, however, this isn’t the case.Because Next.JS knows what’s going on in a browser, it doesn’t have to make a request for a full page. Instead, it can tell what parts of the current page need to be replaced for that new page and just request those parts. Once they’re ready, it seamlessly swaps everything around, updates the page URL, and adds an entry to your history. As far as your browser knows, it’s now on a whole new page, but none of the HTML, images, or any other assets that didn’t need to change didn’t. That saves time, bandwidth, memory, and all the other things you’d want.

If that were all the magic behind Next.JS hyperlinks, it would be impressive, but there’s more. Because Next.JS knows what’s going on in a user’s browser, it can be smart about doing the pre-work for those page-part swap-outs. If you’re looking at a list of links, it will start pre-generating the content for the components that need to change if you were to click on one of those links in the background. But that’s theoretically computationally expensive, so because it knows what you can currently see in your browser (and therefore click on), it only generates those chunks for links you can see. Because these components are pre-generated, the actual time required to swap them out is incredibly minimal. This makes browsing between pages on a Next.JS-powered site incredibly fast for visitors.

So page-rendering is great with Next.JS, but modern sites are typically image-heavy affairs. The platform has you covered there, too. Because images aren’t treated merely as HTML tags in Next.JS, it has the ability to both automatically optimize them and ensure that a page includes them in its layout properly. While the automatic optimizations are important for true performance, the proper inclusion in page layouts is critical for the key “Cumulative Layout Shift” metric, which is important for good search engine optimization and user experiences.

Next.JS takes SEO so seriously that its official training curriculum includes an entire unit on it (https://nextjs.org/learn/seo/introduction-to-seo).

The bottom line: Sitecore got it right

As you can see, Next.JS is an important and exciting tool that represents the future of delivering websites to visitors. The reason this is so important to Sitecore customers is that it is a key part of Sitecore’s recommended Sitecore XM Cloud strategy.One of the most practical reasons Sitecore XM Cloud is compelling for site owners is that it represents the most sophisticated way to leverage Next.JS alongside a proven content management experience.

I was dubious when Sitecore set out to convert its core product into a headless platform. I knew the world did not need an expensive alternative to the host of headless CMS products that were already on the market. But to my delight, Sitecore got it right!They have kept the parts of Sitecore we’ve loved for 20 years now—a highly functional and flexible content and experience management paradigm—and coupled it with what we need today, modern site-delivery technologies.

This is what Sitecore XM Cloud represents: the best way to meet the demands of modern, sophisticated site owners.