Charactir
Journal

Journal · 24 August 2026

In 2018 I built this site in Dreamweaver and put it on shared hosting. In 2026 I rebuilt it from nothing on a different stack. A straight comparison of the two, including what the new one gave up.

Eight years ago I wrote up how I built and hosted this website. That article is still in this journal, a few entries down, and almost none of it is true any more. The site it describes has been taken apart and replaced. Same name, no shared code, and a new address: it moved from charactir.co.za to charactir.com, and the old address forwards here.

This is the other half of that piece. Not a victory lap, but a like-for-like comparison, including what the new site deliberately does without, because a rebuild that only reports its wins is marketing.

Everything below is measured against the two builds themselves: the old theme and database as they were recovered from backup, and the new site as it is served today. Where I could not measure something I have said so rather than estimated it.

What the two are made of

The 2018 site was WordPress running on a shared Linux server at AfriHost, on a theme I had adapted, with the pages assembled by PHP on every request. The 2026 site is a static build: every page is generated once, ahead of time, and what the server sends is a file. There is no database in front of a visitor, and nothing executes to produce a page they ask for.

That single difference is where most of the rest comes from.

2018 2026
Pages built assembled per request 40, built ahead of time
Rendering PHP on shared hosting none, just static files
Content lives in a MySQL database markdown files in git
Third-party requests per page Google Tag Manager, Google Fonts none
Analytics Google Analytics via Tag Manager none
Cookies set via Tag Manager none
Front-end libraries jQuery, Modernizr, Conditionizr none
Typefaces Google’s CDN, plus 841 KB local self-hosted, about 150 KB on a typical page
Host shared server, with Cloudflare in front Cloudflare

Where it got better

Nothing is fetched from anyone else. The old site loaded a Google Tag Manager container and its typefaces from fonts.googleapis.com. Both are requests to a third party that happen whether or not the visitor has any interest in being counted. I checked the new site the honest way: by loading its pages and listing every file the browser actually fetched. Every one of them comes from this domain. Every external address on this site is a link in a sentence that you have to choose to click, and it opens in a new tab so you do not lose your place here.

That matters more than it did in 2018. In January 2022 a Munich court held that loading Google Fonts from Google’s CDN transferred the visitor’s IP address without consent and breached the GDPR, awarding damages on the reasoning that the operator could simply have served the font files from their own server (opens in a new tab) (LG München I, Az. 3 O 17493/20). I was not thinking about any of that when I linked Google Fonts into the old theme. I was thinking that it was one line and it worked.

The front-end libraries are gone. The old theme carried jQuery, Modernizr 2.7.1 and Conditionizr 4.3.0: roughly 16 KB of feature-detection and compatibility shims before any of my own code ran. None of it is here. Some of that is discipline and some of it is simply that the browser caught up: the LazyLoad script I was pleased to have added in 2018 is now a loading="lazy" attribute (opens in a new tab) that browsers implement themselves.

The writing is in files now, not in a database. These four old articles had to be recovered by parsing a mysqldump out of a backup archive. They came back intact, but only because that backup existed and someone went looking. The new site keeps every piece of writing as a markdown file in version control, which means the content is readable without the software that renders it. This article is a file. So is the one it is about, now.

Every old address still goes somewhere. The WordPress site served 352 addresses over eight years, and links to them are still out there. 343 of them now answer with a permanent redirect to the page that replaced them. The other nine had nothing to become, and land on a page that explains the rebuild rather than on a bare error.

The measurement I used to chase does not exist any more. In 2018 I was optimising for a single composite PageSpeed score. That tool is now built on Lighthouse, and the numbers that count are the Core Web Vitals (loading, interactivity and visual stability), which Google made ranking signals in 2020 (opens in a new tab) and rolled into search ranking the following year. Three specific measurements of what a visitor actually experiences replaced one number I could game.

What it gave up

These are not bugs waiting for a fix. They are the price of decisions I would make again, and the old site did each of them better.

There is no analytics, so I cannot tell you who read this. The old site had Google Analytics and could answer “did anyone read this”. The new one answers “was anybody tracked” instead, and the answer is no. The host can tell me roughly how much traffic arrives, the way any server can, but not which article someone stayed on or where they came from. The 2018 article’s entire goal was measurable traffic. I have replaced the measurement with a principle, and a principle does not tell you whether anyone came.

There is no contact form. The old site had one, in PHP, and getting it working was half of the 2018 article. This site offers an email address instead, because a form means collecting and storing what people type into it, and this site collects nothing. For a visitor on a phone with no mail app set up, that is genuinely worse.

I cannot update it from a browser. WordPress let me log in from any computer and fix a typo in a minute. Here a change means editing a file and rebuilding the site. It is quick once it is set up, and it is the reason there is no login page for anyone to attack, but it does mean the site can only be changed from a machine that has it on.

What held up

One thing, and it is the thing I described most vaguely at the time: Cloudflare. In 2018 I put it in front of a struggling shared server to paper over the limitations, and wrote a paragraph about it that does not really explain what it does. It is still here, and it is now the whole host rather than a patch over one. Of every tool named in that article, it is the only one I have not had to undo.

The rest is a fair record of someone learning in public. I would rather keep it up, with this attached, than quietly delete the parts that turned out wrong.

Written with AI assistance, which is also new since 2018, and which is described on the About page.