Client-Heavy vs CMS (server-heavy) Sustainability


In the previous couple of posts, I looked at areas where CMS-based websites might differ from sites built by other means, in terms of their sustainability. Looking at Standard and Permaculture frameworks, it seems to me that there are a few issues that strongly determine the sustainability of CMS systems, compared to other websites.

But I realized that answering the questions about CMS sustainability required a “compared to what?” statment. So, we must first define “what are CMS systems in competition with? The answer is “client-heavy” sites. These include:

  1. Websites with all their “state” data and logic processing in client-side JavaScript frameworks, like EmberJS and Angular JS
  2. Websites wrapped in native code for delivery as an “app” using Apache Cordova
  3. Native apps, written in Object-C, Java, Swift, and others

So, in considering the sustainability of CMS systems, we need to compare them to “client-heavy” solutions. What is the key differentiator?

  • Client-side solutions put all the logic and data on the client, with occasional server trips
  • Server-side solutions (CMS) put all the logic and data on the server, with occasional client modification

We can see this difference by comparing a typical client-heavy app to a CMS. Web-based games written in HTML, CSS, and JavaScript are a good example of the former, while WordPress is a good example of the latter. In the case of a game, all the processing happens in the browser – the web page is delivered in a raw form and extensively modified by JavaScript to produce the game. Occasionally, the game might jump to the server for processing (e.g. to post high scores of top gamers) but generally all the action will be client-side. In fact, many client-heavy frameworks try to minimize the complexity of the server down to a barebones API, with elaborate client-side processing of the data.

In contrast, the server-side CMS will create everything before it leaves the server. The downloaded page, if it needs modification, will be modified before it is pulled down. If pages need to be altered, they will be altered immediately, and directly in HTML and CSS markup. A client-heavy app might just ignore a CSS file, but an efficient CMS file will use server-side code to make sure it is never downloaded in the first place.

Opera Mini

Reflecting on this aspect of CMS sustainability, one can see that Opera Mini was a major sustainability player in the 2000s. Instead of client-side rendering the Opera Mini browser linked to a server which “predigested” the incoming markup and code, and provided a rough rendering. So, while the local Opera Mini browser may barely have supported JavaScript, it was possible to execute JS on the server side to do preliminary rendering, feature detection, and the like.

In time, however, this method has fallen out of favor. With the slow stabilization of web standards, and better processing on mobile clients, the need for server-everything solutions like Opera Mini have diminished.

What’s the More Sustainable Solution?

We can compare client-heavy (Angular, Ember + API) to server-heavy (CMS) solutions to a real-world example – the relative sustainability of an all-electric car fleet, versus a fleet of hybrids. We’re assuming that energy generation (for the near-term) would still require burning natural gas or coal.

In this case, the all-electric fleet is not automatically “green.” In fact, it would be easy to build a system that created more pollution than the fossil-fuel burning fleet it replaces. The reason is inefficiency. An all-electric system would require very large central power plants, distributing vastly more electricity than today over an enhanced electrical grid. In addition, there would be a minor energy loss from tranmission (~7%), and a major loss (~40%) for generating the electricity at the plant, and charging the batteries in the electric cars.

So, in the first analysis, you would burn more fossil fuel to run an all-electric fleet. It’s actually more efficient to get the energy by locally burning the fuel, since you don’t have the conversion and transmission losses associated with central plant distribution.

(oh, you might be able to run your house with solar panels on the roof, but you couldn’t get enough for your car without taking over your neighbor’s lot).

However, even if we assume that we make the big, central plants solar (unlikely in the near-term) we still might get a benefit. In the current car fleet, there is a lot of pollution produced when the fuel is burned. Part of it is removed by each car, but a big central plant could implement “economy of scale” to do a much better job of reducing pollution. For example, it would nearly impossible for a car to “sequester” waste CO2 in the exhaust, but a central power plant could do exactly that.

In contrast, a world with hybrids has improves on the pure electric solution in some ways. While you are burning some fossil fuel, it is less than current non-hybrids. You don’t have the loss of energy caused by power line transmission or charging a huge battery. Instead, you’re scavenging some of the power from the fossil fuel when you use regenerative braking (charging the battery to slow down the car).

So, unless you can build awesome centralized power plants with very efficient pollution control, and update the electric grid to handle 10-100x more power than it does today, hybrids are the best solution. In the long-run, central plants run completely by renewables might trump hybrid increased efficiency, but a solar-only solution for automobiles is a long ways off, despite the techno-euphoria common in “green” thinking.

The Virtual Ecosystem

So how does this map onto Sustainable Virtual Design? Think of data processing replacing electricity in the above example, and you’ll see the comparison.

A central power plant is a bit like pushing all your logic up to the server cloud, like a classic CMS. Since server-side electricity is typically “greener” than the client, and data processing can be optimized via “cloud” services, each bit is more sustainable than the typical client-side solution. In contrast, client-side code executes on a variety of systems, some inefficient, and the electricity from the local utility is typically not as “green” as the server cloud power.

So, if I just duplicate the logic of the server on the client, I end up with a less green solution for my websites and apps.

However, local “burning” of code might still be more sustainable in some cases, being the equivalent of a hybrid fleet. If the client-side code is more flexible and tailored to the user, it might be more efficient. A server (like those Opera Mini servers) has to deliver a “one size fits all” experience. In contrast, client-side code can burn only the bits it needs to create a customized experience. On average, there will be less waste – less transmission of data and assets through the network, and less computation that doesn’t benefit the user.

How Sustainable Thinking can Drive Our Platform Choice 

Thinking this way, we can draw some conclusions:

  1. A server-side solution will be “greener” by default, due to greater efficiency.
  2. Client-heavy solutions using JavaScripts can be greener – but only if they optimize for specific users, and minimize server traffic and computation.
  3. This is a direction that isn’t typically defined by Angular or Ember projects, but it could be added.
  4. In other words, client-heavy solutions need more personalization.
  5. Client-heavy solutions would also benefit by improved, client-side definitions for SEO

Green Ingredients

A client-heavy framework might be just the place to invoke “green ingredients” design strategy. If you check elsewhere on this blog, you’ll see the concept.

  1. Define design strategies, tools, widgets, libraries, workflow practices, and code documentation as an “ingredient” in your project
  2. Score the “green-ness” of each ingredient. If you can quantify, do so, otherwise, score as “green” or “less green”
  3. To improve sustainability during project development, swap in “greener” ingredients

So, imagine you’re switching from a CMS to a local library that does all the computing work. Each time you add a widget, Ui interface design pattern or block of code that makes code run more efficiently and specifically than it would in a “one size fits all” cloud CMS, score a green hit. If the code burns more cycles, score down, since server bits are almost always greener.

Here’s an example similar to that in my recent talk at SustainableUX:

Ingredient 1st QTR 2nd QTR 3nd QTR 4th QTR
WPO 1st Load Score (Webpagetest.com)  3.5  3.3  3.0  2.8
Sustainability Score (Ecograder.com)  44  51  52  56
Swap HTML5 local JS library for HTML4 Support in an (outdated CMS)  X
Swap TDD Coding for Individual coding in in client-side library X
Store page customizations in LocalStorage, and only go to the server is the user requests it  X
Cache assets locally, and use your JS framework to load on demand  X
Reduce CMS access to a REST API for the client-side library  X
Implement a good SEO strategy in the client, pushing back relevant SEO to the server for later download  X
Swap Green Host for AWS Cloud for the server-side X

The debate between CMS versus client-heavy frameworks isn’t about to go away – but thinking in terms of sustainability might be the ticket to deciding which approach to use in your projects.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s