Many researchers looking to share their results gravitate to dynamic websites where readers can enjoy a more customized experience. However, static websites offer a number of advantages that should be considered in your decision making.
Static websites as compared to dynamic websites are simpler, much less likely to become compromised, easier to maintain, migrate, and backup. There are now many tools available to ease the task of content generation in static websites, such as static website generators (Jekyll, Hugo, Eleventy, etc.), many of which can be combined with graphical user interfaces (GUI) and others which have GUIs built in, for example publii. Some functionality available in dynamic websites, primarily the ability to display custom content per visitor, for example shopping carts, bank balances, or tailored content are not possible with a static website. However, depending on the details of the dynamic components you need, it may be possible to either use third party tools (e.g. google forms, formspree.io, etc.), or save data in the visitor’s browser using cookies and javascript to perhaps provide some functionality similar to dynamic websites. If you don’t need dynamic functionality, or you can get the dynamic functionality you need from a third party, static websites can make your life a lot easier - especially in the long term maintenance phase of your site.
For a more detailed explanation keep reading.
So what is a static website and how does that compare with other options? There are two main categories of website - static and dynamic.
On a static website the content is created before someone visits the site and is the same for every visitor. By contrast, the content for a dynamic website is created programmatically when someone visits the website - meaning a program runs on the server to generate the page content from data, usually retrieved from a separate database program also running on the server. There are benefits and drawbacks to each of these two methods. Let’s cover the pros and cons of the dynamic website first.
Dynamic Websites
Dynamic websites allow some pretty cool functionality. For example it can have logins, and depending on the type of account the visitor has on the site, can allow them to edit and contribute to its content, design, and function. Content can be tailored to the specific individual - for example displaying your shopping cart from your last visit, your account balance, or messages sent to you from other visitors of the site.
The advent of dynamic websites allowed the development of a more participatory web, often referred to as Web 2.0, where the viewers of web content are also the generators of web content. Previously, websites were mostly hand crafted static HTML sites. However, there are some drawbacks to this high level of functionality.
Dynamic websites are necessarily more complex than static websites. They do more and so depend on more bits of code to work properly. Often these bits of code are written by many different groups and have become quite complex. As code complexity increases, there is a greater likelihood for problems in the code.
An even larger issue, however, is that these dynamic websites are almost always designed to allow editing through an interface accessible over the web. That often means that anyone anywhere can attempt to access the portions of the dynamic website that allow for the modification of the site, and thus also the server that is serving up the website. Often, attackers do not even care about accessing the content or data on these servers, but instead want to gain control over them to carry out attacks on larger sites using this server as a means to attack another site, or to help mask the attacker's origin by sending the attack through this server.
This means that those maintaining dynamic website content management systems (CMS) software must be very diligent in keeping them secure. In looking at the Critical Vulnerabilities and Exposures site (cvedetails.com) for some of the more popular CMSs (Wordpress, Drupal, Mediawiki, Joomla) we see about one to three CVEs a month. That means you need to be patching these sites somewhere between once a week and once a month to keep them secure. Plus, if you’re using any additional plugins or modules developed by third parties, you must ensure that those continue to function properly with each update. Finally, every few years these dynamic CMSs release a new major version, necessitating a migration of content, accounts, plugins etc. from one major version to another. All of this adds up to quite a bit of work, and stress, to keep dynamic websites secure.
Static Websites
Static websites on the other hand are static files. There is no code that runs on the server when the page is served up to the visitor’s browser. This means there is no opportunity for an attacker to gain access to the web server through vulnerabilities in the site's code. Javascript is often part of these sites, however, this runs on the visitor’s browser, not the server. Javascript allows dynamic interactions with the site (e.g. drop down menus, buttons changing what’s viewed etc.), but nothing runs or is modified on the web server. This is a huge security benefit, and means that keeping the site’s HTML generation software up to date is not a security concern.
The server hosting your static website still needs updates to its operating system and software, but that is a much simpler task than keeping the CMS, plugins, and modules all up-to-date and properly functioning with each other on dynamic websites.
In addition to these security benefits there are also performance benefits with static websites. Since there are no code or database queries executing on the web server, all that needs to be done is to return the contents of the requested page from a file on the web server. This means that with far fewer hardware resources, the server can accommodate many more site visitors at once.
Another common component of many websites is the search function. It is possible to perform searches of content of small and medium sized sites in the visitor’s browser using javascript with the lunr.js library. This is a good solution to the site search problem for static websites and is meant to replace more sophisticated search tools, such as apache solr, which run on the server rather than in the visitor’s web browser and would have difficulties integrating with static websites.
Over the life of a website it may need to be moved from one server to another. There are many reasons for this. One example is building a new web server with a more recent operating system. Since static websites are just a bunch of HTML, CSS, and Javascript files, you can just copy the files from one web server to another. There is no setting up of databases or php involved, no creating and moving database dumps, or installing and configuring newer versions of the CMS with the hope that all the plugins and modules previously used are still available and functioning correctly with the newer versions.
Backing up static websites is very similar to the migration process - just copy the files somewhere safe! Another nice way to backup static websites is with version control software and a cloud-based repository (e.g. Git + GitHub). With this method, there is an off-site backup that includes all changes to the site. As a bonus, GitHub also provides free static site hosting and supports the Jekyll static website generator directly so you might not even need to manage your own web server.
The Bottom Line
There are clearly some pretty substantial benefits to using static websites as opposed to dynamic websites. There are however, some cases where static websites just can’t provide the functionality needed. But with such great benefits you really need to question how much you need that functionality, or if there are ways to get it with a static website. If it does turn out that you really can’t use a static website, then you need to ensure you have the necessary resources to successfully manage a dynamic site.
