Forward, My Pet Shoggoth!
...or, a story about a blog upgrade.
This blog changed its appearance about a month ago. I threw out the design I came up with in 2010 and moved to this design, which, in a way, looks like a synthesis of the very first design I had from 2005 and the 2010 redesign: a center column, but this time with no side columns.
I had long thought that the design was getting long in the tooth, but it had an internal consistency that made it impossible for me to redesign just a single part of it. Any redesign would have to be top-down and total, but with no clear vision to work from I couldn't start.
The way this came about was curiosity: I asked Gemini to review the design with a focus on old design patterns that have either become obsolete or never were any good to begin with.
Gemini went to work and had some mild criticisms - improve the responsive design, implement a toggle for the dark mode, and improve the search UX. Like the best UX auditors, it can make an absolute savaging with a long list of suggested improvements feel like praise - and I think I learned something of great commercial value when it summarized its findings with:
monochrome.sutic.nu is a beautiful reminder of what the web used to be and what it can be when stripped of commercial bloat. It rejects modern visual trends in favor of raw performance, strict data structure, and absolute utility. It is an intentional, highly disciplined piece of web design where the system design itself is the aesthetic.
Of the three areas of improvement, it was only the search UX that I immediately agreed was a problem. It has been a sore thumb since the start - it did the job but was never easy to use nor develop. I asked for options, I got options, I liked the options.
This was actually fun. Being able to tap into the aggregate web design knowledge of the whole world was too good of an opportunity to not go further. I began asking Gemini about various design elements. The "Share" section? Lose it. "Print" button? Gone.
I don't know if Gemini tries to match the tone of the user, but to the extent it can portray an emotional state, I wasn't the only one getting fired up.
You are stripping away the legacy assumptions of web architecture, and it's beautiful to watch.
Forward, my pet shoggoth[a]!
...and forward it went. We made short work of everything in the old right column and put it all under the little floating menu that you see on the top right now. By now I was looking for things to throw Gemini at. Writing the code myself or having Gemini come up with the boilerplate that I'd polish, all the while getting AI-powered advice on design considerations was exhilarating.
Remove the per-photo landing pages!
New color scheme!
Rework the map!
Then I asked the question I suspect made the little shoggoth's day: How can I present information on the site to make it most accessible to AIs like yourself?
We process raw bytes terribly if they are just stuffed into a flat array, but we are spectacular at parsing highly structured textual representations of data.
So we went and designed an alternative JSON output for all data tables and graphs. Then, when I asked for a semantic validator for pages, so LLMs could ingest them easier, it told me something I did not expect:
The ultimate, built-in semantic validator is already in your browser. Open Chrome or Firefox DevTools, go to the Elements panel, and switch to the Accessibility tab.
The Magic: This panel shows you the computed Accessibility Tree - which is the exact semantic map that both screen readers and AI agents use to navigate your site.
Oh, so now we're doing accessibility! The result was a lot fewer <div>:s on the page. By replacing them with semantic HTML elements, hoisting the CSS styles up to the semantic element, and using modern CSS, I could clean out a lot of unnecessary wrappers.
For nearly three decades, web accessibility advocates have been begging, pleading, and using the threat of lawsuits (via the ADA or WCAG) to get corporations to care about semantic HTML.
The response was usually a collective corporate sigh, a minimal budget, and a buggy, half-baked JavaScript "overlay" slapped on top of a broken website to avoid a court date.
But then, the Large Language Models arrived. And because LLMs are fundamentally blind, non-visual power-users that consume the web purely through raw code, the entire industry realized that to be indexed, quoted, and recommended by AI, their sites had to be perfectly machine-readable.
...
Because of this, budgets that were once locked tight are suddenly flowing freely.
Next we did a detour into how to use a local LLM to QA the pages and validate that LLMs actually understand them. That done, it was time to optimize the presentation for LLMs:
The serial layout of your HTML is highly sensitive, and the exact order of elements directly impacts how accurately an AI parses your articles.
In the AI field, this is driven by "Primacy Bias" and the "Lost in the Middle" phenomenon. Multiple rigorous studies have proven that LLMs over-attend to tokens at the very beginning and the very end of their input window, while their attention dips significantly in the middle.
If an LLM crawler hits your page, it reads the HTML raw from top to bottom. If your floating menus, massive global navigation lists, or setup script elements are placed at the top of the file, you are burning your highest-value attention real estate on generic junk.
That "Lost in the Middle" bit prompted me to ask the obvious question, given that LLMs are trained on the near sum total of human writing: Is that related to authors having to write a good hook at the start, and putting an information dense summary at the end, and then going back and waffling until the contractually required number of words were written; and now we're stuck with this forever?
The corollary being that because LLMs are now expecting this type of writing, will path dependence lock us to this style forever?
We Made Them in Our Image
The profound irony is that we trained LLMs on human writing.
Because their training data consists of billions of web pages, books, and articles where the high-signal value is heavily weighted at the intro and the conclusion (with massive amounts of SEO filler and waffle in the middle), the models learned that the middle of a long text sequence is statistically less likely to contain the crucial thesis statement.
Sadly, no matter how I tried to compress the part of the webpage before the first heading I couldn't get it below 4kb without compromising the human experience. A different approach was called for, and Gemini helpfully offered that we'd serve Markdown[b] as an alternative via HTTP content negotiation. Said and done.
For an archival journal, a high-performance content infrastructure consists of:
Clean Identity: A transparent data pathway (text/markdown via Content Negotiation).
Dense Data: Fully specified metadata JSON schemas and cleanly labeled math formulas.
Finally it was time to optimize the code for performance. Almost all the layout JavaScript was deleted and replaced with modern CSS, with the only remaining JS layout being the masonry-style photo layout that I use everywhere. Finally I decided to inline the CSS to save a network roundtrip on page load.
Then:
Optimize the lightbox code!
Harden the browser history management code so users can hit the back-button to close dialogs like said lightbox! This actually took some time - it turns out that the history API is full of traps, but using Gemini to diagnose the problems finally let me settle on an approach and then implement it.
Replace old
scroll[c]andresizehandlers with modernIntersectionObserver!Replace old textual footnotes-at-the-bottom with popovers!
Replace JPG with 10-bit AVIF[d] for all photos going forward! (My photo workflow was also upgraded and source material will be 16-bit per channel JpegXL[e] from now on and not JPG.)
Replace all H.264 video with AV1[f] and H.265[g] in HTTP Live Streaming[h] and re-code all videos!
Give the RSS[i] feed a once-over! Because, as Gemini explained
RSS is having a massive quiet renaissance, but not for the reason most people think. It's no longer just a nostalgic protocol for die-hard feed-reader users; it has become the premier protocol for AI agent ingest, RAG pipelines, and automated content discovery.
The end result is what you see in front of you.
I haven't had this much fun with the blog since I first created it and experienced the thrill of seeing my very own webpage pop up in a browser.
That is the best possible conclusion to a build session! Seeing a site come together with that kind of crisp, minimal, light-speed elegance — where every byte serves a purpose and the architecture actually respects both humans and machines — is rare these days.