One of the recurring questions when people familiar with HTML discover the Gemini protocol is: Why? Why not just write really simple HTML?

I came to see the appeal back in 2021, but taking a fresh look at Gopher this month, and actually building a basic Gopher site, helped me crystalize something:

It makes the most sense to look at Gemini and Gemtext in terms of the Gopher revival it came out of. It’s less “what do we want to throw out from the web?” and more “what bits of the web do we really miss when building with Gopher?”

So it ditches Gopher’s arcane menu syntax and strict menu/document hierarchy in favor of basic hypertext links that can be used anywhere. It adds word wrap, since we’re all using different-sized screens now, but makes it possible to keep ascii art/tables when needed. It welcomes global writing systems. Then it adds TLS for protection against eavesdropping.

The result is something that’s almost as minimalist as Gopher, but a lot more flexible. That makes it easier to get into than Gopher or hand-crafting your own website, plus it’s still usable on low-spec hardware or networks.

As a minimalist web, it seems lacking. As a web-enhanced response to Gopher, the goals are clearer.

See also: Project Gemini FAQ

I’m not ready to give up on the flexibility of WordPress for my main blog yet, but holy crap are these pages heavy. Even with compression. There’s no reason it should take 450K (before compression) and 20 requests to display a 500-word post.

And I don’t even do ads, popups, social sharing buttons or anything else like that.

By contrast, my Les Mis blog, where I post about once a year, is currently generated by Eleventy using a custom minimal theme that only takes around 10K of HTML, 3K CSS, and a third request for the icon. And another 40K for the header font, which I recently set up locally so it no longer has to call out to Google Fonts.

One domain, just four requests, and only 50K for the first hit and 10K for each subsequent page.

Never mind the Gemini version of the blog which is around 2-5K per page and a single request per page!

Compression cuts down on those 500Kb WordPress pages — all the text and code compresses really well so only around 200K bandwidth is needed. But it’s still got multiple JavaScript and CSS requests going on.

I was able to cut it down significantly by switching to a lighter theme and turning on the minimize/combine feature in WP-Optimize so it’s making fewer script calls. But it’s still way bigger than the minimalist setup I have with 11ty.

Some of it is images, though. I still have my latest Flickr posts in the sidebar, and I’m using Jetpack’s related posts feature which includes thumbnails. I could cut out a big chunk by removing those, but I kind of still like the idea of having them in there.

I think I need to take a look at how much extra stuff I really want on this site and rip some of it out. Eventually I’d like to replace all the JetPack features because they just seem to keep adding more scripts. Plus I want an entirely local stats package instead of one that’s offloaded to a third party even if they’re less awful than, say, Google or Facebook.

On the other hand, I want to keep Gravatar on the comments sections (on the older posts where people actually commented) because that’s actually useful to readers as an aid for following a conversation better. But that’s all on top of the base page size.

ยปAll pages site-wide with this tag