When PINT begins a web development project with a client, a major decision must be made: what type of website are we building?
In addition to the content we want to include on the site, the infrastructure on which we want to host it and the technologies we want to use to build it, we must also determine how the site will be published.
1. Will the site require frequent updates by non-developer contributors?
2. Does it need to be highly-performant?
3. Will it be viewed by consumers on their mobile devices or is it a desktop application for a large corporate team?
If the website requires regular editing and new content, it is likely that PINT will employ a Content Management System (CMS). A CMS is an application that allows contributors to do things like upload files, edit content and view updates before publication. Examples of popular CMSs include Wordpress, Drupal and other open source and proprietary tools.
If the website is not intended for frequent updates or if the client intends on contacting PINT for updates, then PINT may opt to build the site as a collection of static files generated by a build and deployment tool from a Git (version-controlled) code repository.
If that sounds like a lot of tech jargon, that’s because it is.
Think of the generated, static site as a working copy published from the most up-to-date version of the website.
The most apt analogy is that this is the digital, web-based equivalent of publishing and republishing print media from a typesetting machine: each time the website is changed (the typesetting machine is reconfigured) your generator fires off a new copy of the site and your build/deploy process places it in the server environment.
Each of these site structures has its benefits and drawbacks across performance, security, ease of use, features, maintainability, and reliability, which we’ll cover in some detail below.
For end users loading a website on a mobile device or another, less-powerful machine, website performance is a critical issue. In these situations, a static site may be preferable because static sites are fast by default. Whereas a Content Management System needs to assemble the website from separate assets and components for download at the time of request, static sites have no server-side processing components.
Static Site Performance vs. CMS Site Performance
In viewing a static site, page load performance is entirely dependent on how fast a device can download and render the content. Since the user downloads the content from a static site and a CMS site at the same speed, the main performance factor that separates the two is that server-side processing and the non-zero server-side processing time of a CMS means it will always be slower than the static site by an amount equal to the time it takes the CMS to do the server-side processing.
However, there are ways to speed up that server-side processing, or even eliminate it entirely. By using a CDN (content distribution network) like CloudFlare, you can cache the compiled content generated by the server-side processing and serve it as if it were a static webpage.
The CDN thus eliminates the server-side processing and makes the page load just as fast as a static site, with the drawback that it only works well on high-traffic pages that are frequently accessed and, therefore, cached. In this way we can speed up a homepage or landing page quite easily, but less-trafficked pages likely won't be cached for most new visitors.
So we’ve seen that static sites are fast by default on every page, but CMS sites can be made just as fast on high-traffic pages. Other pages on a CMS site won't necessarily be slow, but they won't be nearly as fast as the static site pages.
Security is a major concern for most web properties, and generally the most vulnerable points of a site or application are the areas where server logic interacts with databases in which sensitive content is stored.
Static Site Security
Since static sites have no server-side processing and generally have fewer moving parts, they therefore present a smaller attack surface to malicious agents. In fact, when using a static site generator the biggest security risk present is an attacker compromising the version control system you use to build and update the site.
Whether that version control system is GitHub, GitLab, or Bitbucket, if that code repository is kept secure, the site or application is generally safe from nearly all security issues.
CMS Site Security
On the other hand, CMS-based sites have a much larger attack surface that needs to be protected. Keeping a CMS secure involves constantly patching the core CMS application and any plugins, securing any login or admin pages, and having a good backup system in place to restore a site to working order in the event that it does get hacked.
Common Content Management Systems like WordPress and Drupal are huge targets for attackers and any sites built on those platforms are constantly being attacked by automated tools which probe known points of weaknesses in search of sites that haven't been maintained properly. This is the reason that many WordPress or Drupal hosting services will automatically apply any security updates to the core CMS as soon as they are released.
There's really no competition here. Static sites are simply more secure and easier to host.
Ease of Use
Content Management Systems
Content Management Systems first rose to popularity because of how easy they made it to create and maintain content and publish it on a webpage. They have WYSIWYG editors that provide a "What You See Is What You Get" content preview as well as an intuitive editing interface with buttons for typical functions text decorations such as bold, italics, inserted images, etc.
Content Management Systems also provide tools to categorize content and build navigation bars and topic-based pages dynamically based on those categories.
Additionally, any functionality that isn't present in your CMS can likely be added by installing the appropriate plugin.
For example, most Content Management Systems have plugins that enforce SEO best practices on content and help you fix any SEO related issues. Adding the same functionality to a statically-generated site is more difficult and requires a higher level of technical ability.
Static Site Generators
Static site generators are also relatively easy to use, with a couple of caveats.
While developers often prefer working with static site generators for their ease of use and the freedom they provide in precision formatting (which often isn't possible with the WYSIWYG editors found in most Content Management Systems), most static site generators also require the content producer to know the markup language their generator uses, which is usually Markdown and/or HTML.
While basic Markdown is pretty simple and anyone should be able to be productive with it, it will likely require a little training for those who are unfamiliar with the syntax.
In addition to learning a new markup language, someone on the production team will also need to learn to handle the Git operations required to publish or revert changes from within the GitHub/GitLab/Bitbucket code repository.
This is technically challenging in comparison to publishing or reverting changes in a CMS with the push of a simple button.
Takeaway: Ease of Use
If your website is going to be managed by technical users who already know Git and Markdown/HTML, then they might prefer working with a static site generator.
Otherwise, a CMS-driven site will be easier to use for most people and it will also handle the heavy lifting of updating navigation, updating category pages, and other simple tasks that are prone to human error.
One of the primary strengths of CMS-based sites is that they include a ton of functionality out of the box, whereas static site generators are severely minimalist.
A lot of common web functionality is dependent on having a database, or is made easier by having access to server-side processing.
Here are some common use cases which are handled easily by a CMS, but which are challenging with a static site generator:
- User Comments or Reviews - If a site needs to accept input from users such as comments, reviews, surveys, or similar, the site will need a database to store them. In order to get this functionality on a static site, an integration with a third party service is required.
- User Registration - If a site needs to allow users to sign up to gain access to downloads or newsletters, then a database will also be required, similarly necessitating an integration with a third party service to get this functionality on a static site.
- Multiple Authors - If multiple people will create and edit content for the site, they’ll all need to be familiar with how Git works and how to use a branching workflow, as well as HTML/Markdown. In a CMS, this is not a problem and users are typically managed with an account system.
- Large Sites with Many Pages - A marketing or brochure site with a large product catalog that requires management of many product details or the performance of any sort of bulk edit will be time consuming on a static site since it may require editing a large number of pages. The same operation in a CMS would likely be a few button presses on a single page.
In addition to having a lot of functionality built-in, Content Management Systems also make it easy to add or modify functionality. It’s often as simple as installing a plugin. Some common plugins that most sites use are a SEO best practices plugin (formerly mentioned in the ease of use section), plugins to make image sliders and contact forms, image compression plugins, and plugins that provide management of redirects.
Static Site Generators Functionality
Most static site generators also have a plugin system but none of them have the extensive library of plugins that WordPress or Drupal have available. Of course, any functionality that can not be found in a plugin can be added with some custom development work, but that is going to be much more expensive to build and maintain than installing a third party plugin.
In general, a CMS will include everything needed to build a website, while a statically generated site will require integrations with third party services or extensive, custom development to interact with users. While both systems can be extended with plugins, pre-built plugins to fit the site’s needs are much more likely to be found using a common CMS like WordPress or Drupal.
Cost of Ownership
Static sites are easy and cheap to host because they don’t need any server-side processing. Most statically-generated sites keep their raw content in a version control system like GitHub, GitLab, or Bitbucket and then have a build process that runs the static site generator and publishes the generated files to a service like GitHub/GitLab Pages, or to a static file hosting service like Amazon S3.
This allows static sites to be hosted for a small monthly fee. However, sometimes dynamic content or functionality is needed on the site and it’s important to include the costs of commenting platforms, or contact form to email services in the total costs of ownership.
Contact forms and commenting systems require some type of server-side processing, which Content Management Systems already have and can usually provide that extra functionality for free.
However, that need to have server-side processing means that a CMS can’t be hosted on low-cost, static file hosting services. The CMS will have to be hosted on a server and the Content Management Systems and the servers that they run on need to be patched and maintained constantly to be kept secure.
PINT recommends that sites be hosted on a managed hosting platform specific to the CMS and that hosting platform should take the burden of server maintenance, leaving PINT or the site management team responsible for only the CMS and plugin updates.
Static Site Generators produce some of the most reliable sites on the internet because they have so few moving parts.
There’s very little that can break, and all the content is version controlled with limitless revisions, so restoration of any content that is broken or deleted is performed quite easily as long as the site manager understands Git. If the team isn’t knowledgeable in Git, restoring content to a working state can be more difficult, but still possible.
Most common Content Management Systems do allow content revisions, but having a large number of revisions hurts performance in those systems so most experts recommend limiting the maximum number of revisions per page to 5 or fewer, and managed hosting services typically disable revisions entirely.
In that case, site managers have to rely on full site backups to restore content, and restoring full site backups is a much more involved process than simply reverting a single page.
So what have we learned?
As we’ve seen, there are a number of tradeoffs to using both Content Management Systems and Static Site Generators.
The choice of either option will be dependent on the requirements of the website or application, the capabilities of its maintainers, the allocation of resources to maintenance and security and the value of site performance in comparison.
All of these should be considered at project conception and PINT makes sure to weigh the costs and benefits of each before advising our clients on which to choose.