As specialists in building websites for government agencies, we’ve seen e-government come a long way over the past decade. We also know there’s still much progress to be made. According to Forrester’s 2019 US Federal Customer Experience, no less than 80% of US federal websites ranked “poor” or “very poor” as opposed to just 14% of private sector brands.
Sitebuilding for governments tends towards the conservative. This is hardly surprising. Governments typically have strict visual guidelines for their agencies. They also have to satisfy very stringent security requirements as well as accessibility standards. They’re also expected to stay on budget. The Canadian government found this out the hard way when its web redesign went over-budget by over CA$7 million in 2016 and the press had a field day with it.
It’s little wonder governments tend to “play it safe” with web design at the expense of innovation.
That said, people have come to expect a lot of government websites. Agencies with fast, easy-to-access sites accessible via multiple devices are in turn rewarded in many ways. This includes reduced workload of employees in the form of in-person walk-ins and inbound phone calls and increased community engagement through uptake of government programs as well as investment, migration, tourism, and job seekers.
Like private businesses, governments have much to gain in being innovative online. Going headless is one way organizations are innovating on the web, and definitely an option that government agencies should consider if they want to optimize e-government.
What is a “headless” site?
For those unfamiliar with the term, a headless content management system is exactly what it sounds like – a back end-only CMS that communicates with a decoupled front-end presentation layer via API call.
In a traditional CMS, you have a content management layer that is fully integrated with the presentation layer. This structure has certain advantages, namely its simplicity and ease of management. But with mobile apps, chatbots, the Internet of Things (IoT), and other innovations becoming standard fare, a lot more is being asked of web content than to simply exist on a website.
With a headless CMS, there are no limits to the number of “heads” you can stitch onto a back end. Furthermore, in a headless environment, none of the traffic demands of these various heads come at the expense of site performance. This is particularly advantageous for high-traffic sites prone to sudden spikes in bandwidth use, which can easily overwhelm a server and paralyze a site in a traditional CMS environment.
Headless does have its disadvantages. A headless site is going to be more work to maintain than a traditional one. Because you’re eschewing the out-of-the-box front end templates of a Drupal or WordPress, you’ll need a skilled on-staff or contracted front-end developer to make it work. You’ll also likely need separate hosting for the front and back ends of the site, which can add to the upfront cost.
Whether or not a decoupled solution is right for you depends on your website needs. If your online presence is largely static and informational, going headless is just going to add an element of complexity that you likely don’t need. However, if you have a high-traffic site prone to big spikes in visitors that features dynamic content and is geared for two-way communication, it’s definitely worth considering.
Benefits of headlessness for government agencies
While uptake of the decoupled model has been precipitous in the private sector in recent years, governments have been slow to adopt the model. This is mostly due to the approval processes being in place for the likes of traditional Drupal, which is well-established in the public sector. Decoupled architecture is a new phenomenon, and thus concerns about its security have likely stymied its adoption by governments.
There are numerous reasons, however, why government agencies should look into headless solutions. Here are five:
- Speed and performance
Headless websites are fast across the board, and this alone should make them worth considering. In e-commerce, sites that load in one second have a conversion rate three times higher than ones that load in five seconds and five times higher than ones that take ten seconds. While governments aren’t e-commerce, there’s no reason to think site speed impacts the uptake of e-government services any less than it does online sales.
Many government websites are also prone to large spikes in traffic and the declines in performance that this can cause. This was graphically demonstrated during the pandemic, when many sites that provided COVID-19 data faced traffic surge-related problems. A headless site offers a layer of protection to your back end server, offering seamless crisis communication support.
- Scalability
From public transit apps to personalized chatbots, governments are increasingly diversifying their digital outreach. This alone is a reason to consider a headless environment. With a detached CMS, you can literally add anything on as a “head” without sacrificing any single component’s performance.
- Efficiency and cost
A headless configuration enables you to prioritize your data design over development. This can reduce costs, make for faster deployments, and make your data available for multiple interfaces. In a decoupled environment, you don’t need an interface to test your back end. Good API documentation is enough for testing back-end development.
- Security
Site security is a major concern of governments and a significant factor behind their hesitance to try out new models. However, going headless actually offers a layer of security not offered by traditional CMSs. Transmitting content as read-only data via API protects the back end from attacks with multiple layers of code.
Headless sites are also better protected from distributed denial-of-service (DDoS) attacks, in which hackers attempt to overwhelm a site by flooding it with requests, as this translates to a single request in a headless CMS.
- Flexibility and availability of talent
With the traditional monolithic Drupal, you’re stuck with the Drupal front end and its unique development requirements. Drupal front-end developers require a high level of expertise in PHP and the Twig templating system, which are unique to the platform and are generally not taught in college training programs. The result of this is that Drupal front-end developers are thin on the ground, presenting a challenge for organizations looking to add such talent to their IT teams.
Going headless means freedom from Drupal front-end development strictures. It means you can select from a wide range of JavaScript frameworks like Angular, React, Vue, Ember, and so on. This in turn translates into a wider talent pool, as JavaScript is widely taught in colleges and developers with this skill set are much easier to find.
Drupal and headlessness
Roughly 56% of all government websites ran on Drupal as of 2021. This is hardly surprising given the platform’s robustness and security, its flexibility by way of an ever-expanding galaxy of contributor-developed modules, its commitment to accessibility, and the transparency of the open-source model itself – all important factors for government agencies. It’s also been around longer than most, longer even than WordPress, which makes it better established.
Drupal is also a dependable CMS for headless configurations thanks to its support for REST, JSON, and GraphQL APIs. Drupal 10 makes decoupling even easier by adding read-only menus for Drupal HTTP APIs, thereby making it easier for front-end developers to consume menu data to build navigation systems. Meanwhile, front-end frameworks like Next.js and Gatsby enable some of the functionality lost when discarding the Drupal front-end, such as the ability to preview new content.
The advent of headlessness has seen a number of API-first content management platforms like Contentful emerge that are giving Drupal a run for its money. Drupal, however, is peerless when it comes to managing large amounts of content and the editorial workflows that come with that, as well as modeling diverse types of content, while its API capabilities are as reliable as any other API-first platform. Sometimes it pays to be the older, more experienced kid on the block.
If you’re contending with a large, diverse array of content with complex workflows, as many government agencies are, Drupal is simply a better CMS for managing it all.
