Hello, I'm Russ, and this is my website. I'm a software engineer who programs for the love of the craft in an age of tech disillusionment. The purpose of this site is to give me a place to publish my thoughts in general and on programming, personal projects, and professional developments.

Hit Counter

Publish Date: 2026-06-13

One staple of the old web was the humble hit counter. Counters are a number presented on a site in text or graphic form which represent the count of visits. They still exist today, especially on the "indie web" (Indie Web), Neocities, Wiby, but in the early-to-mid 2000s, they were mostly replaced by more comprehensive systems like Google Analytics which tracked many metrics: browser, geolocation, language, timezone, referrer, etc. Systems like GA are in many ways superior to hit counters except in their reliance on a corporate, third-party system.

For those who've never seen them, here's an example I made in GIMP (I tried very hard not to use any 3s or 7s in the example):

Web counters are a simple concept: each time the counter is accessed, increase count by 1. This post seeks to design a simple web counter for the site.

Properties

Here are some desired properties:

1. Current Count
2. Date Created
3. Text or Graphical Representation - for now let's stick with graphics for that 'old web' feel
4. Server-side Persistence Layer
5. Encounter Definition: A user accesses the counter resource
6. Encounter Properties:
   • IP
   • Referrer
   • User Agent
   • Visited Resource
   • Date/Time
7. Visit Definition: An Encounter that has an IP that's the first of the day
8. Counter Incrementation Rule: Once for each Visit

The Encounter properties might be useful or interesting for later analysis and can answer questions like:

• Which resource is most visited?
• Where are visitors most located?
• Which browsers are favored?
• Are visit rates changing over time?

Model

Let's persist the model in a relational database.

I would like to avoid utilizing cookies because nobody likes those and because I'd like to avoid a GDPR cookie prompt if possible.

Many encounter entities to one counter entity. Pretty straightforward.

I considered having a resource entity which represents the URI that's accessed when an encounter occurs. However, I felt this was duplicating the presence of the counter on the resource's landing. Said another way, the counter's relationship to a URI is defined by its presence on the landing, not by configuration in the database. This allows the front-end to move a counter from one location to another without changing the database.

For the initial version, we'll hard code references to the digit graphics. This will eliminate the need for configuration, for now.

API

Only one operation is needed:

1. Operation 1: Visit & Display URI</li>
   • Build the Encounter
   • If the Encounter, for IP, has been recorded less than N times today, then record it today (prevents a bad actor from filling up the database)
   • If the Encounter, for IP, has been recorded less than 1 times today, then increment the counter
   • Access the counter's current count
   • Output image

In today's age, there are lots of great font libraries out there, but I would like to build my counter graphic server-side, the way they used to be built long ago.

There could be other operations like registering a new counter, resetting a counter, deleting a counter, etc. This is too much for now and each would require an authentication mechanism.

End

Ok, it's time to get to work! I've already started building out the database model, but this week I'm aiming to finish the implementation and put a shiny new counter on each page of the site.