Static vs. dynamic websites: why we migrated from WordPress to a static website

Recently, we migrated our website from WordPress to a new static website. WordPress is one of the most widely used free Content Management Systems (CMS). With this homepage builder, you can easily build a blog or a dynamic website without much programming effort. We have now migrated from a dynamic website built in WordPress and launched our new static website. But what is the difference at all and what advantages and disadvantages offer both versions of websites? This is what we would like to shed light on in this blog article.

What are dynamic and static websites?

In general, a distinction can be made between dynamic and static websites. A static website, as the name suggests, is completely built once and then delivered and not rebuilt again until the next build. Each page and subpage of a static website is programmed individually and then also loaded individually from the server. With dynamic websites, each requested page that a user wants to visit can be rebuilt with each request. The basic structure of dynamic websites is the same, only the content is loaded from a database and built by a page generator on the server for a request. Of course, the result can also be cached and does not have to be rebuilt every time.

What are the advantages and disadvantages?

At OpenProject we have decided to migrate from a dynamic site to a static site. Therefore, we would like to take a closer look at the advantages and, of course, the associated disadvantages.

Advantages of a static website

• Data security: One of the big advantages of a static website is data security. WordPress as one of the most used and very widespread CMS systems. Due to its distribution, it is one of the most attacked sites. Security vulnerabilities can mean a great damage for the website owners. If no CMS is used, and no (active) server is required, there is much less attack surface. The server only delivers the files.
• Privacy: with a static website, no user data is shared with the hosting service. There is no user tracking from e.g., hosting providers, who often use it for free data analysis and user tracking. The privacy aspect is of course increased if you don’t host your static site with big services like Amazon.
• Individualization: Instead of a generic “construction kit” page builder, where each single element is always delivered, a static website is a tailor-made solution. Of course, this again includes advantages and disadvantages at the same time. Using a page builder, ready-made web pages can be created quickly and easily. These pages are then largely generic and often drag along a lot of elements and styles which you actually do not need for your own website. This often has a great impact on the speed of a page. The static website is built to measure, only what I really need is developed.
• Speed: The topic of individualization already deals with the speed of a static page. Here only what is needed is delivered. This usually means much faster loading times. The content is not loaded on-demand from a database, but the pages are delivered directly. Image optimizations run beforehand (for us in advance only once) and are then delivered. This means that different variants for data formats for the images are generated beforehand. In comparison, many CMS systems do this on the fly.
• SEO: A faster page also has influence on my search engine optimization (SEO) because page speed and speed of delivery are important ranking factors.
• Lower data volume: The point individualization already indirectly addresses the lower data volume for static websites, since by default only what is needed for a page is developed. In a CMS like WordPress, for example, virtually each HTML element has an ID; each row, column, cell, each heading. With a static website only the elements that need it, e.g. the headings, get an ID. This saves on the entire page a large amount of data that would otherwise have to be delivered each time.
• More climate friendly: A static website has significantly less demand on servers. The smaller amounts of data described above lead to less demand on servers (e.g. for processors), which in turn lead to less power consumption. Because of the lower data volumes, much smaller, more power-efficient servers can be chosen.
• Staff: The knowledge of programming a static website is more generic and not a specific application knowledge (as for example for deeper domain WordPress knowledge). It usually requires general web development.
• Scaling: A content delivery network (CDN) is not a problem with a static website. The loading time is much faster. In contrast, it is much more difficult to build a CDN for a dynamic site, for example.
• Operating costs: The operating costs of a static site are often significantly lower than those of a dynamic site. Here, complex database management and the pay per amount of view model are relatively widespread. In contrast, simple file hosting is often sufficient for static sites. Dynamic sites are quite demanding and usually risky to host yourself. Here, professionals with insider knowledge, e.g. for WordPress, would often be needed to keep the site secure. Otherwise, you quickly have a security incident. The external services for hosting must be paid.
  Of course, static websites do not always have to be completely static but can also include content from dynamic servers. In our case, for example, this is the case with the careers page, which pulls live and current data from our hiring platform.

Disadvantages of a static website

• Cost: The cost savings you have as described above brings with it an increase in cost on other sides. However, this is usually lower overall, for example, due to higher costs for programming needs.
• No dynamic features: A static website has no or few dynamic features such as blog comments, login area for user area. Dynamic, individual functions are not easily possible.
• Technical hurdles: A static website can have higher technical hurdles, e.g. knowledge of Markdown, GIT, etc. especially for less tech-savvy content editors or they require again backend costs. Creating and maintaining content is much more difficult. In the CMS, on the other hand, the creation and editing of content is simple and possible without programming. In this case, it is the developers’ job not only to build the site, but also to keep it usable, and to provide support for non-technical people. Alternatively, a CMS can be set up in the backend of a static page to make it easier to be used and then build a static front page from it again.
• Slower updates: Changes to a static site are much slower and usually cannot be viewed immediately, there are no direct preview functions. Even with a fast site builder, it takes up to half an hour for a change to go live. Changes still have to go through the deploy systems. With a dynamic site, there is often a direct preview function. Changes are virtually live at the push of a button.

Applies to both

• Technical dept & tool decisions: This is relevant for both variants. Even for static pages, technical dependencies, such as a site builder, may exist, but usually do not represent a security risk. Any tool decision is therefore made at the current time and may turn out not to be the right one in the future. It is often difficult to assess what may work well in the future.

Why we migrated from WordPress to a static site?

In summary, a static site is not suitable for very many changes in a short period of time, such as an editorial system with many updates or a blog with frequent comments. It does not scale with many updates and changes in a short time. For OpenProject, the website content does not change on a daily basis. The topics of security and privacy are very important to us. Other advantages like speed were also very relevant. Therefore, the change to a static website was advantageous for OpenProject.

How we proceeded with the migration?

After we decided to switch from WordPress to a static site, we first manually rebuilt all existing pages from WordPress. For this, the templates now had to be rebuilt with Ruby for our site builder. Our website is maintained in a GitHub repository and built with Middleman. The WordPress templates and styles were largely rebuilt, and the superfluous, generic stuff was left out, e.g. only the elements that need it, such as headings, received an ID. In the next step we defined site wide widgets, which are now being used uniformly for all pages. This further harmonized the website. The website’s content is created in English. For the translation we integrated the translation service CrowdIn. Here we send a .yml translation file to CrowdIn, which is then translated. The translations then end up back in the site builder. We have also integrated the documentation more into the website. The docs are also generated with Middleman. For the search, we no longer use an external service. The search is now included in the site builder, a .json file, which contains compressed all content to be searched for. All searches run on the user’s browser.

For OpenProject, switching from WordPress to a static website was a win!