Static.Quest

Improving the webring links, one build at a time

2026-08-24T13:28:30Z

If you have ever clicked the little ← and → arrows on a member's site, you have used the plumbing that ties Static.Quest together. Those links are how a web ring works: every site points to the next and previous member, and visitors can walk the whole circle without ever visiting the hub. This post is a look at how those links worked until recently, what was wrong with them, and how we made them better while staying 100% static.

How it used to work

The original approach leaned on the browser. Members embedded links like this:

<a href="https://static.quest/next/?host=yourwebsite.com">&#8594;</a>

When someone clicked that link, they landed on a small page on Static.Quest whose only job was to run some JavaScript:

Read the host value out of the query string
fetch() a JSON file listing all the members
Find the current host in the array
Set window.location to the neighbor's URL

It worked, and honestly it worked fine for years. But it had a few rough edges worth fixing:

JavaScript required. No JS, no redirect. You got a polite <noscript> message instead.
An extra round trip. Every hop waited on fetching and parsing members.json before anything happened.
Silent failure modes. Visit /next/ without a ?host= parameter and nothing happens at all.
The ring order wasn't stable. The JSON array was generated in whatever order Eleventy happened to collect the files, which is not guaranteed to be identical between machines or CI checkouts.

The new way: generate the redirects at build time

The key realization is that Eleventy already knows everything needed at build time. It has the full member list, so it knows exactly who comes before and after you in the ring. So why involve the browser at all?

Instead of one generic redirect page, we now generate one tiny HTML page per member per direction during the build:

/next/yourwebsite.com
/previous/yourwebsite.com

Each page is just a meta refresh pointing at the correct neighbor:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="refresh" content="0; url=https://yourwebsite.com/" />
  </head>

  <body>
    <p>Walking the Static.Quest web ring to
      <a href="https://yourwebsite.com">https://yourwebsite.com</a>&hellip;</p>
  </body>
</html>

Members embed a link to their own page (/next/yourwebsite.com) rather than passing themselves as a query parameter. That URL never changes. When a new site joins the ring, the build regenerates everyone's pages, and all the neighbors quietly shift over without any member touching their markup.

How it is built

Two pieces make this work in Eleventy.

First, a deterministic ring order. Hosts are normalized (lowercased, trailing slashes stripped) and sorted alphabetically, then shared through filters so every consumer agrees on who is next and previous:

function normalizeHost(host) {
  return String(host || "").trim().replace(/\/+$/, "").toLowerCase();
}

eleventyConfig.addFilter("orderedHosts", function(collection) {
  return collection
    .map(item => normalizeHost(item.data.host))
    .filter(Boolean)
    .sort();
});

eleventyConfig.addFilter("ringNeighbor", function(collection, host, offset) {
  const hosts = collection
    .map(item => normalizeHost(item.data.host))
    .filter(Boolean)
    .sort();
  const index = hosts.indexOf(normalizeHost(host));
  if(index === -1) {
    return null;
  }
  return hosts[(index + offset + hosts.length) % hosts.length];
});

That modulo arithmetic is the whole wrap-around trick: the last site's "next" is the first site, and the first site's "previous" wraps back around to the end. A web ring should be a circle, after all.

Second, a paginated template generates all the pages:

---
permalink: "/next/{{ member.data.host | hostSlug }}/"
eleventyExcludeFromCollections: true
pagination:
  data: collections.members
  size: 1
  alias: member
---
<meta http-equiv="refresh" content="0; url=https://{{ collections.members | ringNeighbor(member.data.host, 1) }}/" />

Eleventy fans that out into 63 pages, one per member, in about a third of a second. There are 63 current members at time of writing.

Nobody gets left behind

Changing the widget format would normally mean asking every member to update their site. Instead, both formats work side by side:

The old /next/?host=yourwebsite.com pages are untouched and keep doing their thing
The new per-host pages live alongside them at /next/<host>/
Both read from the same shared ordering, so "next" means the same neighbor no matter which style of link brought you there

New members copying the snippet from the join page get the new format; existing members can update whenever they feel like it, or never. No rush, no breaking changes. That felt like the right way to treat the folks who make the ring a ring.

While improving the overall process, the random link got a small tune-up too. It used to be the same story: load page, fetch JSON, pick a winner. Now the member list is baked right into the page at build time, so clicking "Feeling lucky?" needs zero network requests beyond the redirect itself.

Why this matters

Everything above stays true to what makes a static site a static site: no server-side logic, no edge functions, no databases. Just files on a static server. The "dynamic" behavior people usually reach for JavaScript to solve turned out to be a build-time problem wearing a runtime costume, and moving it into the build made the result faster, simpler, and friendlier to browsers that don't run scripts.

So go ahead, click an arrow somewhere in the ring and enjoy the tour. If you run your own site and want to join the quest, we would love to have you. Check out the joining instructions and add yourself to the circle.

What is a static website?

2026-08-24T13:28:30Z

What is a Static Website?

A static website is like a digital brochure that remains unchanged unless manually updated. Every page of a static website is a fixed HTML file, meaning the content is pre-determined and doesn't dynamically change based on user interactions or real-time data.

Key Characteristics of Static Websites

Pre-built Content: All content is created and stored as individual HTML files.
No Server-Side Processing: Unlike dynamic websites, static sites don't require a server to process requests and generate content on the fly.
Faster Load Times: Because there's no server processing, static websites generally load much faster than dynamic ones.
Limited Interactivity: While they can include basic elements like forms and images, static websites lack advanced features like user logins, personalized content, or real-time updates.

When to Choose a Static Website

Simple Content: If your website primarily consists of text, images, and basic information, a static site is a good option.
Performance Focus: Static websites are ideal for projects where fast load times are crucial, such as portfolios or online stores with a limited product range.
Low Maintenance: If you don't need frequent updates or advanced features, a static website can be easier to manage.

Popular Tools for Creating Static Websites

HTML, CSS, and JavaScript: For those comfortable with web development, creating a static site from scratch using these languages provides maximum control.
Static Site Generators: Tools like Jekyll, Hugo, and Gatsby streamline the process by converting plain text and templates into HTML files.
Content Management Systems (CMS): While primarily designed for dynamic websites, some CMS platforms like WordPress can also be used to create static sites, offering a more user-friendly approach.

In Conclusion

Static websites offer a straightforward and efficient solution for many online projects. Their simplicity, speed, and low maintenance requirements make them a popular choice for individuals and businesses with basic website needs. However, if you require more complex features and dynamic content, a dynamic website might be a better fit.

Building a static site

2026-08-24T13:28:30Z

Static sites are a great part of the small web. They are easy to configure, deploy, and maintain. You can use a static site generator or write the HTML yourself.

Static Site Generators

To help some content producers, the use of a Static Site Generator is helpful. This allows the user to design their site and functionality, then just add content where it is needed and the generator builds complete HTML from template files. Examples of Static Site Generators (in alphabetical order):

Astro (JS)
Docusaurus (JS+React)
Eleventy (JS)
Gatsby (JS/TS+React)
Hugo (Go)
Jekyll (Ruby)
Lektor (Python)
Next.js (JS/TS+React)
Nuxt (JS/TS+Vue)
Pelican (Python)
VuePress (JS+Vue)

There are plenty more: https://jamstack.org/generators/

Most of these generators rely on technologies like NodeJS, Python, Ruby, Go and others. The generators are able to build simple personal sites to large complex business pages, the choices are endless.

Hosting your Static Site

Hosting a website is the next step after building it. There are many free platforms available to host a static site, and also paid hosting options. Popular static site hosting is found at:

Many of these providers integrate with the Git actions to build and deploy the site to their hosting platform. The addition of Git provides some with a workflow that makes it easy to add their content and publish without needing to be hands on or knowledgeable in the hosting aspect of web content.

This is not a comprehensive list, but a small one to help those who wan to get into web design, blogging, and sharing their content.

Choosing a name

Every website on the Internet is reached via a domain name. The choice provider for Static.Quest is Porkbun. They have a fun name and good prices.

If you don't want to spend a lot of money yearly, many of the hosting providers mentioned also allow you to have a subdomain off of theirs for convenience.

What's next

There are so many further places we could go, but let's have some other bloggers and website developers tell you in the resources.

Just start a blog

2026-08-24T13:28:30Z

Finding a good community to help you along in your web journey is a powerful thing. There are places to improve design, backend work, writing, and more. Here are a few great resources to help in some of those ideas.

Go start a blog by Jeremy
Blogging on a budget by Benjamin Hollon
100 Days to Offload by Kev Quirk
One year of blogging by Andreas
Year in review by Clayton Errington
This blog is running on a recycled Google Pixel 5 by Dom Corriveau
Jekyll Archive by Steve Fenton
Astro Archive by Steve Fenton
The great paywall by Benjamin Hollon
Announcing my blogroll by Benjamin Hollon
Different Types of Web Hosting Explained by Adamsdesk

This list should hopefully grow and expand over time. If you have something you'd like to share, send a pull request to get it added.

Static.Quest

Improving the webring links, one build at a time

How it used to work #

The new way: generate the redirects at build time #

How it is built #

Nobody gets left behind #

Why this matters #

What is a static website?

What is a Static Website? #

Key Characteristics of Static Websites #

When to Choose a Static Website #

Popular Tools for Creating Static Websites #

In Conclusion #

Building a static site

Static Site Generators #

Hosting your Static Site #

Choosing a name #

What's next #

Just start a blog

How it used to work

The new way: generate the redirects at build time

How it is built

Nobody gets left behind

Why this matters

What is a Static Website?

Key Characteristics of Static Websites

When to Choose a Static Website

Popular Tools for Creating Static Websites

In Conclusion

Static Site Generators

Hosting your Static Site

Choosing a name

What's next