A Single Click, Dozens of Small Decisions
The publish button looks like the simplest element on the whole screen, and that is exactly why nobody thinks about it. You finish a sentence, you click, the page refreshes and the post is live. What happens between that click and the confirmation notice is a short chain of deliberate decisions WordPress makes on your behalf, and once you know them you start seeing your own site differently. The browser first sends the content to the server — in the block editor this travels through the REST API instead of the old form submission, which explains why a flaky connection can leave you watching a spinner for several seconds. Before anything is written, WordPress verifies that the request really came from your session, confirms that your user role is allowed to publish, and cleans out anything that looks like an attempt to slip code into the database. Only then does it hand the content over to the function that writes a new row into the posts table. That row is mostly plain text and a handful of columns: status, author, date, slug, comment status. Everything else — blocks, colours, image IDs, column widths — lives either inside the content field as structured markup or in separate rows somewhere else. Once the row exists, a long list of hooks fires in order: SEO plugins build their meta description, caching plugins purge the relevant pages, sitemap generators mark themselves for regeneration, and notification plugins queue an email. In under a second, dozens of small modules react to the same event, and the order they react in is decided partly by the plugins themselves. That is why a badly written plugin can break a publishing flow it has nothing to do with.
The Tables That Grow Quietly in the Background
A fresh WordPress installation creates twelve database tables, and the names are reassuringly boring: posts, postmeta, options, terms. The interesting part is how fast they grow compared to what you actually see published. Every post, page, menu item, image attachment and revision is a row in the same posts table, distinguished by a type column, so a site with forty visible pages can easily hold several thousand rows in that one table. Then comes the meta table, which is a free-form key and value store — and this is where plugins quietly deposit their work. A single page built with a page builder can carry two or three hundred meta rows: layout settings, conditional display rules, custom field values, cached template data. None of that appears on the page itself, but all of it is read, sometimes repeatedly, on every request. The options table follows the same pattern. Each option has a flag that decides whether it is loaded automatically on every page load, and plugins are not always careful about that flag, so a settings screen you opened once two years ago can be shipped to every visitor forever. I have seen sites where the autoloaded options pile weighed more than the actual content, and trimming it cut the time to first byte nearly in half without changing a single design decision. Nothing here is broken by design; it is simply the natural result of years of small additions with nobody looking at the total.
Revisions Are a Safety Net Nobody Empties
Every time you save a draft, WordPress stores a second copy of the post in the same table, marked as a revision. This is genuinely useful — it is the reason you can roll back a paragraph you regret deleting on a Tuesday afternoon — but it is also the single most underestimated source of database bloat on long-running sites. By default WordPress keeps an unlimited number of revisions, and a writer who saves every few minutes on a long article can create forty or fifty copies before publishing once. Multiply that by five years of weekly publishing and the posts table can end up being ninety percent history and ten percent live content. The consequences are rarely dramatic; most sites keep working. What happens is subtler: backups become slower and larger, database exports crawl, migration between hosts takes longer than the quoted window, and any plugin that queries the posts table broadly has more rows to sift through. The fix is a one-line constant in the configuration file that caps revisions at a sensible number — five is generous for most editorial workflows — plus a light cleanup routine once or twice a year. It is one of those chores that costs twenty minutes and buys back years of tidiness. The same logic applies to spam comments, orphaned meta rows left behind by deleted plugins, and transients that were never given an expiry date. None of them hurt individually, all of them together decide whether your database feels light or heavy.
WP-Cron Is Not the Cron You Think It Is
Most people assume WordPress has a scheduler running somewhere, quietly waking up on time. In reality, WP-Cron has no daemon at all. It works by checking a list of scheduled events every time somebody loads a page, and if a task is due, it fires it during that request. On a busy site this behaves beautifully, because visitors arrive constantly and every task gets its chance within seconds. On a quiet site — a small business brochure site with a few dozen visits a day — it behaves unpredictably. A scheduled post may go live twenty minutes late because nobody visited. A backup that should have started at three in the morning may run at eleven, in the middle of your busiest hour, and slow the first visitor who triggered it. Security plugins and update routines can be delayed for hours. None of this is a bug; it is a reasonable trade-off for hosts that do not offer real schedulers to every customer. The practical answer for anyone who cares about predictable timing is to disable the built-in version and point a real server cron job at the file once every five minutes. That single change makes scheduled publishing feel genuinely scheduled, tidies up the timing of automated backups, and stops heavy maintenance tasks from landing on a random visitor’s request. If you have ever wondered why your posts appear late or your weekly email goes out at strange hours, this is almost always the answer.
The Heartbeat That Ticks Every Fifteen Seconds
There is a small feature called the Heartbeat API that most site owners have never heard of and every site owner has benefited from. While a post is open in the editor, your browser quietly pings the server every fifteen to sixty seconds, and the server replies. That rhythm is what makes autosave feel instant, what keeps the post-locking warning honest when a colleague opens the same article, and what lets a plugin warn you that someone else is editing before you overwrite their work. It is a genuinely thoughtful piece of engineering that solves a real problem — two people destroying each other’s paragraphs — and it is also the reason a cheap shared host can feel sluggish. On a site with several administrators logged in all day, those pings add up, and each one wakes the whole application stack. The good news is that the interval is adjustable, and on most sites lengthening it slightly is invisible to real users while noticeably reducing background load. This is the pattern with almost everything WordPress does in the background: a sensible default that becomes less sensible as a site grows, and a small adjustment that restores the balance. You do not need to understand the internals to benefit from them. You only need to know that the editor is not a static form, and that the quiet traffic between browser and server is doing useful work rather than wasting your resources.
What All of This Means for the Person Paying the Bill
None of these details are trivia for their own sake. Together they explain a specific kind of frustration that site owners describe in almost identical words: the site is not broken, but it feels heavier than it used to. Pages that once loaded instantly now hesitate. The dashboard takes a second longer to open. Backups that used to finish before a coffee now run through lunch. The cause is rarely one dramatic mistake; it is the accumulation of ordinary decisions — unlimited revisions, autoloaded options nobody removed, an unbounded cron queue, a theme that loads three icon fonts to display four arrows. The fix is equally unglamorous: a lightweight theme that does not fight the core, a caching layer that matches your traffic pattern, a plugin list you can actually justify line by line, and a yearly half hour spent pruning what no longer earns its place. I have watched a site go from a four-second load to under one second without touching its design at all, purely by removing weight it had been carrying since 2019. If you are choosing a starting point, choose a lean foundation — the kind of clean, fast theme collection you can find at seosthemes.com — and then be deliberate about what you add on top. WordPress will happily run whatever you hand it. The judgement about what deserves to be handed to it has always been yours.