Introduction to Static Sites, Static Site Generators, and Jekyll

DZone 's Guide to

Introduction to Static Sites, Static Site Generators, and Jekyll

See why Jekyll might be right for you.

· Web Dev Zone ·
Free Resource


The modern web development (by “modern” we mean one that’s been taking place in the last ~5 years) seems to be heavily into dynamic content. As the internet progressed from simple HTML pages to dynamic web apps, the benefits of dynamic web technologies became ever so clear. Nowadays, web apps like YouTube, Google Maps, and Figma are gradually bridging the gap between web and native software (and technologies like WebAssembly are playing a huge part in this process).

Still, we shouldn’t disregard static websites. Even though they can’t boast rich functionality, their advantages lie in other areas. In this article, we’ll take a closer look at a static site generator called Jekyll and analyze the benefits that you’ll get when using any static website.

You may also like: Azure DevOps Build Pipeline for Jekyll.

The Bigger Picture: Static and Dynamic Websites

Before diving into Jekyll directly, let’s take a step back and see the bigger picture. Websites can be divided into two groups: dynamic and static. What are the differences between them?

Even though static websites are called, well, static, it doesn’t mean that they don’t provide any dynamic functionality. The main difference between these two types lies in the website’s ability to change its content (i.e. the files it stores).

  1. Dynamic sites can change to change files dynamically via the server. Every time the server receives a request, it (re-)generates the files depending on the user’s intent. These files are then served to the user.
  2. Static sites, on the other hand, can’t do that. They serve static (i.e. pre-built) unchanged files that include .css styles, .html pages, and .js scripts. In this scenario, the developer doesn’t need a server (e.g. Node.js) to handle the website’s business logic — they only need a web hosting service.

Static Websites Advantages

The advantages that dynamic websites can offer are self-evident: their functionality is practically limitless (well, it is limited by the amount of JavaScript memory leaks the developer may accidentally introduce ¯\_(ツ)_/¯). But what are the reasons that you may choose static websites instead?


The most obvious advantage is speed — as static websites aren’t coupled with databases and content generation, their performance increases dramatically. In fact, databases often turn out to be the website’s biggest bottleneck: databases are easy to use, but they’re hard to use properly and efficiently, which often leads to blaming the wrong technology for the website’s subpar speed (e.g. “Argh! Why did I choose Python for this project — it’s so slow!”).

Static vs Dynamic websites

Static vs Dynamic websites

In static sites’ case, therefore, the user experience becomes much more streamlined and enjoyable: the Time to First Byte (the time it takes for the browser to receive the first byte upon the request) is significantly lower, allowing the users to get the content they want faster — after all, the website isn’t executing any database queries or HTML templating.

More skeptical developers might think: “Can’t the users wait just a few seconds?” Well, let’s look at the data that Google has provided in their "Why Performance Matters" post: 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.

Retention by website load time

Retention by website load time


Another important factor is security. Once again, it’s heavily tied to the lack of databases — SQL injection is still one of the most common cyber attacks. In essence, SQL injection utilizes the website’s ability to accept user input — hackers can use various input fields to execute malicious SQL commands, changing or deleting the server’s data. Naturally, static websites are safe from this threat — no databases, no problems.

In the sections above, we mentioned that developers working with static websites don’t have to deal with managing a web server. An essential part of this managing process is installing security updates. WordPress developers are especially familiar with the headache-inducing duty of keeping the website’s security up-to-date — the platform’s immense popularity means that it’s a prime target for hackers, so website security becomes a top priority. Conversely, static websites are secure because they don’t have any functionality that can be exploited.

Hosting and Development

Both hosting and development of static websites are seamless. When it comes to hosting, the hosting provider is only expected to store static files and doesn’t have to support a particular framework. Of course, it’s always great if the hosting provider offers a content distribution network functionality; this will make your static website perform even faster.

As of October 2019, more and more hosting providers (especially those active in the cloud computing industry) are offering to host not only static websites, but also static site generators — this means that the entire development process becomes easier as well, allowing you to implement continuous deployment. Some of these providers include:

  • Amazon Web Services (Amazon S3, optimal for file hosting).
  • Google Cloud Platform.
  • DigitalOcean.
  • Netlify.

In terms of development, continuous deployment (which is a strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment) is a major time-saver. It simplifies the development process, making it much less of a hassle. Therefore, the typical development steps/stages are:

  1. Connect the repository.
  2. Add build settings.
  3. Deploy the website.

A Few Words about GitHub Pages

This is where GitHub truly shines. As it turns out, we can use this platform to host static websites! GitHub Pages is specifically designed to transform GitHub repositories into static websites, allowing you to showcase anything you want. While we’re on the topic of GitHub Pages, we should also reiterate the limitations this service has — we’ll quote our guide to GitHub Pages:

You shouldn’t expect to run a large web project without any hiccups as GitHub enforces usage limits, which are:

  • Source repositories have a recommended limit of 1GB.
  • The maximum size of the published sites cannot exceed 1 GB.
  • Sites have a soft bandwidth limit of 100 GB per month.
  • Sites have a soft limit of 10 builds per hour.

Furthermore, GitHub Pages users are prohibited from hosting commercial projects like online businesses and e-commerce platforms. You may notice that the limitations above as referred to as soft limits — this means that, upon exceeding the limit, the user will get a polite email from GitHub requesting to slow things down.

So what happens when site usage pushes past these limits? GitHub suggest a few strategies to solve this problem:

  • Setting up a separate content distribution network (CDN).
  • Using GitHub releases.
  • Switching to a different hosting service.

Where Can Static Websites Truly Shine?

The (somewhat limited) functionality of static websites shouldn’t prevent you from making your projects come to life. Generally, static websites excel at helping you show something to the world without an overcomplicated setup process:

  • Portfolios and static websites are the ideal combination — they’re only required to whet the visitor’s appetite and, preferably, lead to the project’s separate websites.Some notable examples: Lucas Gatsas, Chester How.
  • Personal blogs are, essentially, just text with images — just what a static website needs. Furthermore, static site generators like Jekyll offer a plethora of blog themes. Some notable examples: Auth0 Blog, Mozilla’s Release Management Blog
  • Informational pages can be viewed as “really long blog posts.” Some notable examples: Twitch Developer Documentation, Spotify Developer Documentation, htmlreference.io, Markdown Guide, plainlanguage.gov.
  • Landing pages are another great option — it’s usually designed to showcase the product’s key features, topping it off with a call-to-action (“Enjoying our articles? You’re not enjoying them enough — enjoy more!”). Some notable examples: Ionic Framework, TwitchCon, Sketch.

A Few (Kind) Words about Jekyll

At this point in the article, you’re probably itching to create a static site yourself. You’re opening the StaticGen homepage and seeing that there are 262 static site generators. Which one should you use? Our experience tells us that Jekyll is a great option. In the sections below we’ll explore its awesome functionality in greater detail, but let’s first take a closer look at Jekyll itself. Its Quickstart page reads:

Jekyll is a simple, extendable, static site generator. You give it text written in your favorite markup language and it churns through layouts to create a static website. Throughout that process you can tweak how you want the site URLs to look, what data gets displayed in the layout, and more.


The Liquid feature introduces real programming logic to HTML, which is a “not-a-real-programming-language” language. Liquid is a templating language that extends static sites’ functionality via objects, tags, and filters.

Objects act as pointers to specific content, signifying that this content should be outputted in the given object’s place. They’re denoted via double curly braces:

{{ page.title }}

 page refers to the website in general, while title refers to the website’s name that we set in the config file. The code above, therefore, is a variable that will output the website’s name in the page we specify.

Tags deal with the page’s logic and template’s control flow and are denoted by curly braces and percent signs. Using tags, you can highlight a code snippet:

{% highlight python %}
def greet(name):
    print(f”Hello, {name}!”)
{% endhighlight %}

You can also create short links to other pages:

{% link _posts/2019-10-15-dzone-article-guidelines.md %}

And you can even implement if-logic!

{% if page.show_sidebar %}
  <div class="sidebar">
    sidebar content
{% endif %}

The code above will output the sidebar if page.show_sidebar is true.

Filters can modify an object's output. They’re placed within the objects and are denoted by a vertical slash (|). Filters can convert dates to strings...

{{ site.time | date_to_string }}

23 Oct 2019

… normalize whitespace (i.e. replace multiple whitespace instances with a single one)...

{{ "a \n b" | normalize_whitespace }}

… count the number of words on a page…

{{ page.content | number_of_words }}

… sort an array (e.g. by order)...

{{ site.pages | sort: "title", "last" }}

… and much more.

Front Matter and Layouts

The front matter serves as the page’s overseer, storing various variables you'd like to use in objects. It’s denoted by triple-dashed lines at the top of a file:

author: “Jane”

 author is now a variable. We prepend it with site. and get “Jane” as the output:

{{ page.author }}

An important feature of Jekyll is layouts, which are templates that you can utilize to format/structure your content with ease. Let’s say you have a personal blog. The page type that you’d have to work with most frequently would be blog posts. Without layouts, you’d have to organize and style each new blog post manually; conversely, you can create a dedicated page layout for blog posts…

<div class="post">
  <div class="post-info">
    <span>Written by</span>
    {% if page.author %}
        {{ page.author }}
    {% else %}
        {{ site.author.name }}
    {% endif %}
    {% if page.date %}
      <span>on&nbsp;</span><time datetime="{{ page.date }}">{{ page.date | date: "%B %d, %Y" }}</time>
    {% endif %}

  <h1 class="post-title">{{ page.title }}</h1>
  <div class="post-line"></div>

  {{ content }}


<div class="pagination">
  {% if page.next.url %}
    <a href="{{ page.next.url | prepend: site.baseurl }}" class="left arrow">&#8592;</a>
  {% endif %}
  {% if page.previous.url %}
    <a href="{{ page.previous.url | prepend: site.baseurl }}" class="right arrow">&#8594;</a>
  {% endif %}

  <a href="#" class="top">Top</a>

… and include the reference to this layout in each post:

layout: post
title: "Introduction to WebAssembly: Is This Magic?"
author: "Jane"

The real power of layouts is tied with editing code. In raw, static websites (i.e. those built without a static site generator), you’d typically copy and paste code blocks whose functionality you’d like to include in multiple pages — a good example would be a navigation bar. In the end, you end up with dozens — if not hundreds — copies of a navbar code block. The problem arises when you want to edit this navbar. In order for the changes to be consistent across the entire website, you’d have to edit each copy of this code block.

Layouts were designed as a solution to this problem. To apply the change to the entire website, you only need to edit the original layout file.


The beauty of Jekyll comes to life when you start combining features like tags, objects, and filters. This makes the development workflow much easier:

  1. Jekyll-powered code is less verbose than raw HTML code.
  2. The build process is streamlined — as you make changes to the code, Jekyll automatically regenerates the page you edited.
  3. Logic introduced by Liquid allows you to implement new functionality.

All in all, both static and dynamic websites are excellent tools of web development. In each project, make sure to choose the right tool for the job. We hope that this article has improved your understanding of these topics. Let’s recap the things we’ve learned:

  1. A static website cannot change its server’s files dynamically; instead; it serves premade assets.
  2. Static site generators simplify the development process even further, but they also add some critical functionality.
  3. Hosting a static website via GitHub Pages is a great place to start — but you may need to choose a paid hosting provider later if you’re planning to scale your web project.

Further Reading

static site ,static site generator ,static sites ,jekyll ,web dev ,html ,javascript ,first byte

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}