Blurring the Line Between CDN and CMS

Cloudflare recently announced that they’re launching a new feature, called “Cloudflare Workers”. It provides the ability for anybody who’s using Cloudflare as a CDN to write arbitrary JavaScript (based on the standard Service Worker API), which runs on Cloudflare’s edge nodes.

In plain English, you’ll be able to write code which changes the content, headers, look, feel and behaviour of your pages via the Cloudflare CDN. You can do this without making development changes on your servers, and without having to integrate into existing site logic.

If you’re familiar with JavaScript, you can just log into Cloudflare, and start writing logic which runs on top of your server output.

Why is this helpful?

As SEOs, we frequently work with sites which need technical improvements or changes. But development queues are often slow, resources restricted, and website platforms complex to change. It’s hard to get things changed or added.

So many of us have grown comfortable with using workarounds like Google Tag Manager to implement SEO changes - like fixing broken canonical URL tags, or adding robots directives to pages - and hoping that Google respects or understand the conflicting signals we send when we mix on-page and JavaScript-based rules.

But whilst Google professes to be capable of crawling, indexing and understanding JavaScript content and websites, all of the research suggests that they get it wrong as often as they get it right.

Cloudflare’s announcement is significant because, unlike tag management platforms, the alterations are made server-side, before the page is sent to the user - Google only sees the final, altered code and content. There’s no messy JavaScript in the browser, no cloaking, and no conflicting logic.

Service workers on the edge

Cloudflare, like other CDNs, has servers all over the world. When users request a URL on your website, they’re automatically routed to the nearest geographic ‘edge node’, so that users access the site via a fast, local connection. This is pretty standard stuff.

What’s new, however, is that you can now write code which runs at those edge nodes, which allows fine-grained control over how the page is presented to the end user based on their location, or using any logic you care to specify.

With full control over the response from the CDN, it’s possible to write scripts which change title tags, alter canonical URLs, redirect the user, change HTTP headers, or which add completely new functionality; you can adapt, change, delete, build upon or build around anything in the content which is returned from the server.

It’s worth noting that other platforms, like AWS, already launched something like this in July 2017. The concept of making changes at the edge isn’t completely new, but AWS uses a different approach and technology stack.

Specifically, AWS requires users to write functions in Node.js (a common server-side JavaScript framework), using a specific and proprietary approach to how requests/responses are handled. This comes with some advantages (like being able to use some Node.js libraries) but locks you into a very specific approach.

Cloudflare’s solution is based on the Service Worker API (as opposed to Node.js), which might look like a more future-proof approach.

Service workers are the current framework of choice for progressive web apps (PWAs), managing structured markup, and playing with new/emerging formats as Google (and the wider web) moves from favouring traditional websites to embracing more app-like experiences. That makes it a good skill set to learn, to use, and potentially to recycle existing code and solutions from elsewhere in your ecosystem.

That PWAs look likely to be the next (arguably, the current) big thing means that service workers aren't going anywhere anytime soon, but Node.js might just be the current flavour of the month.

Getting hands-on

Cloudflare provides a sandbox for you to test and visualise changes on any website, though it’s unclear whether this is part of their launch marketing or something which will be around for the long-term (or a component of the editor/deployment system itself).

That’s a lot of power to play with, and I was keen to explore what it looks like in practice.

It took me just a few minutes to modify one of the scripts on their announcement page to add the word ‘awesome’ (in a pleasing shade of orange) to Distilled’s homepage. You can check out the code here.

Whilst this is hugely powerful, it doesn’t come without risks and drawbacks. For a start, you’ll need to have some sharp JavaScript skills to write any rules, and you’re going to have to do it without any external supporting libraries of frameworks (like jQuery).

Service workers can be complex to work with, too. For example, all of your changes are asynchronous; they all run in parallel, at the same time. That makes things lightning fast, but it means that some complex logic which relies on specific ordering or dependencies might be challenging to write and maintain.

And with all of this, there’s also no nice WYSIWYG interface, guides or tutorials (other than general JS or service worker questions on StackOverflow). You’ll be flying by the seat of your pants, spending most of your time trying to work out why your code doesn’t work. And if you need to turn to your developers for help, you’re back at our initial problem - they’re busy, they have other priorities, and you’re fighting for resources.

A meta CMS is not a toy

As we increasingly find ourselves turning to workarounds for long development cycles, issues which “can’t be fixed”, and resolving technical challenges, it’s tempting to see solutions like Google Tag Manager and Cloudflare Workers as viable solutions.

If we can’t get the thing fixed, we can patch over it with a temporary solution which we can deploy ‘higher up the stack’ (a level ‘above’/before the CMS), and perhaps reprioritise and revisit the actual problem at a later date.

You can fix your broken redirects. You can migrate to HTTPS and HTTP/2. You can work through all those minor template errors which the development team will never get to.

But as this way of working becomes habit, it’s not unusual to find that the solutions we’re using (whether it’s Google Tag Manager, Cloudflare, or our own ODN) take on the characteristics of ‘Meta CMSs’; systems which increasingly override our templates, content and page logic, and which use CMS-like logic to determine what the end user sees.

Over time, we build up more and more rules and replacement, until we find that there’s a blurring of lines between which bits of our website and content we manage in each platform.

This creates a bunch of risks and challenges, such as:

• What happens when the underlying code changes, or when rules conflict?
  If you’re using a tag manager or CDN to layer changes ‘on top’ of HTML code and pages, what happens when developers make changes to the underlying site logic?

  More often than not, the rules you’ve defined to layer your changes break, with potentially disastrous consequences. And when you’ve multiple rules with conflicting directives, how do you manage which ones win?

• How do you know what does what?
  Writing rules in raw JavaScript doesn’t make for easily readable, at-a-glance understanding of what’s being altered.

  When you’ve got lots of rules or particularly complex scripts, you’ll need a logging or documentation process to provide human-friendly overviews of how all of the moving parts work and interact.

• Who logs what’s where?
  If conflicts arise, or if you want to update or make new changes you’ll need to edit or build on top of your existing systems. But how do you know which systems - your CMS or your meta CMS - are controlling which bits of the templates, content and pages you want to modify?

  You’ve got rules and logic in multiple places, and it’s a headache keeping track.

  When the CEO asks why the page he’s looking at is broken, how do you begin to work out why, and where, things have gone wrong?

• How do you do QA and testing?
  Unless your systems provide an easy way to preview changes, and allow you to expose testing URLs for the purposes of QA, browser testing and similar, you’ve got a system with a lot of power and very little quality control. At the moment, it doesn’t look like Cloudflare supports this.

• How do you manage access and versioning?
  As your rules change, evolve and layer over time, you’ll need a way of managing version control, change logging, and access/permissions. It’s unclear if, or how Cloudflare will attack this at the moment, but the rest of their ecosystem is generally lacking in this regard.

• How do you prevent accidental exposure/caching/PII etc?
  When you’ve full access to every piece of data flowing to or from the server, you can very easily do things which you probably shouldn’t - even accidentally. It doesn’t take much to accidentally store, save, or expose private user information, credit card transaction details, and other sensitive content.

  With great power comes great responsibility, and just writing-some-javascript can have unintended consequences.

In general then, relying overly on your CDN as a meta CMS feels like a risky solution. It’s good for patching over problems, but it’s going to cause operational and organisational headaches.

That’s not to say that it’s not a useful tool, though. If you’re already on Cloudflare, and you have complex challenges which you can resolve as a one-off fix using Cloudflare Workers, then it’s a great way to bypass the issue and get some easy wins.

Alternatively, if you need to execute geographically specific content, caching or redirect logic (at the closest local edge node to the user), then this is a really great tool - there are definitely use cases around geographically/legally restricted content where this is the perfect tool for the job.

Otherwise, it feels like trying to fix the problem is almost always going to be the better solution. Even if your developers are slow, you’re better off addressing the underlying issues at their source than patching on layers of (potentially unstable) fixes over the top.

Sometimes, Cloudflare Workers will be an elegant solution - more often than not, you should try to fix things the old-fashioned way.

ODN as a meta CMS

Except, there may be an exception to the rule.

If you could have all of the advantages of a meta CMS, but with provisions for avoiding all of the pitfalls I’ve identified - access and version control, intuitive interfaces, secure testing processes, and documentation - you could solve all of your technical SEO challenges overnight, and they’d stay solved.

And whilst I want to stress that I’m not a sales guy, we have a solution.

Our ‘Optimisation Delivery Network’ product (Distilled ODN for short) does all of this, with none of the disadvantages we’ve explored.

We built, and market our platform as an SEO split-testing solution (and it’s a uniquely awesome way to measure the effectiveness of on-page SEO changes at scale), but more interestingly for us, it’s essentially a grown-up meta CMS.

It works by making structured changes to pages, between the request to the server and the point where the page is delivered back to the user. It can do everything that Google Tag Manager or Cloudflare can do to your pages, headers, content and response behaviour.

And it has a friendly user interface. It’s enterprise-grade, it’s scalable, safe, and answers to all of the other challenges we’ve explored.

We have clients who rely on ODN for A/B testing their organic search traffic and pages, but many of these also use the platform to just fix stuff. Their marketing teams can log in, define rules and conditions, and fix issues which it’d typically take months (sometimes years) for development teams to address.

So whilst ODN still isn’t a perfect fix - if you’re in need of a meta CMS then something has already gone wrong upstream - it’s at least a viable, mature and sophisticated way of bypassing clunky development processes and delivering quick, tactical wins.

I expect we’ll see much more movement in the meta CMS market in the next year or so, especially as there are now multiple players in the space (including Amazon!); but how viable their products will be - if they don’t have usable interfaces and account for organisational/operational challenges - is yet to be seen.

In the meantime, you should have a play with Cloudflare’s sandbox, and if you want more firepower and a stronger safety net, get in touch with us for a Distilled ODN demo.

Get blog posts via email

About the author

Jono Alderson

Jono joined the Distilled family as a Principal Consultant in November 2016, after many years attending and occasionally speaking at our tri-annual SearchLove conferences. He's a well-known and respected figure in the digital marketing industry...   read more

Source: Distilled