CMS Static Websites
By Philippe Bodart | Created on April 26, 2017
Choosing between a Git-based CMS or an API-driven CMS for managing and updating your Static Website
Problems dynamic websites build with f.ex. Wordpress are facing
Let’s start with web performance. Regardless of how well we optimize everything or how good of a job we do with with perceived performance, dynamic websites are SLOW. This is due to the amount of steps that have to take place in order to display the requested content everytime someone visits a web page. We’re also at a point where every website being built on Wordpress is being overwhelmingly loaded with plugins, scripts, and a ton of other overhead that just slows the crap out of what we ship to production. This is in addition to security concerns, expensive hosting, and the ever-changing landscape of different languages a developer must learn to build a website. So let’s rethink our approach to building dynamic websites and start from scratch static.
How Static Websites Differ
First, what’s a static website? Nope, not a new technology, static websites have been around for ages. That Dreamweaver website you created back in college? That’s a static website. A website made up of HTML pages with pre-populated content. When a browser requests the URL of a static page, the server returns the static page in it’s entirety. There aren’t calls to a database being made nor content being generated on the fly — the content is already there. That doesn’t mean we’re putting together every page by hand . There are different tools that address different layers of this technology stack.
Faster loading times
The fact that JAMstack websites don’t have to make any calls to a database makes the loading time exponentially quicker. Matt Biilmann, founder of Netlify, ran a test of the Smashing Magazine website (which currently runs on WordPress) against a static counterpart he cloned and deployed on Netlify. It resulted in a website that loaded six times faster than the original.
If you’re using a popular CMS, you know about the necessary security measures. This is mostly due to the login page being available to anyone with access to the website and some basic knowledge of the specific CMS. With a static website, a login page doesn’t exist. If you do integrate a headless CMS (more on what a headless CMS is further down) to your static website, tracking the website back to its CMS isn’t as straightforward as it is with a traditional CMS.
Front-End and CMS are Decoupled
You don’t have a CMS dictating the way you should structure your content and pages. Not having a CMS tied in to the presentation layer gives you the flexibility of creating anything you want on the front-end while using the API endpoints to pull in content.
Lower cost of scaling
We’re not dealing with expensive runtimes or complicated server setups — we’re only dealing with static files being served on the client side. For smaller sites, you can get away with cheap hosting as long as you pair it with a fast CDN.
Seamless developer experience
What Steps to take to take to build your Static Website
Step 1: Choose a Host & CDN
The beauty of static websites is that you’re able to host them anywhere. ANYWHERE. You don’t need a list of server requirements with a certain version of PHP or a specific database. All you need is a host that allows you serve HTML, CSS, and JS for a straightforward development workflow, especially when dealing with staging environments. I recently started playing around with the idea of moving to Amazon Web Services. I zipped up my website, uploaded it to their server, and boom, my website was ready to go live by just pointing the DNS. Because my website is static, I didn’t have to worry about transferring a database or server requirements. (It took me about 10 minutes to set this up.) Although you are going to enjoy the flexibility (and affordability) of hosting, specially with larger scale websites, you want to make sure that you’re using a host with a fast CDN to deliver your static files. You have a bunch of options:
Built from the ground up to host modern static websites, Netlify (they actually coined the term “JAMstack”) understands the static concept and provide a full suite of open source products that are focused around static websites (sorta like the WP Engine of static websites). They’re also the hosting platform behind the new redesign of Smashing Magazine. Plans are relatively affordable but if you have an open source project, they’ll host it for free.
Amazon Web Services (AWS) S3
Amazon S3 is a utility storage service that’s used for backups and content storage as well as static websites. This is an ideal hosting setup for a JAMstack website. If it’s your first time creating an AWS account, they’ll provide free hosting for the first 12 months.
Using the full capabilities of the Netlify network, WebriQ provides you with a fully self-contained Software-as-a-Service for building and managing your Static Websites. Building tools, content management tools, continuous deployment through Github, SSL certificates are just a couple of important features that come standard with any service. Pricing is quite affordable and starts at $15 per month for a fully managed service. Free service is available at WEBRIQ APP
Step 2: Decide on a Static Site Generator
In order to avoid creating static html pages manually, you’re going to need a sturdy static site generator. There are 457 static site generators to choose from. But I’ll help you narrow down the list to the top three contenders below.
Built on Ruby and using Liquid as a templating engine; Jekyll was created eight years ago when Github founder, Tom Preston-Werner, was looking to write his own blogging engine. A very well documented SSG with the support of a massive community. It has been the de facto choice for static site generators since static websites began regaining popularity around four to five years ago. Although Jekyll is simple to setup, the workflow begins slow down when working on larger websites; static pages will still load fast once on the server, but the time for them to get generated locally during development starts becoming painful.
Built on GoLang using it’s own templating engine; Hugo was created in 2013 by Steve Francia, Docker’s Chief Operator. Although relatively young, Hugo has the support of Smashing Magazine and its immense community; Smashing Magazine announced that they would be ditching WordPress for Hugo in the new iteration of their website. The main reason for choosing Hugo as their SSG was the speed in which Hugo generates its pages. This was something that co-founder, Vitaly Friedman, needed to carefully take into consideration for the large number of posts the website has published since 2006.
Why is WebriQ using Roots?
The short answer is because roots was built very specifically for static site builds, so it's cleaner and better than general purpose build tools, since it's specialized to that purpose. The longer answer is that it's a qualitative thing. Much like people would ask "Why should I use snapchat when I can just text a photo" or "Why should I use slack when I already have hipchat?", there is no logical answer other than that the experience is different, and in my opinion, much better -- tailored exactly to what you need. So just try it, and you just might find that you really like it.
As awesome as Static Site Generators are, there are a few problems rooted in the fact that it gets a bit complex for the everyday admin user that’s just looking to publish content. It’s unrealistic for us in the agency world to get non-technical team members and clients to publish content and deploy websites via CLI. In order to make this appealing to the masses, we need a dynamic layer in our current stack that provides a friendly admin UI…
Step 3: Select a headless CMS
Choosing between a Git-based CMS or an API-driven CMS
With a Git-based CMS you can publish content every time you push changes to Git, allowing for a seamless development workflow. This approach is a bit difficult to scale with content that you want to publish across different platforms, but it will allow for you to have a purely static website. Since it runs on Git, you won’t have a problem finding an open source CMS to work with.
With an API-driven CMS, you’re creating content that will be strictly delivered via APIs. Although you won’t be able to keep track of content changes through Git, you’ll be able to scale your content through flexible APIs. But since you are working on a platform that hosts these APIs (server bandwidth ain’t cheap) these tend to not be open-sourced and rather pricey, but some offer freemium pricing models.
Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.
Exciting times for all front-end developers and for business owners who want to simplify their web operations with secure, reliable and ultra fast technologies.