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.
Your admin boots like an operating system, and then behaves like one.
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.
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.
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.
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 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.
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.
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.
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.
Measuring properly has a way of surfacing things nobody was looking for. In ascending order of embarrassment:
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.
| 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 |
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.
Kōkua Hawaiʻi Foundation acquired unused farmland on Oʻahu in 2019 to create an educational resource.…
Under Section 56(2)(x), there is applicable taxation of such a difference in the buyer's hands…
A food delivery worker was filmed urinating in the elevator of Akshay Co-operative Housing Society…
Researchers utilized fluorescein dye in the Rockall Trough to study deep ocean water upwelling. They…
On October 2, a remarkable event unfolded as several Indian startups managed to send payloads…