OpenStation turns your WordPress admin into a desktop: windows, a dock, wallpaper, drag and drop. The promise was always that it should feel better. This week we checked whether it is actually faster.
Every number below was measured on the site you are reading right now — openstation.blog, over a real network, on real WordPress.com hosting.
The short version
- Six ordinary screen changes: 14.6 seconds in classic wp-admin, 8.0 in OpenStation.
- Going back to a screen you already have open: 1.9–3.3 seconds in classic, 0.6 of a millisecond here.
- Starting the admin: a third of the weight it had in version 1.0 — about 2 seconds on 3G instead of 10.
Your admin boots like an operating system, and then behaves like one.
Why a classic admin feels slow
A classic admin throws your page away every time you click.
Click Settings, wait. Click Tools, wait. Click back to Settings — the screen you were looking at a minute ago — and you pay full price again. Measured here: 1,903–3,326 ms per click, every time, forever.
Nothing in that design remembers anything, so it can never get better.
Windows don’t get thrown away
OpenStation’s answer is the one every desktop reached decades ago: stop throwing things away.
Your windows stay alive. Returning to an open screen isn’t a page load, it’s just bringing a window to the front: 0.6 ms median, 1.2 ms at its worst.
That is not a percentage difference. It is a change of unit — seconds become fractions of a millisecond, on the single most common thing you do in an admin. No settings, no flags, no cache. It’s simply what happens when your admin has windows.
Six clicks, both ways
The fairest test we could think of is the most ordinary task there is: Settings → Writing → Reading, twice. Six screen changes, same site, same sitting.
| Classic wp-admin | OpenStation | |
|---|---|---|
| Total waiting, six screens | 14.6 s | 8.0 s |
| Typical screen | 2.1 s | 1.0 s |
| Fastest | 1.9 s | 0.98 s |
| Slowest | 3.3 s | 2.0 s |
Roughly twice as fast — and this journey is deliberately hard for us: three different pages, none of them already open. It’s the case where OpenStation has the least structural advantage, and it still wins by half.
We also put the desktop on a diet
In version 1.0, everything loaded the moment you opened the admin: every window, every dialog, every extra feature — including the ones you were never going to touch that day.
So for two releases we kept asking one question:
Does the desktop need this right now, or only when someone uses it?
Kilobytes are abstract; waiting is not. Here is the time your browser spends just downloading OpenStation’s startup files before the desktop can appear:
| Connection | v1.0.0 | Today |
|---|---|---|
| 3G (1.6 Mbps) | ~10 seconds | ~2 seconds |
| 4G (12 Mbps) | ~1.4 seconds | ~0.3 seconds |
Nothing was removed. Every feature still works — it just waits for its natural moment:
- The file uploader loads the instant you start dragging a file, and finishes before you let go of the mouse.
- The sharing dialog loads the first time you click Share.
- Sticky notes load only if your desktop actually has notes.
- The command palette (⌘K) was the heaviest passenger of all — over a megabyte of editor code on every visit, just in case you pressed it. It now loads the first time you actually do, and still opens instantly.
The editor got the same treatment. OpenStation used to add its own files to every Gutenberg window, where they did nothing at all. Today it adds none — you get Gutenberg at exactly the speed WordPress itself delivers it.
One detail we’re quite proud of: since 1.0 OpenStation has gained Station Home, desktop themes, games, the notes wall and more. Today’s startup is still lighter than 1.0’s. Growing the product and slimming the start turned out to be two separate things.
Booting an OS
Opening OpenStation from scratch costs more than opening a single classic page, and it always will: the desktop loads its own document and a real admin screen inside a window. That is the honest price of a desktop.
But it used to be much worse. A boot was two server renders running strictly one after the other — your window’s page couldn’t even be asked for until the shell’s HTML had arrived and built a frame, nearly four seconds in. And the shell can never fix that from inside itself: by the time its code exists, those seconds are already spent.
The service worker can, because the browser wakes it for the shell’s own request, before the server has even finished answering. It now starts your windows’ pages right then, in parallel, using what the last session told it.
Window pages went from 1,247–1,353 ms to 1–2 ms, a whole boot from 6,492 ms to 5,183 ms, and the first usable window now arrives 1.7 seconds sooner.
Two experiments you can switch on
1. A cache shared by every window
Every window is a real admin page, and real admin pages are heavy — 117–147 requests for a screen like Settings. But a service worker sees every request from every window, so versioned admin assets now come from one cache bucket shared by all of them.
With it on, opening a window makes zero network requests for cacheable assets. A cache hit costs 0.8–2.3 ms instead of 176–260 ms over the network — roughly a 100× advantage per request, and it holds for the heavy stuff too.
One accidental proof that the shared part is real: during testing a file came back in 2 ms on what should have been a cold fetch, because a completely different window had already put it in the bucket. That’s the whole idea — every window you open makes the next one faster.
2. Windows that start loading before you click
The page itself can’t be cached — admin HTML carries nonces and per-request state. But it doesn’t have to wait for the click.
A sustained hover on a dock icon is a strong hint about your next click, so a 180 ms hover now builds that window hidden and starts loading it while you’re still deciding. Click, and the desktop simply adopts it.
A normal window open took 2,000 ms. The same open against a prewarmed window took 3.3 ms. If you never click, the speculative window quietly disposes of itself after 45 seconds — invisible to sessions, taskbar and Alt-Tab the whole time.
And because our last two releases were spent on that diet, we checked the cost of the features themselves: +0 asset requests, +0.01% boot document. The boot path is untouched.
Three things measuring turned up
Measuring properly has a way of surfacing things nobody was looking for. In ascending order of embarrassment:
- Windows were loading a toolbar they never draw. Eight files, about 49 KB, working on something that isn’t even in the page. Removed, along with the emoji script the block editor already drops: nine fewer files and ~71 KB per window.
- The biggest thing in the page was us. The little program OpenStation puts inside every window was written into the HTML in full, unminified — about 125 KB, the largest block in the document, and the one thing no cache could ever help with. It’s now a proper file: 34 KB, fetched once and reused, and the page each window delivers went from 76 KB to 37 KB.
- On WordPress.com, our service worker had never executed. Ever. The platform’s nginx short-circuited the address it lived at, silently, for the whole life of the feature. It now lives somewhere that always reaches WordPress — and as far as we know, openstation.blog is the first WordPress.com site this service worker has ever run on.
Which is really the lesson of both releases: don’t trust intentions, measure what the browser actually downloads. Several features we were sure loaded on demand were being quietly bundled back into the startup. We now have an automatic check that fails the build if anything heavy sneaks back in.
The scoreboard
| Measurement | Classic wp-admin | OpenStation |
|---|---|---|
| Returning to a screen you already have open | 1,903–3,326 ms, every time | 0.6 ms median |
| Six screen changes | 14.6 s | 8.0 s |
| Typical single screen change | 2.1 s | 1.0 s |
| Cold start, from nothing | 3,494 ms | 5,183 ms — the one-time boot |
| Asset requests per window (cache on) | 117–143 every navigation | 0 on the network |
| Per-asset fetch, browser-cold | 176–260 ms | 0.8–2.3 ms |
| Opening a new screen from the dock | 1,903–3,326 ms | 3.3 ms on a prewarm hit |
| Startup download, 3G | — | ~10 s in 1.0 → ~2 s |
| The page each window delivers | — | 76 KB → 37 KB |
The point
Classic wp-admin has one speed and it never improves. Every screen costs what it cost the first time you saw it — today, tomorrow, and in five years.
OpenStation asks for a little more when you sit down, and then gets out of your way. Screens you have open are instant. Screens you move between cost half what they used to. The assets behind them stop touching the network, and the pages start loading before you click.
The longer your session runs, the further those two lines diverge — which is precisely backwards from how WordPress admin performance has worked until now.
Both experiments land in version 1.1.4 under OpenStation Preferences → Features → Beta features: “Shared asset cache” and “Prewarm windows on hover”. They’re off by default while they gather real-world mileage — which is also an invitation. Turn them on, and tell us what your numbers look like.
How the 3G and 4G seconds were calculated: we measured the compressed size of every file OpenStation makes the browser download at startup, rebuilding version 1.0.0 from its release tag and measuring today’s build the same way, then divided by the standard 1.6 Mbps and 12 Mbps profiles browser developer tools use. Real devices also spend time processing those files, so real-world differences are slightly larger than the table shows, never smaller. Everything else was measured live on openstation.blog.
