Sitecore Symposium: How to Embrace the Composable Future

JSS, Next.js, Vercel. JAMStack, static site generation, and headless. These are all terms you’ve probably heard a lot lately, especially if you attended Sitecore Symposium 2022. But what do they mean? And what’s the difference between these technologies and the ones you’ve used before?

Let’s start with the issue at hand. What are you comparing? If you’re looking at an upcoming Sitecore project, you must decide if you’re going to build it the classic way—meaning .NET, MVC, and server-side page generation or embrace the headless approach by adopting a JAMStack architecture.

So, what is JAMStack? The JAM in JAMStack stands for JavaScript, APIs, and Markup. It’s a simple concept that has a lot of implications for how you build a website. Going with this approach means changing architecture, hosting models, and learning new skills for the members of your web team. There are added costs compared to the classic approach you’re comfortable with. That’s why you need to weigh the costs and benefits of going with what you know versus pushing forward with new technology.

There are two primary benefits you should think about when creating your website with the JAMStack architecture: speed and scalability.

Faster Pages, Happier Customers

What do we mean by speed? Simply put, it’s the ability to deliver your content to your audiences faster.

Studies have shown that customer engagement depends greatly on the speed at which you can respond to their requests. Think about a website you visited lately that took a long time to load. You hit a link and then count one, two, three, four…you’re already bored. Maybe you flip over to your favorite social media app while waiting for this page to load. Or open another tab in your browser, perhaps a competitor’s site?

Our attention spans are short, and we crave immediate feedback. The longer your page takes to get to your audiences, the greater the chance they’ll get impatient and move on. That’s how inefficient technology causes a lost customer.

Three seconds doesn’t seem that long! And yet, every second has a cost. Think about your website. Are your most important pages your most optimized ones? If not, what are those delays costing you?

It’s not just your conversion rate, it’s also your customer’s ability to find you in the first place. If your site doesn’t perform, then search engines deprioritize your content. They’re interested in giving their users the best experiences too.

This is the number one concern of JAMStack architecture—speed—to deliver your content to your audiences as fast as possible. It helps keep those people engaged instead of waiting for your content to render on a server.

Scale With Confidence

The second benefit of JAMStack architecture is scale. Think about your website again, and what happens when there’s suddenly a flood of traffic. Can it handle unexpected surges, or does it slow down? Maybe it starts responding with errors? If that’s happening to you, you’re not alone. It’s more common than you think.

When you’re trying to get to the bottom of the issue, you may hear a lot of different reasons, like, “We need more servers. We need a better caching strategy. We need to put more in the content delivery network (CDN).” Perhaps there’s a bit of inefficient code that no one can seem to get to the bottom of, and it always winds up causing problems exactly during peak hours.

Keep thinking about your website. Likely, most of the content doesn’t change from page load to page load. Why does it need to run all that logic, and render that same page, every time it’s requested?

Sure, there are CDNs, caching strategies, instrumentation analysis, and reports to pour over. All these things layer on technology on top of, or inside of, your content delivery environment to make it go faster, to serve more requests, and to get your content to more users. But what if we just…didn’t do all that?

Enter static site generation (SSG). In this model, you render the page once and serve it up from an edge server (think closer to the customer, thus faster!). If a page is the same for everyone, why give everyone their own specifically rendered page-consuming resources on a server?

SSG gives you the same experience. The page is pre-rendered, running all that business-critical server-side logic. Then it’s published and cached. When a user requests it, the work to generate that page has already been done. You send the finished markup down to their browser and let the browsers do the work of rendering it. You’ve offloaded that work to the client browsers so you can do more with less.

JAMStack and Sitecore

All of this is great and that answers the question of why you should care about JAMStack architecture. You should care because it improves the experience for your users. It boosts their confidence in you, and it keeps them engaged with your site and your content. So, why hasn’t everyone been using this architecture all along?

Technology changes and evolves. If you’re not moving forward, you’re falling behind, right? You’ve probably heard this before. At Velir, we’ve built some amazing websites with Sitecore, using server-side renderings and MVC. So why change what works? What are you going to give up by adopting this new technology?

Turns out, not much. When you think about the Sitecore platform, and why you would choose it, a few things come to mind. One is its flexibility. With Sitecore, you can create the site architectures you need to satisfy your organization, and all the components to realize the design that you’ve invested so much in, without compromise. The ability to quickly stamp out and customize pages in the Experience Editor, and to create deep content relationships you can use to dynamically serve that content is why you choose Sitecore.

Will you lose all those things if you get rid of server-side logic? Will your dynamic content components still deliver content dynamically, or will you have to add new content every time we make a new article? Does Experience Editor still work if the site uses JSS and is statically generated? Can your users log in?

Don’t worry, it all still works. This is where Sitecore 10 shines, and why we feel that this release is the appropriate time to make your move into the future. Because there isn’t any compromise. You can get all the benefits of JAMStack, the performance and scalability, without sacrificing the functionality you need to run your digital business. The composable model lets you choose the best pieces to fit your needs.

The Composable Checklist

Whether you’re upgrading an existing site or starting something new, ask yourself these questions to find out if you’re ready to move into Sitecore’s Digital Experience Platform (DXP) and adopt a headless approach to your next build.

• Is your dev team ready to adopt new patterns?
  • Moving the primary development language from .NET to JavaScript is an adjustment for your developers. Are they trained and ready?
• What is your path for hosting changes?
  • JAMStack architectures don’t require new infrastructure, but without them, you can’t take advantage of their benefits. Are you prepared to make these adjustments?
• What is your search provider?
  • Statically generated sites require compatible search providers. Coveo and Sitecore Search are great choices.
• Can your site take advantage of SSG?
  • How static is your content? How much is personalized based on user roles or session interactions?
• Are you ready to transition from Sitecore xDB to Sitecore’s Customer Data Platform (CDP)?
  • Headless sites aren’t compatible with Sitecore xDB. What will the move to Sitecore CDP look like?
• What is your path for content migration?
  • What content will be statically generated? What dynamic content will need to be adjusted?

Excited about the transition to JAMStack architecture, but not sure how to make it happen for your Sitecore website? Contact us, and we can help you through the process so you can embrace Sitecore’s composable future!