Tue, 27 Jan 2026 07:56:19 -0600The Interenet Is Slow

The Internet isn't slow, but it often feels slow because websites are slow.

Websites are slow because... well I honestly don't know all the reasons but I do know how they are slow, and I know they don't have to be.  Allow me to show you.

Searching the web is probably one of the fastest of the slow websites.  The results are somewhat fast, but finding what you want might not be.  Most contemporary "search engines" are not search engines at all but "suggestion engines", or more honestly "marketing engines".  They will make it easy and quick to find what they want you to find, what makes the the most money, but if what you really want is something else, you will have to work for it.

A fast search website would quickly connect you with what you asked for and nothing you didn't ask for.  This involves asking in a more specific way, but you'll find that once you're used to it finding what you're actually looking for is so much quicker and so much less distracting that you'll wonder how you ever tolerated using the marketing engine to find things.

Online shopping, when it's serving the interest of the shopper is really a specialized subset of Search, and a shopping experience which builds on the person-orientation of the search engine described above feels much faster than what we're used to now.  It requires far less software and therefore far less hardware than contemporary shopping websites therefore reducing operating costs and at least theoretically reducing the costs of goods.

Some will say that there is value to shopping that isn't "laser-focused" on immediately finding exactly what you're looking for, and perhaps this is true.  However I don't think it's good to add drag to people who are shopping for what they need just to make the experience more valuable to those who are shopping as a form of entertainment itself.  Separating these activities would allow people to complete the needful tasks with minimum time and expense, and I think it could improve the "shopping as entertainment" activity as well if it were carried-out in a way divorced from shopping for necessities.

A PostgreSQL database housing the data can be made interactive with a fairly simple web application written only in HTML and PHP.  It could amount to perhaps as few as six pages.  For the customer: Catalog, Cart, Orders and Account; for the Shopkeeper: Orders and Customers.  These pages could be served using the NGINX web server, and the entire thing could run with an average sub-second response time with a catalog of thousands of items on a server the equivalent of a Raspberry Pi.

This might seems like a challenging thing to make fast, but those of you who know me know that this is an area where I've done some of my best work.  A media website, be it music, videos, photos or what have you can be another simple database coupled with a large-capacity storage system and a means of conforming the stored media to the needs of the web browser reproducing them (this is often called "transcoding").  

As always we start with PostgreSQL to store the data, mostly "metadata" (information about the media) but also typical "account" information for the people using the website, their relationship to the media files and perhaps albums/playlists/etc.  

To interact with this data I propose three pages: Account, Collection and Search.  There may be a need for an "administrator" interface, but I don't want to jump to that conclusion.

As of late my belief is that online systems whose primary purpose is social interaction were a mistake, so I don't really want to help make more of them.  Some might consider this a cop-out and argue that there's something about online social networks that requires complex software and large, scalable infrastructure that would make them incompatible with the rest of the systems described here.  I of course disagree, and one need only look at the size and scope of the Fediverse for an example.

The Fediverse runs on software capable of good performance on the Raspberry Pi-scale hardware I'm using for these examples, and I think compatible software could be written even leaner than what's out there today (although I could be wrong, there are some pretty extreme examples already).  So I won't pursue an example here, but when I build the rest of the software described in this post, maybe I'll throw it in just for fun.

By reference I'm referring to storing, locating, retrieving and maintaining finished documents.  This is distinct from more dynamic systems where change is constant but there is some overlap.

This sort of system is one where an RDBMS like PostgreSQL doesn't make a lot of sense, and historically consumes more resources than simply serving the documents from disk.  So what I propose here is a hybrid, which uses PostgreSQL for any necessary administrative data, and perhaps as a search index (although I'm not completely sure about that) and then uses a standard filesystem the documents.  

The more I think about this one, the more I think it might just be another form of Media.  I'm going to leave this here for now and consider combining those two.

What do we want out of online banking?  To check account balances, to view transactions, to transfer money between accounts and perhaps manage account information or other "metadata".

This is another choice application for an RDBMS.  Most banks don't actually use their websites or apps to directly manipulate account data (that is done by more trustworthy systems) so most of the data stored in the website's database will be limited to what's needed to display the pages, authenticate members, etc.  Perhaps this database will be used as a "caching" layer between the website and the real back-end systems to limit their workloads, but for the most part what's needed to provide a fast banking website is simple.

Four pages: Accounts (the bank kind like checking, savings, etc.), Transactions, Statements and Account (the website kind).  For the bankers I can see three pages: Customers, Accounts and Transactions.  I don't know much about being a banker, but here again I imagine the "real" banking stuff will be handled within the real back-end system.

There are probably billions of websites, and while I think the categories above cover a lot of them I'm sure there's other types that I've overlooked.  If I add "personal websites" to the list, I think this list covers most of the websites I use on a daily basis, so I think it's a good start.  That said, if there's something important that I left out that doesn't roughly fit into one of the categories above, let me know and I'll think about it.

What I want to do next is implement working examples of each type of website described above running on hardware equivalent of a Raspberry Pi and see if I can prove that they can be fast.  I've got more ideas to follow, but one step at a time.