We started looking into the Jamstack architecture (specifically Jekyll) around 2019, when the Gutenberg block editor changed WordPress. Building sites using Jamstack has many advantages, including from the perspective of sustainability. Jamstack uses only what’s needed for a given website, reducing its energy impact. More of our clients are requesting Jamstack-based sites, and we think the demand will continue to grow.
Jamstack is changing the way we build websites, and we want to share the combination of technologies we use.
What is Jamstack?
The Jamstack architecture is the opposite of an “all-in-one” approach. Instead of asking one service/tool to take care of everything from managing copy to ecommerce, Jamstack allows developers to appoint expertly designed services for each job and enables them to work together.
The community of developers using the Jamstack architecture is growing rapidly. From software, ecommerce, and retail, to informational websites, the community is using the approach in various industries for audiences into the millions.
Example: Throughout this article, let’s use the fictional retail company Best Fair Trade Coffee to illustrate how Jamstack would work to build its website. The site has an ecommerce component where it sells its products online, a blog about coffee, and a way to sign up for weekly news about specials and new coffee varieties.
A closer look at the tools and services we use
Image caption: We make content edits in CloudCannon. CloudCannon then updates the code with the content edits within the GitHub repository (file storage). (The GitHub repository is backed up with the new code updates.) A developer can also make changes to the code directly in the GitHub repository. Whenever there are new changes to the repository, Netlify detects it, and brings the changes to the live website.
GitHub
GitHub is a backbone of the coding/programming community. Without getting technical, it’s a service for code repositories. Millions of repositories exist on GitHub (a Microsoft product) and are used in nearly as many ways.
We use a (private) repository to store website code; from there, we can connect different services to do different things with the code. It’s like the central hub.
Example: At Best Fair Trade Coffee, the web development team and the IT team would need access to the GitHub repository. After the website launch, this is where the two teams may need to make specific updates to the repository.
Jekyll
Jekyll is what is known as a static site generator and is built with Ruby by GitHub. Jekyll has been around since 2013, and its user base has been quite strong. It isn’t something that a client would see—it works in the background to generate files.
There are so many good static site generators out there. We wanted one that would be around for a long time. Jekyll is what powers GitHub Pages: free non-commercial hosting for repositories on GitHub. We chose Jekyll because GitHub Pages’ existence is dependent on Jekyll being maintained. A similar line of thinking is one of Jekyll’s philosophies: “If a user’s site builds today, it should build tomorrow. Backwards-compatibility should be strongly preferred over breaking changes.”
Example: At Best Fair Trade Coffee, Jekyll would be working in the background to generate website files. From time to time (perhaps once every few years), the web development team or the IT team will update Jekyll.
CloudCannon
CloudCannon is a proprietary content management system (CMS). Out of all the tools/services we’ll discuss with Jamstack, this is the tool that clients will use most; it allows them to make changes to the website content. Content includes all text, images, graphics, blog posts, and other settings.
CloudCannon launched in 2013 as a CMS for Jekyll and grew slowly. In 2021, it saw exponential growth when it added support for nearly all major static site generators. Twitch and Netflix use CloudCannon, so our clients are in good company. Overall, we find the CloudCannon CMS offers a straightforward editing experience, providing multiple editor styles for building pages.
Example: Best Fair Trade Coffee content creators and editors would log in to CloudCannon to update or publish content. The web development and IT team would also access it to troubleshoot when needed.
Two examples of the editor’s interface
Netlify
As mentioned earlier, Netlify is an important player in the Jamstack scene. It’s a host and content delivery network (CDN) in one. In other words, it’s what serves up the final website. Netlify looks at the GitHub repository for changes/updates and pushes those to the live website.
Example: At Best Fair Trade Coffee, the IT team would need access to Netlify to manage things such as a repository location change, or domain change.
Can WordPress be used in a Jamstack site?
Using WordPress in a Jamstack site is possible, but not advisable because it adds too many moving parts to maintain and vet. There might be exceptional circumstances that lead to taking this route. Our post Jamstack vs. WordPress might be helpful for you to review.
Warning: this section might be more suited for those looking to get even more technical.
Traditional WordPress Site
Image caption: Content edits are made within WordPress. (The backup system connected to WordPress takes a backup with the updated content.) This content, and direct code updates, then get put into the hosted files and database. The hosted files then get distributed via CloudFlare, and work with the database for your browser to build the site, showing it to you live.
Traditionally, WordPress forces the browser to render the site when a visitor first opens it. This means that the browser must check the code in the files to find out where a piece of content in the database needs to render on the page. This process goes against the Jamstack method of prerendering a site.
Forcing the browser to render the site only poses an issue (broadly speaking) for high-traffic sites. It places a significant burden on the servers containing the website files and the database. This produces a series of potential problems: slow load times, security issues, and maxed out servers that load nothing but an error screen.
Jamstack & WordPress Site
Image caption: Content edits are made within WordPress. (The backup system connected to WordPress takes a backup with the updated content.) This content, and direct code updates, then get put into the hosted files and the database. The hosted files and database are combined to generate the static files or the final website. The live website is then delivered by a host or CDN to your browser.
You can move WordPress over to the Jamstack architecture in many different ways. From a non-technical approach, each service will handle “Jamstack-ifying” WordPress differently, but overall they follow a similar pattern.
The main idea, no matter what service and method you use, is to prerender the website. We need to avoid the browser “piecing together” the website when it loads. Instead, we want it to read our files top to bottom, as fast as possible, of course!
After everything is said and done, essentially, you get a “two for one” deal. You have the traditional WordPress site that gets generated into a static site so that the browser no longer has to render it. You then must maintain the two entities, leaving you with the burdens of traditional WordPress maintenance and hosting, plus a static site.
This method has some of the Jamstack benefits, with the drawbacks of complexity.
Reliability
Many new to Jamstack wonder if too many moving parts are involved to make it reliable. What happened to the simplicity of how things used to be?
Image caption: Code and content updates are made directly in the hosted files on the server, which are then reflected on the live website.
Bare functionality is usually the most reliable, but it’s not always the easiest to use. For example, the base model of a car will likely be more reliable than a “fully loaded” option because there’s less to go wrong. Does it mean the base model is better? No. Bare necessity has a time and place, but when we’re talking about websites, it won’t always fit the bill.
Simply placing website files on a server will get the job done, but there won’t be an easy way for content editors to make changes to the website. They would need access to the files (a security risk) and know where to find each piece of content in the files (which may require coding experience).
Content editing aside, this simplistic method doesn’t lend itself well to integrating with popular ecommerce systems or plugins. Plugins, scripts, or serverless functions can save hours, minutes, or days of having to “reinvent the wheel” or manually optimize certain aspects of the website.
A little Jamstack inspiration
Since 2019, we’ve tried a number of different Jam-stacks at Manoverboard. We’ve found our favourite tools and are happy to showcase three of our most feature-packed static sites using them.
Maritime Forest Accord
- Feature of note: Multiple forms, working with CloudCannon’s form services.
- CMS: CloudCannon
- SSG: Jekyll
- File delivery/host: CloudCannon
CCM Group LLC
- Feature of note: Exceptional load times despite large images and self-hosted video.
- CMS: CloudCannon
- SSG: Jekyll
- File delivery/host: Netlify
Our own site: Manoverboard
- Features of note: A highly custom form, working with CloudCannon’s form services; a blog; and a multitude of script libraries working together for custom animations and transitions throughout the site without sacrificing a lot on page speed.
- CMS: CloudCannon
- SSG: Jekyll
- File delivery/host: CloudCannon
If you have questions about Jamstack, or have feedback about this post, let us know.
Did you find this post helpful? You can get more MOB content by subscribing to our monthly e-news.