Static is the New Dynamic

Static is the New Dynamic

Remember when web servers were essentially a metal box with a fixed IP? When web content management meant copy-pasting indecipherable bits of text from the HTML tab in Microsoft Frontpage? And when Amazon’s homepage looked like this in your browser?

Amazon.com Old

Well, that was a long time ago. Back then when you were surfing the web, your web browser (likely Mosaic) would ask a web server for a static HTML file, which would then send it back through your 14.4 Kbps dial-up connection. That was that – no interactivity, no high-res images, no cool videos.

Not surprisingly, a lot has changed since then. Specifically, sophisticated dynamic website frameworks have evolved, adding a lot of exciting elements to the user experience.

And yet… static site generators have recently been experiencing a renaissance. Huh? With all the amazing server-side dynamics available, why would users be interested in this ancient approach to delivering web pages? And in particular, why would CoreMedia be intrigued? Read on!

A Static Website Doesn't Mean Dull

Along with web frameworks, browsers and client-side tooling have evolved as well. This is not news, but claims about the drawbacks of static sites remain, such as "You can’t do site search," "You can’t do personalization," "You can’t do paywalls or gated content," etc.

But technology has caught up.

Regarding search, for example: Depending on the volume of your sites and your specific needs, a client-side search solution like js-search could be all you need. For more demanding search requirements, search-as-a-service offerings such as Algolia or Bonsai are well worth a look.

And for features traditionally asking for server-side dynamics like personalization, gated content, and A/B testing: These elements can be implemented by applying client-side techniques from modern JavaScript-based frameworks. Or more interestingly, by pushing the dynamic part to the edge - that is, doing dynamics in a globally distributed way - and using serverless offerings such as AWS’s Lambda@Edge or Cloudflare Workers.

Hosting a Static Site is a No-Brainer (and Cheap)

So let’s talk about the cost factor for a static site.

When you’re dealing with virtual machines to host your dynamic delivery, it’s not unusual to find yourself facing cloud costs ranging from OMG to WTF — even when you pick the cheapest options.

Then, of course, you have to maintain, update, and monitor these machines, ensure your setup is secure and resilient, and even figure out how to extend it to different regions of the world.

But when you’re only serving a static website, all that headache goes away. You can just sync files to one of the many cloud storage services, turn on public hosting, and - boom! - you’re done.

Many services offer generous free tiers and even paid options are super affordable, such as Google Cloud’s two cents per gigabyte-month. A global content delivery network (CDN) may already be built-in, and even when it’s not, adding it usually requires just a few extra steps. And as a bonus, you could even get add-ons like SSL termination and the respective certificates for free.

Gatsby and CoreMedia: A Great Static Site Match

Enter Gatsby, one of the newest contenders in the field of static site generators.

Gatsby made an impressive debut in 2019 on stateofjs.com, instantly becoming one of the most interesting back-end frameworks. The main repository has over 3,500 contributors and over 45,000 stars on GitHub as I type this.

The framework got my attention because of some bold design decisions. Essentially, Gatsby acts as a "web compiler" using React-based components as main building blocks, automatically applying hyper-efficient client-side techniques that make the end result ultra-fast — almost to the point where using a Gatsby-powered site feels like a native app.

Furthermore, it has elegantly abstracted out content sourcing by using GraphQL as the universal interface to any content provider, such as a platform like CoreMedia. This means you don’t have to provide content in a specific format, you can just point it to anything that speaks GraphQL.

That makes it a great match for CoreMedia’s headless capabilities, which exposes a fully-fledged GraphQL endpoint right out of the box. In fact, with just a few lines of configuration code, CoreMedia shows up as a content source in the development server’s GraphiQL tool that’s included in the Gatsby development server:

Code Gatsy Screenshot

Seamless Previews and Incremental Builds

By definition, static site generators build a complete set of static files representing pages and assets in one go. If you have a big web site with thousands or even millions of web pages, that process can take a while. And this negatively impacts your time-to-web.

Sure, some delay when publishing is acceptable in certain scenarios, but at CoreMedia we believe super-fast preview roundtrips are crucial when authoring content. We want users of CoreMedia Studio to be able to work fast. Making users wait for a preview to refresh when creating a complex campaign is not OK.

So we prototyped an integration that uses Gatsby to apply an incremental build strategy. This means that when content changes in the authoring environment, CoreMedia Studio instructs Gatsby to rebuild only the parts that really need rebuilding. And it does so by keeping track of dependencies between content items.

I’ll explain. Imagine you’re editing a landing page (P) that features two articles (A1 & A2) as teasers, each one linking to their respective full-page views. What happens when you make an edit to A1’s headline?

Well, you need to rebuild not only the A1 page but also P (but not A2). Since P shows A1’s headline in its teaser representation, P has a clear dependency on A1. Or to look at it another way, A1 has an incoming reference from P. On the other hand, if you only flip the positions of A1 and A2 in P, all you need to rebuild is P itself because neither A1 nor A2 depend on P. Got it?

Tracking content dependencies is not easy, but this capability has been a building block of CoreMedia since the beginning. So in our prototype, we just needed to teach our GraphQL endpoint to add a content item’s "references" to the response that contains the content. Check out a depiction of the result in the above GraphiQL screenshot.

The article "knows" that it depends on the picture being embedded, so when an editor changes something like the cropping, CoreMedia will rebuild the article webpage. That way, when the headless server detects a change in a content item, it can notify Gatsby of that change. Gatsby can then query the server about what to rebuild in addition to the changed content item itself.

Take a look at the result in the brief screencast below. On the left-hand side, you see CoreMedia Studio with its multi-preview selector displaying the Gatsby-powered preview next to the dynamically generated one. The console on the right-hand side is displaying Gatsby performing its magic as soon as we start editing. And if you look closely, you’ll see that regenerating the current web page takes Gatsby only a fraction of a second.

Everyone Can Win with CoreMedia Content Cloud

So static sites are not as outdated as you might think — especially when you pair them with modern frameworks and can easily integrate with them. Unlike CoreMedia, many pure headless CMS solutions often focus solely on the end user experience, neglecting the people in charge of creating the web sites.

Our example shows that choosing headless doesn’t have to mean content editors have to suffer through time-consuming authoring experiences. Everyone can win.

Take the Next Step with CoreMedia Content Cloud!

We'd love to get a dialogue going. Contact our experts and we'll schedule a demo.