Our company’s mission to work for an open web that is secure, performant, reliable, and accessible has been the driving force behind Tide, a tool that aims to lift code quality across the WordPress ecosystem.
During the 12 month journey Tide has been on, we’ve discovered that the vision behind it also aligns with the goals of WordPress. We saw the value and importance of Tide being part of WordPress itself where it can have a bigger impact and a greater chance of achieving its vision.
During the State of the Word presentation this past weekend Matt Mullenweg announced WordPress’ adoption of the Tide project.
This was a milestone moment for XWP and Tide, and a giant step closer to accomplishing what we set out to do; building a stronger open web.
Tide now belongs to the WordPress community and we are so grateful it will have the community to support it.
How you can contribute to Tide
A priority near-term for XWP is completing the transition to WordPress.org and ensuring that the project continues to build momentum with Derek Herman and Jeff Paul as leading contributors from our team. They welcome and encourage all community participation.
The project site for Tide is make.wordpress.org/tide. Visit and subscribe to the site to remain updated with progress and details on where to contribute. To get involved directly in conversations around Tide, join the #tide channel on the Make WordPress slack.
We would like to thank those who tried out Tide at WordCamp US. The public API will be back online no later than December 20th, paving the way for the integration with WordPress.org.
Thanks to Automattic, Google, and WP Engine who supported us throughout the journey. We are excited to see what the future holds for Tide in WordPress!
Understanding how a headless content management system (CMS) works and the value it provides content producing teams can be a bit of a research journey, but one that can have big payoffs for the right companies. There are many opinions, ideas and buzzwords around content management and headless CMS and unpacking them into valuable takeaways that can inform decisions can be difficult. We, alongside a few of our industry friends, have worked on a number of headless CMS projects and are pleased to bring you a series of posts to help unravel the mystery and shine a light on why and when a headless CMS makes sense.
What is a Headless CMS?
To wrap our heads around the idea of a headless CMS, let’s begin with a simple illustration.
In the 20th century, off the back of the industrial revolution, American factories introduced a method of production we all know as the assembly line. This method of production did a few things:
It introduced work specialization
It accelerated progression through a linear process
It isolated work types, allowing for focus and optimization
Effectively, assembly lines grouped work into stages and allocated specialized resources and processes for each stage.
A headless CMS reflects the assembly line approach. It groups the work performed by both technology and people and allocates specialized resources and processes for each.
Specifically, running headless refers to the practice where content is produced independently of where it is consumed.
But what are the components of a typical headless CMS? Like a factory assembly line, it depends on the work that is being done and the desired outcome. Generally speaking however, a headless CMS is broken into 2 or 3 components.
Content production and data storage are handled by the same system and content presentation is separated out (figure a), or all three components are separated (figure b).
Figure a
Figure b
On the other hand, a traditional CMS has everything all-in-one (figure c).
Figure c
The term “headless” comes from the idea that the production and data storage or “the body,” is removed from how and where the content is presented, “the head.” Search around long enough and you’ll stumble upon a few different terms, like decoupled and content as a service (CaaS), that at a high-level, describe the same sort of thing.
Why is a Headless CMS so Great?
Running separate platforms rather than having everything in the single place may sound like it could actually double your efforts. After all, with a traditional CMS the technology (infrastructure, user interface, etc.) takes care of everything meaning users only need to familiarize themselves with the single environment. For example, the user interface responsible for managing plugins or extensions also needs to facilitate content editing.
However, by doing everything it means that the platform is restricted in its ability to specialize.
By implementing a Headless CMS solution, each part of the system can:
Run on only the technology that is needed
Be isolated from a maintenance and support perspective
Be isolated from an optimization perspective
Present a user interface (UI) relevant to its exact function
Require training only for its exact function
The greatest benefit that comes from running a headless CMS is that the people and platform can specialize and optimize.
How to Know if a Headless CMS is Right for You
While the upside of a headless CMS is clear, how do you decide whether or not to implement? Like with any big implementation, there are some key questions to ask yourself:
How can a headless CMS improve your content management process, and what is the value to your business?
What will it cost?
Does the ROI stack up?
What value can a headless CMS provide to your business?
For example, implementing a user interface (UI) specifically geared for content production sounds great in theory, but will your team realize the benefit? Are they currently hindered by the present system? Will the new system help create greater efficiency?
If the answers is yes, it makes sense to also ask yourself the following questions.
What will it cost to implement a headless CMS?
Whether implemented by an internal team or outsourced, the discovery phase, support, and maintenance will require time and resources. If you choose to use internal resources to implement your headless CMS, it’s important to remember that time spent on the project is time not spent on other business priorities. There is an opportunity cost to any large implementation.
Does the ROI stack up?
While a headless CMS can dramatically improve the efficiency and quality of your content management capabilities, it’s important to understand your ROI expectations for a new tech implementation.
Generally speaking, in our experience it is the larger the team(s) who work day-to-day with the platform where operational efficiency and business profit is tightly correlated that have the greatest potential ROI for a headless CMS implementation.
If you’re interested in learning more about how a headless CMS could work for your business and how it may improve your current CMS, we’d be happy to help. Please contact us for a free consultation.
Every big content team eventually faces the same problem with scaling. The rate (and quality) of content production is no longer proportional to the size of the team. In early days teams can simply add staff to solve production bottlenecks. If they need to do more, they grow the team. However, as they and the systems and processes around them mature, the positive correlation between headcount and content dramatically fades.
In these cases, business managers face a choice. Keep hiring, hoping they stumble on some magical combination of people and roles, or look to the machine underneath the team and find ways to free the team from time/attention/energy-sapping tasks that distract them from what they were really hired to do.
In this article, we’re going to look at the impact a slow-moving content machine has on productivity (and ultimately profit), and then go over 3 examples of ways big teams are unblocking their content creators and freeing them to focus on content creation.
Imagine needing a car mechanic’s help every time you wanted to change gears.
“Hey Bob, could you just drop to second as I approach this intersection. Thanks.”
Unsurprisingly this isn’t reality. We have gearboxes. They take the repeatable and technically complex task of gear-changing and make it accessible to the driver.
Increasing efficiency in big teams, or implementing workflow gearboxes, is perhaps the biggest problem category we work on with our clients. They find that in their day-to-day operations they have these repeatable and technically complex tasks being handled by their development team. For example:
Build a new page layout > Get a developer
Update the style > Submit a ticket
Move a banner ad > Add it to the backlog
The business impact of these bottlenecks is three-fold:
Content production is dependant, or blocked, by the developments team’s capacity to respond to the task
To move a task forward, content producers are required to understand and interact with the development workflow
The development team spends their time on operational tasks rather than focusing on maintaining and enhancing the platform
Removing these kinds of bottlenecks results in massive time and resource savings.
Now remember, in a car a gearbox doesn’t do everything. It has a clearly defined range of influence. It doesn’t let the driver change the oil, swap out a fan belt, or replace a tyre. It lets them change gears. Defining what tasks should be handed over to a site manager, and how, or left in the hands of developers is just as important as the actual implementation. There is a process for identifying what should be gearboxed and what should remain in the purview of the development team, but for now, let’s explore some specific and current examples of how big teams are reducing day-to-day reliance on developers and unblocking their content creators.
Example 1 – Layout & Site Customization
Layout and Site Customization
Layout customization in the form of drag-and-drop page builders is something most site managers are at least familiar with. The WordPress eco-system itself has seen a boom in this quadrant with many businesses developing tools that deliver page-building powers to site owners. However, the translation of this kind of mass-market solution to big teams isn’t as simple as could be expected. There are a few factors that need to be considered. These can include:
Restriction – What should, and should not, be customizable by the team (gearboxing)
Reviews & Approvals – Like general content, layout and site customizations should go through a review workflow
Scheduling – When customizations should go live (more on this in example 2)
The good news is that even though the implementation can be unique to every team, the underlying methods and technology are becoming more standardised. For example, recent and arriving (changesets) updates to WordPress Core lay a very strong foundation for the kind of complex implementation big teams need for layout and site customization.
Example 2 – Complex Scheduling
Complex content and customization scheduling
Let’s use an example to illustrate the opportunity here. Imagine coordinating a 12 days of Christmas campaign that delivers unique content on a rolling 24-hour cycle for the 12 days leading up to the 25th. The number and variety of changes impact things like:
Headlines and other copy
Banner ads
Imagery
Page layouts
Styling
These changes include more than what is typically “scheduled” by site owners. Scheduling content (e.g. articles) is a familiar CMS feature, but big teams need to consider much more. Normally scheduling these kind of changes would involve working with a developer team to stage the changes on a separate instance of the site and scheduling a code-merge. For our above Christmas campaign, this would mean coordinating numerous code-bases and deploying, possibly manually, on a very strict timetable.
Recent updates in WordPress actually now allow the changes to be both made and scheduled within the WordPress user interface. The direct reliance on staging environments and developer teams can be removed through this.
The positive impact on efficiency is obvious when complex changes like these can be systemised (gearboxed) and taken away from developers and given to the content team.
Example 3 – A/B Testing
A/B Testing
Frequent, small, defined and measurable changes to a site will over time produce a far greater ROI than big redesigns. Unsurprisingly, the discipline of A/B testing is widely used and something we see a lot of our clients doing. Simply put, the process looks like:
Select the metric to be improved (E.g. time on page)
Define a hypothesis (E.g. if we increase the body text font-size from 14px to 16px we will see an increase in time on page)
Create the assets required to deliver the alternate state (E.g. font styling)
Set up an A/B experiment to deliver both the current and new state
Measure impact on selected metric
Implement the winner
Throughout this process there are potentially multiple developer touchpoints. I.e.:
Develop experiment assets
Set up mechanism for delivering the experiment
Collect data
Implement experiment winner
For the full value of A/B testing to be realised, experiments need to be run frequently. If developers were required to manage the above 4 points, the bottleneck would prove fatal to the entire process.
Big teams, especially those that are producing and managing high-traffic sites, are systemising this process as much as possible. Even the mechanisms for determining “the winner” of an experiment are being automated. Developers are freed from having to manage and implement and site managers can accelerate the A/B process significantly, properly realizing the ROI of a compounding A/B testing strategy.
These three are only a few of the ways we are seeing big teams remove their dependency on developers and unblock content creators. The industry and technology under it move at an incredible pace and we are constantly seeing innovative solutions enter the market.
How does your team handle these kind of repeatable and technically complex tasks? To what degree do you think your team is burdened by tasks that distract them from focusing on the work they were hired to do?
The more we work with large online publishers, the more we appreciate the impact on-page advertising has on their bottom line. The challenge these companies are facing is that their advertising strategies cannot be set-and-forget. They must evolve. They are realising that not only is the technology behind advertising ever-changing, the attitudes, expectations, and behaviors of readers towards advertising is evolving just as fast.
The risks publishers face in response to this challenge are:
Let their ad technology grow stale and watch their competitors leave them behind, or;
Get implementation wrong and watch their audience engagement plummet
Basically, this means they must grow, and grow the right way, or die.
A stakeholder might put it this way:
“We want to maintain (or grow) our ad revenue but we need to make sure we maintain good page performance and user experience or we will lose our readers.”
For small sites, the method of implementation is important. For large sites with thousands/millions of visitors per day, implementation is everything!
The difficulty here is that this kind of implementation rarely results in better page performance and user experience.
A good rule of thumb is that the more things (like ads) being delivered to a page, the poorer the performance. The poorer the performance, the poorer the user experience.
Simply speaking the things that impact the performance of a page includes:
The number of assets (content, code, images etc) being requested
Where in the page code assets are being requested
The number and location of servers the assets are being requested from
The size of the assets
The technology running on the servers
The quality of the device and software of the user (you can’t really do much about this one)
With these many considerations, you can see how much care needs to be taken for good implementation. Ad services, or ad providers, send a variety of assets to the reader’s browser including images, text and tracking code snippets. Additionally, the page itself is often part of the actual bidding process for auction-based ad services. The nature of what on-page advertising is and what it requires means it is primed to be a major drain on page performance.
But… it doesn’t have to be! When implementation is done right, publishers can realize the revenue upside of an optimised ad strategy without damaging page performance and user experience.
Unsurprisingly, most large publishers are, and have been, careful about ad implementation. However, ad revenue is under increasing pressure from a few fronts. Be it ad-blockers, which are starting to see mass-market adoption, or general banner-blindness, on-page advertising on large publishing sites needs to be more than just good. it needs to be really, really good. A 1% decrease in ad engagement can have a significantly negative impact on overall profit.
We are finding that ad strategy implementation, or general revenue optimisation, is a frequent conversation topic with our clients and contacts. These companies aren’t looking for general advice on which ad service they should choose or how they should design their banners, but are interested in leveraging technology to maximise ad revenue from what is perhaps an increasingly critical audience. They are looking for solutions like automated A/B testing, reader personalization, or as we have found in a recent project with our friends at Resignation Media, optimising on-page ad bidding and ad delivery, or Header Bidding.
For this particular project, the implementation of Header Bidding with the Resignation Media Team meant that they realized a few key benefits:
Access to a wider range of ad providers
Optimised on-page bidding (occurs very early during the page load)
Transparency in reporting and analytics
Or put even simpler, the whole process was faster, more transparent, and more profitable.
Resignation Media were able to implement a more mature advertising strategy and actually improve page performance and user experience.
We’re looking to walk through the technical ins-and-outs of how Header Bidding works in a future post, but the core message is that with the right implementation, publishers can realise increased revenue through on-page advertising without sacrificing page performance and user experience.
If ad revenue is an important part of your bottom-line, what steps are you taking to manage the ever-evolving challenges of typical implementations? Are there opportunities for optimising your technology?
