Last night The Practical Dev had their periodic #DevDiscuss Twitter chat and the topic was web performance. I brought up static sites as something to consider and then got into a discussion of the benefits and limitations of static site generators. The entire thread was interesting but seemed to hinge partly on one important question: what makes a static site…static? More to the point, what generally accepted criteria can we use to classify a web site as "static" as opposed to "dynamic"? This question got me thinking and I realized that the issue is a little more complicated than it might seem, especially for modern static site generation.

Definition

I have no idea if there is a single generally accepted definition of "static site". It's probably one of those terms that means different things to different people. Here's the best I could come up with:

The web server does not perform any rendering as the result of a real-time request.

Let's break that down a bit.

First I mention the web server. Whether a site is static or not is highly, if not solely, dependent on what the web server is doing. Anything in front of the web server like caching infrastructure and anything behind the web server like a database or API layer doesn't change the static nature of a site. It's important to note that when I say "web server" I'm primarily talking about the bit that is responsible for returning content to the client. Services like APIs may also reside on the same web server or even in the same process, but that's not what I mean here.

Then I specify rendering. For a site to be static, the web server can do lots of things but it must not render any of the pages or content that are being returned to the client. If the web server needs to run code to generate a view for a given request then it's probably not a static site. On the other hand, if the views are pre-rendered but stored in a database then I would say that qualifies since the file system itself could be considered just one type of view storage database (though this comparison is certainly up for debate). In any case, if your web server is running code, fetching data other than views from a database, or otherwise manipulating the content being sent to the client it's probably not a static site.

Finally I narrow the scope to real-time requests. This is an important distinction because some static generators may also be the web server. The key here is that the web server must not do rendering on the fly. If the web server is also the generator and it's rendering all views beforehand and storing the result for real-time retrieval later then I would say it probably qualifies. For example, many static site generators like Jekyll and Hugo ship with a built-in web server for previewing the generated site. These are real web servers and could be exposed to the network (though they're not necessarily "production grade" so I wouldn't actually do that if I were you). Even though the web server is the generator, there's no doubt that the sites created by these generators are static since the view generation is being done beforehand and merely stored in the file system for later retrieval in response to a request.

Examples

Now that I've defined "static site" let's look at some examples.

First off, let's consider a blog hosted on GitHub Pages that uses it's built-in Jekyll generation. I'd guess most people would say that's clearly a static site. But what if the blog also uses Disqus for comments? In that case, JavaScript on the client is requesting data from a service, which is probably using a database, and which is returning dynamic results in response to the request. That makes the site dynamic, right? I don't tend to think so. Note that earlier I said there was a distinction between the web server as it pertains to returning content to the client and other, non-content centric services or servers. In this case, whether it's a hosted service like Disqus or you're running the service and server yourself, as long as it's returning data and not content I'd still consider the site to be static. That holds for all sorts of dynamic capabilities like searching, form submission, and data aggregation. This is a good approach to making a site static while still providing dynamic functionality. If you can isolate those aspects of the site that require run-time request-based data and provide that data through a service, JavaScript on the client can be used to fetch and render the data taking that burden off the web server and maintaining a static site posture.

What about a site where the generator pulls data from a database? For example, consider a headless CMS (a Content Management System that only worries about the content and not the presentation). The CMS probably stores it's data in a database and the interface content editors use would probably be considered a dynamic web application, but what about a site that uses that content during a static generation process? The resulting site would be static because it doesn't matter what happens during the generation process as long as the end result is a set of static content files. This is one of the areas where I think there's a lot of confusion and misunderstanding about static generation. Many of the static generators today primarily take templated input files along with some sort of metadata, apply rendering engines to the input files using the metadata, and output the results. But that's not to say the static generation concept couldn't be applied for much more sophisticated generation processes. I'd venture many sites that are currently dynamically rendered could be statically generated instead. As long as you can fully bound the potential requests and it's realistic to generate static pages for all possible combinations of data, it's a candidate for static generation. That said, static generation may not be the best approach in all cases, but it's at least worth recognizing as a possibility and considering the tradeoffs.

Finally let's look at the frequency of generation. One way to address user-provided data in a static site is to frequently regenerate the site as the result of certain events. For example, a commenting system on a static site may provide user comments to a service which stores them in a database. Then a change hook notifies the static generator to generate and redeploy the site with the new comment. This could happen very frequently, or even continuously without a hook at all. I've also seen this approach used to handle time-based changes to the site. For example, you may write a blog post that isn't supposed to go live for another few weeks. This can be addressed with automatic periodic regeneration. If you automatically regenerate and deploy the site every night at midnight, then any future-dated posts will go live at the appropriate time when the generation process is run and their published dates become active. In all cases, frequent or periodic regeneration of a static site does not disqualify it from being static. As with the way data for the generation process is obtained, the frequency or mechanism by which generation takes place is also irrelevant.

Conclusion

For those who maintain that "static" means just that, and anything going on that extends beyond returning HTML and other resources from a file system to the client doesn't count, perhaps you're right. That's where the JAMstack philosophy comes in. The notion is that as dynamic sites have a "stack" so do static sites, and the static stack consists of JavaScript, APIs, and Markup (HTML). If you look at my examples above, many are applications of the JAMstack and I'm considering them static sites. Granted, these ideas aren't new. The static site community has been moving towards this concept for a while, but it's only recently that the JAMstack term was coined and the community has mostly rallied around it's usage and principles. And perhaps that's where my own definition of "static site" might go beyond what you typically think of. When I think "static" I think of the JAMstack.

As I qualified this post in the beginning, this is all my personal opinion on the matter. I'm interested to hear if you think my definition is too narrow, too broad, or if I missed some important aspect entirely. I also want to close by saying that like anything, it is important to pick the most beneficial tool for the job. I advocate for static sites a lot because I think they're more broadly applicable than people given them credit for and the subsequent benefits of applying them to those situations are worthwhile. On the other hand, there are lots of sites for which static generation as I've defined it above is a terrible fit. There is never "one true way", only alternatives and tradeoffs. The more you understand those alternatives and tradeoffs, and how they apply to your specific problem, the better equipped you'll be to select the best one. Defining the distinction between alternatives is a good first step towards understanding them. So in that spirit, I hope this was useful.