Headless CMS

™
What you need
to know about
headless CMSs
How to make the right decisions about
your content delivery architecture

White paper // What you need to know about headless CMSs
1
Published 12/17. © 2017 Sitecore Corporation A/S. All rights reserved. Sitecore®
and Own the Experience®
are registered trademarks of Sitecore Corporation A/S in the U.S. and other countries. All other brand
and product names are the property of their respective owners. This document may not, in whole or in part, be photocopied, reproduced, translated, or reduced to any electronic medium or machine readable
form without prior consent, in writing, from Sitecore. Information in this document is subject to change without notice and does not represent a commitment on the part of Sitecore.
Contents
Introduction�� 2
What is a headless CMS?�� 2
Headless CMS—a really big deal�� 2
The third way—headless nirvana�� 3
Sitecore XP 9: hybrid headless perfection�� 4
Glossary of CMS terms��6
Next steps�� 8
About Sitecore�� 8

2
Introduction
Debates about the respective merits of headless and
non-headless CMSs have been ongoing during the past
few years. You may well have been ignoring them. After all,
CMS architecture isn’t exactly a go-to dinner party subject—
even for the most content-obsessed marketers.
But this is an important discussion. The quality of the
content appearing on audience screens is becoming
fundamental to the brand value of most businesses.
To maintain an edge over competitors, you need to ensure
the experiences you and your developer colleagues create are
as rich, smooth, and contextual as possible—and extendable
to wherever your audience is, whether that’s on a mobile
app or connected device. Headless CMS architecture is
a big part of this conversation.
So now’s the time to get to the heart of the headless and
non-headless debate. In this white paper we’ll explain what
headless is (and isn’t). And we’ll look at how you go about
making the right CMS decisions for your company—taking
into account the needs of both developers and marketers.
At Sitecore, we also think it’s time to consider the merits
of a third way: one that’s arguably much better suited to
the modern age of contextual marketing.
Ready? Here we go.
What is a headless CMS?
A headless CMS is a content management system that lets
you store, edit, and manage content—but doesn’t actually
render the content on your audience’s screen.
In other words, a headless CMS separates the creation,
delivery, and management of content (the back-end tasks)
from its presentation on the web page, app, or device
(the front-end tasks). It has no role in website design,
page themes, or templates.
By contrast, traditional coupled (otherwise known as non-
headless) CMSs are responsible not only for content creation,
management, publishing, and delivery—but also for the last-
mile rendering (otherwise known as presentation) of the
web page.
How headless and non-headless CMS
architectures differ
So it’s clear that using a headless CMS (rather than a
coupled CMS) places a lot of responsibility for the end user’s
experience on developers—because how a particular page or
screen is built has to be described in code and managed by
the developer.
But there are some very big advantages to using headless
CMSs—and that’s why it’s become such a big deal lately.
Headless CMS—a really big deal
When the digital world was all about the web and not much
else, a CMS could handle authoring, storage, and presentation
of designed websites quite happily. Content repositories
(which store content and dynamically deliver it to a page)
were optimized for HTML templates. Everything was coupled
together nicely and there were big performance benefits to
this all-round closeness.
Then came the mobile revolution and the internet of things
(IoT) as well as a proliferation of different devices on the
market that didn’t use HTML. Suddenly, the coupled CMS
cracks began to show.
Their content repositories, which were web-page-centric,
just didn’t play nicely with non-HTML formats. They were
ill-equipped to use the latest front-end technologies without
hacks or significant development work. They simply weren’t
ready for an age of fluid and responsive web apps in which
pages dynamically update as users interact with them.
They couldn’t adapt to a new age of content in which
content objects were delivered via an API.
Creation of new content
and organization of
existing content
Headless
Non-headless
Delivery of content to
one or more channels
Headless
Non-headless
The actual rendering or
presentation of content
on one or more devices
Headless
Non-headless
Content management Content delivery Content presentation

3
Enter headless
Then headless CMSs came on the scene and sidestepped all
the problems. The agnostic content (no longer optimized for
HTML or any other format) was stored and easily retrieved
from the headless CMS.
Front-end developers, using tools they liked, could take care
of the look, feel, and functionality of the user’s experience
on web, mobile, or other channels (without having to learn
a CMS user-interface technology that was likely to be way
behind the curve).
Headless CMSs are perfect for an era in which devices had
become powerful enough to cope with rendering locally,
which in itself brought great UX improvements.
Happy developers
Headless CMS and its decoupled rendering has freed
developers from the conventions and structures of the
back end.
Now they no longer have to deal with the peculiarities of a
CMS’s rendering system and technology—whether .NET, JAVA,
PHP, or Ruby. Instead, they can access pure-code fragments
of content that are not already in the final representation of
the page. Using the latest open-source JavaScript libraries and
frameworks, developers can quickly build rich applications
and get full control over the user experience.
Headless architecture has also made the audience experience
smoother and quicker—by moving all the rendering to the
devices and streamlining the back end. Meanwhile, marketers
enjoy the ability to write once and have their content
distributed across all channels.
All this freedom and flexibility is huge for businesses.
It has empowered them to continually move with the
times, innovate, and future-proof their sites.
Sound great? Here comes the “but.”
The BIG headless compromise
There’s a very big downside to headless. Headless CMSs
can disconnect the marketer from managing the customer
experience—and, perhaps more important—from the data
and insights that the customer experience delivers.
Here’s why: The decoupling of the rendering (or presentation)
of the content in a headless CMS means that before the page
is actually rendered, its composition is described in code
only. That means marketers aren’t able to create and edit
content in context. They can’t enjoy what-you-see-is-what-
you-get (WYSIWYG) authoring. To even reposition a simple
component or add a new one requires additional coding.
That’s a big problem for marketers. But here’s another as well.
The fact that content storage and presentation is decoupled
in headless architecture makes it highly problematic to
personalize experiences. Personalization requires collection
and analysis of customer interaction data from the front end
so you can test and optimize personalized experiences from
the back end. That requires a lot of custom integration work
in a headless architecture in which front and back ends are
separated, and even then, some fidelity may be lost.
In an age in which marketing in context and delivering great
experience is everything, this is a huge downside. There is,
however, a win-win-win alternative—a route that’s good
for developers, marketers, and end users.
The third way—headless nirvana
The new, “third way” in CMS architecture delivers marketers,
developers, and end users all the best attributes of headless
and non-headless CMSs:
■■ Front-end developers have total freedom.
Unchained by conventions and structures of any
back end, they can use their tools of choice to get
the most from content.
■■ Marketers connect with the content. They can see
what they’re creating and editing—and only have to
write once to distribute content across all channels.
■■ Marketing in context is possible. Personalization
and optimizing user experiences through testing
becomes easy.
This third way is a new type of no-compromise architecture
that is at the heart of the Sitecore®
Experience Manager
(Sitecore XM), the market-leading CMS in the Sitecore®
Experience Platform™ (XP).

4
A new headless architecture
Sitecore has always stored content in an item-based
repository. In other words, our platform never “pre-bakes”
pages ahead of delivery. We’ve kept the creation, delivery,
and management of content (the back-end tasks) separated
from the rendering, or composition of the web page, app, or
device (the front-end tasks). And that’s been true from the
very start—it’s what we mean when we say that our CMS
“decouples content from its presentation.”
This item-based, logically decoupled architecture means
Sitecore implementation partners and developers have been
able to use Sitecore as a headless system—relying on their
own tools to do the rendering outside of the Sitecore server.
But they missed out on the opportunity to personalize pages.
We wanted to find a way to make it far more straightforward
for front-end developers to decouple the content creation
and management from the presentation, so they could easily:
■■ Maintain full control over the user experience—
no matter which sort of device they were
delivering content to
■■ Use the rendering tools, frameworks, and libraries
they wanted
■■ Build amazingly rich applications
We wanted to deliver all this while still ensuring marketers
retained the power to create and edit in context, in a
WYSIWYG environment, and personalize content for
end users.
Happily, we’ve managed to pull this off in Sitecore XP
version 9.
Sitecore XP 9:
hybrid headless perfection
In Sitecore XP 9, we’ve introduced two add-ons—Sitecore®
Experience Accelerator 1.4 and JavaScript Services Tech
Preview—that deliver a new REST API on the presentation
layer of the Sitecore CMS architecture. This effectively allows
any device or browser to interpret the whole composition of
the page or screen of Sitecore content—complete with all
the personalization rules implemented by the marketer.
Meanwhile, a new JavaScript SDK called JavaScript Services
(JSS), allows front-end developers (even those with no
knowledge of Sitecore) to use modern JavaScript libraries
and frameworks such as React.js and Angular to carry out the
rendering of Sitecore content on an end device or browser.
These two developments mean the presentation of the
content doesn’t have to take place on the Sitecore server
anymore—it can be physically decoupled from the creation,
delivery, and management of content, yet without any of
the downsides normally associated with headless CMSs.
The marketer simply composes the page, sends it off for
approval, and then the page is ready for delivery to any
type of mobile app, web page, or internet-connected device.
The front-end developer can either consume the whole page
created by the marketer or cherry-pick parts of it before
choosing how it’s rendered.
In short, front-end developers get the freedom to use the
tools they want to deliver audiences a great user experience,
while marketers stay in control of the content.
At the heart of the headless process is Sitecore’s content
delivery engine, which pulls together the components of
content into the full screen or page layout before it renders
dynamically on the front end.
For traditional websites, rendering Nirvana is to
combine both the browser and server (known as
universal rendering). This means the server can
instantaneously render the first page delivered to
an end user, avoiding the flash and reload seen in
some web apps. Then the browser can take over
the end user’s next action (for example, clicking
on the nav menu). Because this doesn’t involve
round trips to the server for full page rendering,
it becomes a very fluid process. Sitecore XP 9
makes this possible.

5
Here’s how our hybrid headless architecture works
Item-based
content repository
Sitecore
Experience
Database
Personalization rules
Rendering
server
API
JSS SDK
Sitecore contextual
content delivery server
Sitecore content
management server
Form
Web hero
banner
Text box
Graphic
with caption
Mobile device IoT device Browser
Content marketer uses WYSIWYG tools to
create pages once for any device (attaching
personalization rules when applicable).
For SEO and performance reasons, the JavaScript
application can render on a separate rendering
server fully decoupled from content delivery.
Each page is composed of small content items
(also known as components).
Content items (not yet optimized for any format)
are gathered in repository.
Delivery engine gathers information – ready
to be delivered to device or server (or both)
for rendering.
The Sitecore®
Experience Database™ (xDB)
delivers context about end users including
profile information, past interactions, and more.
New API lets any device/ browser consume
and interpret page or screen composition
AND personalization rules.
New JSS SDK lets front-end devs use JavaScript
libraries and frameworks such as React.js and
Angular to build apps that carry out the rendering
of Sitecore content on end device or browser.

6
Glossary of CMS terms
Back-end developer—creates the core computational
logic of websites, software, and systems. These are
accessed by a user through a front-end system or app.
Content object—content is information which is
created, as part of an editorial process, for consumption
by an audience. A content object is a single piece of
this content (like an article or a headline) with its own
unique identification number.
Content delivery engine—a suite of technologies that
helps you control how your digital content is served to
your audience.
Front-end developer—uses languages such as
JavaScript, HTML, and CSS to make the visual part
of websites work on computers, mobile phones,
and other devices.
Item-based repository—a database of digital content
objects that allows applications (via an API) to access
the content, manage it, and also to modify it.
JavaScript—a programming language that makes
things happen inside the browser, including
interactivity. Think popup windows, Facebook Likes, etc.
JavaScript Engine—a program that executes
JavaScript code.
JSON—short for JavaScript Object Notation,
and is the preferred way to exchange information
between a server and a web application. It’s an
easy-to-understand, readable, text-based format
for representing data.
OData standards—a protocol that defines a set of
best practices for building and consuming RESTful
APIs. Using OData means you don’t have to worry
about the various data-related definitions. It enables
interoperability between disparate data sources,
applications, services, and clients.
Presentation layer—contains the components
that interpret HTML code, JavaScript, and other items
passed from the server, and transforms them into
what the audience sees on a screen.
Rendering—the process of interpreting content data
and other items passed from a server into what the
audience sees on a screen.
REST (or RESTful) API—helps with interoperability
between computer systems. Web services that use
REST allow requesting systems to easily access and
manipulate textual representations of web resources.
SDK (software development kit)—a package of
software development tools and documentation
that helps with the development of applications
for a platform.
Sitecore JavaScript Services (JSS)—a toolkit for
JavaScript developers to build full-fledged solutions
using the latest modern JavaScript UI libraries and
frameworks for Sitecore in a disconnected fashion
and physically decouple rendering from content
delivery without losing the value of Sitecore XP.

7
Contextual delivery
The contextual delivery of content is arguably the most
powerful aspect of Sitecore’s new, flexible, and channel-
agnostic CMS architecture. Marketers, using the Sitecore®
Experience Editor, simply attach personalization and
testing rules to the page or screen. Then this information,
complete with attached cookies and identifiers about the
end user in question, will be available via the API on the
presentation layer.
Then when an end-user’s device makes the request to the
API, the content delivery engine is able to accept this request
and pull information about the end user from the Sitecore®
Experience Database™ (xDB), including profile information,
past interactions, and other available data. Then the engine
can pull components of content into the full screen or page
layout before it renders dynamically on the front end.
All this means that any rules-based personalization set up
on a content component (for example, an exclusive offer on
a travel site about a premium cruise which is only presented
to visitors with a luxury travel persona) will be applied by the
content delivery engine.
More control over JavaScript
Sitecore’s JavaScript Services is set for official release in
early 2018, but it’s available for public preview now. JSS is a
toolkit for JavaScript developers that allows them to build
sophisticated Sitecore web apps using JavaScript libraries
and frameworks.
Along with our new presentation layer API, JSS will help
bridge the gap between the front end and back end, while
helping front-end developers become way more productive
when using Sitecore and JavaScript.
JSS will offer lots of useful Sitecore abstractions, helping
front-end developers map the output of the presentation
layer to the final render—whether HTML or something else
native mobile. It will help them build fully headless JavaScript
front ends that are fully integrated with the Sitecore
Experience Platform.
JSS will initially support React.js and Angular, but expect
more to be supported as time goes by.
Bringing it all together
At Sitecore, we’re committed to narrowing the divide between
back-end developers, front-end developers, marketers, and
their audiences—freeing them all to produce outstanding,
contextual user experiences on any channel.
The release of Sitecore Experience Platform 9 makes
further strides by continuing to build on OData standards.
This allows you to use off-the-shelf component libraries
and software to create content for your audiences
without having to worry about the various intricacies of
the REST API request, response headers, status codes,
HTTP methods, URL conventions, media types, payload
formats, and query options.
This is part of Sitecore’s journey toward standards-based
communication, rather than proprietary formats.
In summary, Sitecore’s current products and those in the
pipeline offer more control over the delivery, management,
layout, and presentation of content—regardless of channel,
device, or platform. Meanwhile, reporting back becomes
straightforward. And it doesn’t even require separate
analytics tools.
Your next headless move
At Sitecore, we’ve always believed headless should be a
win-win-win—for marketers, developers, and the customer.
We think that by delivering this triple win, we’ve reframed
the headless debate.
The headless CMS approach will increasingly prove invaluable
to many organizations—but there’s no longer a need to
endure the traditional downsides.
When deciding on CMS architecture, businesses should now
be asking a simple question: How does this CMS empower
marketers and developers to deliver the most rich and
contextual experiences to their audiences?

8
Next steps
We’d welcome the opportunity to hear about your plans for
headless. Reach out to us via:
■■ Email: sitecore.net/contact-us
■■ Phone: sitecore.net/phone
■■ Chat: sitecore.net/chat
■■ Or request a demo here.
If you need further help with understanding Sitecore’s
decoupled architecture:
■■ visit Sitecore Documentation
■■ give your account manager a call
■■ or check out Sitecore training to book an online
or in-person training session.
About Sitecore
Sitecore is the global leader in experience management
software that combines content management, commerce, and
customer insights. The Sitecore Experience Cloud™ empowers
marketers to deliver personalized content in real time and
at scale across every channel—before, during, and after a
sale. More than 5,200 brands—including American Express,
Carnival Cruise Lines, Dow Chemical, and L’Oréal—have
trusted Sitecore to deliver the personalized interactions
that delight audiences, build loyalty, and drive revenue.

Headless CMS

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Headless CMS

Ähnlich wie Headless CMS (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Headless CMS