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?

Amazon Homepage in 1995 Screenshot

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

Not surprisingly, things have changed since then. Specifically, sophisticated dynamic web frameworks have evolved that add a lot more excitement to the experience now.

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


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 (i.e. “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 things like personalization, gated content and A/B testing (i.e. features traditionally asking for server-side dynamics): These can be implemented by applying client-side techniques from modern JavaScript 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.


So let’s talk about the cost factor.

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 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 static files, 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 the 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.)


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

Gatsby made an impressive debut in 2019 on,  instantly becoming one of the most interesting backend 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 components as main building blocks, automatically applying hyper-efficient
client-side techniques that make the end result blazingly 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, CoreMedia shows up as a content source in the development server’s GraphiQL tool that’s included in the Gatsby development server:

Gatsby Development Server Screenshot


By definition, static site generators build a complete set of static files representing pages and assets in one go. If you have a big site with thousands (or even millions) of 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 when authoring content are crucial. We want users of CoreMedia Studio to be
able to work fast. Having to constantly wait for a preview to refresh when you’re 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 re-build
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 (however 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 in fact 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 that when an editor changes something like the cropping CoreMedia will rebuild the article page. That way, when the headless server
detects a change in a content item, it can notify Gatsby of that change and Gatsby in turn 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 showing the Gatsby-powered preview next to the dynamically generated one. The console on the right-hand side shows Gatsby doing its magic as soon as we start editing. And if you look closely, you’ll see that regenerating the current page takes Gatsby only a fraction of a second.





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. As opposed to CoreMedia, the pure headless CMS solutions out there often focus solely on the end user experience, neglecting the people in charge of creating it.

But our example shows that choosing headless doesn’t have to mean content editors have to suffer through bad authoring experiences. Everyone can win.


About the Author

As VP Engineering, Tobias Stadelmaier leads CoreMedia’s engineering department, helping our highly motivated team of experts to develop great CoreMedia products. Responding swiftly to customer requirements and adapting nimbly to changes in the market, Tobias and his team are proud of their record of delivering customer-ready innovations. Tobias started his career at CoreMedia in 2001 as a Technical Consultant and worked for three years as a Delivery / Engagement Manager and Product Owner. After a detour into the games industry as a Senior Product Owner, he returned to CoreMedia in Summer 2016. Tobias Stadelmaier holds a degree in Political Science from the University of Bamberg, Germany.