By Jessica Hulett October 26, 2020 Twitter LinkedIn Facebook
Walk through the helpful process of using the five Ws to determine whether a decoupled website is a good choice for your business or organization.
Decoupled websites have grown in popularity in recent years, as newer front-end tools offering improved functionality have exploded on the market. But that doesn’t mean it’s a one-size-fits-all approach for every website.
Steve Persch who’s Pantheon’s Technical Product Marketing Manager, recently presented at WPCampus 2020 Online with Rachel Cherry, the Director of WPCampus on the topic. Here are the key takeaways from the event, including how site decoupling can improve your flexibility and boost your performance.
Editor’s Note: Our Five Ws of Decoupled Websites webinar from December 2020 provides greater detail on Pantheon’s forthcoming offerings of Decoupled Bridge and Edge Sites.
What Is a Decoupled Site?
On a basic level, a decoupled site is one in which the back-end functionality and database is separate from the front-end presentation. That means content editors will go into the CMS back-end to create content, but your website visitors engage with a front-end that lives outside of the CMS.
There are many different ways to decouple your site architecture. There can be a hard split between the back and front ends. For example, your back-end CMS can run on PHP, and your front-end framework can be written in JavaScript. For instance, you can use WordPress or Drupal for your CMS, and then a framework like Gatsby for your front-end site.
Progressive decoupling, on the other hand, is when you only split certain components of your webpage. For example, your site’s CMS may be on Drupal, but certain blocks or widgets might be implemented in Vue.js. This approach can be used for a gradual site decoupling, or it can be a permanent split.
Why Have a Decoupled Site?
There are a number of advantages to having a decoupled site. While having an end-to-end site built in WordPress or Drupal may make some aspects of website management easier, there may be better solutions for some of the functionality you want on your site. And you likely don’t need everything included in a monolithic application, which can make them unwieldy.
Content management systems are, first and foremost, built to manage content. Using them for that, and then bringing in tools that are built for front-end performance can make your site faster and more flexible. A decoupled environment allows you to iterate quickly and more often, which leads to better customer experiences.
Who Benefits From a Decoupled Site?
The short answer to that question is, everyone who is responsible for maintaining and updating the site. But some members of the web team benefit greatly from splitting the architecture, including:
-
Front-end developers: They have to contend with an ever-growing number of devices, browsers, and nuances on the front end. Utilizing front-end tools built specifically for these challenges is easier and more effective than trying to do everything in a monolithic CMS.
-
Designers: The faster iteration cycle of having a decoupled website is a huge advantage for designers. It allows them to demo and push changes live quickly, allowing for greater flexibility and frequent updates.
The faster and easier the iteration, the better the website, which means more value to the site visitor. Decoupled architecture puts you in a better position to deliver that value on a consistent basis.
Where Should Your Decoupled Site Live?
Decoupled sites may streamline your processes and user experience, but they do complicate things from a management perspective. Where does everything live? Who controls what? How do you ensure everyone is still working together?
If you want to decouple your website, you may need new infrastructure. It could be a major cloud provider that you configure yourself, or specialized services that split your front- and back-end resources across different places. Where to put your decoupled site comes down to how you plan to manage it and the resources you have available.
This challenge is one of the biggest pain points involved in decoupling a website. At Pantheon, we have been working on a solution with a small set of customers, and soon we’ll be rolling out a full product offering for managing decoupled site architecture.
When Is It a Good Idea to Decouple?
The decision to decouple or not to decouple is not one to be taken lightly. There is a lot of research and work involved, and you have to ensure that you have the resources to make it work.
Decoupling makes the most sense when it will move you closer to your business goals. What are your pain points? What do you want to accomplish? How fast do you need to get there? If decoupling will address those needs, then it’s worth considering.
When you decide it’s time to decouple, you have to focus on how. And the most important thing to remember on that front is, not all at once. If you run multiple large sites, don’t move the front-end side of every one to a new tool. Start with a widget. Start with a block. Start with a page. Build from there. Investing the time and resources to decouple a large network of sites — only to realize it wasn’t the right move — will only set your web team back.
Decoupled websites aren’t right for every business, or even every website within businesses. Assessing your goals, the work involved, and most importantly, how it will deliver better customer experiences, is a process and ultimately a decision that’s unique for every web team.
Interested in how Pantheon can empower your teams to accelerate collaboration and deliver results — by uniting front- and back-end developers on a single platform? Go here for more info on Pantheon's Decoupled CMS, and listen to Steve Persch's Decoupled-specific session from our latest WebOps Summit here.
You might also like:
- How Decoupled Architectures Benefit the Entire Web Team, and Drive User Engagement
- What Gutenberg Means for Headless/Decoupled CMS
- Drupal: Sometimes Headless, Never Heartless
- Headless Websites: What's the Big Deal with Decoupled Architecture?
Topics: Decoupled CMS