OpenStation is a free WordPress plugin that turns wp-admin into a desktop. Every admin screen opens in its own window that you can move, resize and keep open next to the others. You can try it in your browser right now, with nothing to install.
Most of us spend the day jumping between screens in wp-admin. You open a post, go back to the list, check the media library, then go back again. With OpenStation, those screens stay open side by side, so you don’t lose your place.
What you get
A window for every admin page: posts, media, settings, plugins
A dock with your whole admin menu, including your other plugins
Several desktops, for example one for writing and one for site settings
Wallpapers, widgets and accent colors
Cmd+K to jump anywhere fast
Your windows are still open when you come back
Try it in your browser
Go to the OpenStation page on WordPress.org and click Live Preview. It runs a full WordPress site with OpenStation in your browser tab, so you can’t break anything.
Install it on your site
In your admin, go to Plugins → Add New and search for “OpenStation”
Click Install Now, then Activate
Click the desktop icon in the top-right corner of the admin bar
It’s safe to try
OpenStation is opt-in for each user, so the rest of your team keeps the normal admin. Click the same icon to go back to the classic view. If you deactivate the plugin, wp-admin goes back to exactly how it was. It doesn’t change WordPress core.
Almost a third of our source code was comments. I deleted all of them and asked an AI agent to build the same features on both versions of the codebase, three times each. The code it wrote was just as good with or without comments.
If you use agents on a real codebase and wonder whether comments help them, slow them down, or don’t matter, here’s what I found.
Why I tried this
In this video (around 23:07), Lauren mentions that they don’t let their agents write comments in the code. Our codebase, is the opposite: it’s full of comments, and most of them were written by agents.
So I wondered: are all those comments helping the agent, or are they just extra text it has to read?
The experiment in one paragraph
I made a copy of the codebase with every comment removed, about 168,000 lines in total. Then I gave the same task to the same agent on both copies, three times on each, and checked the results the same way. I did this for two tasks, a small one and a bigger one.
The results
Every run passed every check: lint, type checks and the existing tests, plus, on the bigger task, a hidden test the agent never saw. A separate AI judge scored each result without knowing which copy it came from (more on that below).
Small task: tile all open windows (score out of 19)
Branch
Score
Tokens
Cost
With comments
18.3
2.18M
$1.42
Without
19.0
1.71M
$1.04
Bigger task: keep a window on top (score out of 23)
Branch
Score
Tokens
Cost
With comments
21.7
9.06M
$3.84
Without
22.0
9.12M
$3.95
The numbers are averages of three runs. The score differences are within noise, and so is the cost on the bigger task. On the small task, the agent used about 22% fewer tokens without comments, which makes sense: there was simply less to read.
The bigger task had a trap. The pinned state has to survive a page reload, and the PHP function that saves the window session drops any key it doesn’t know. Miss it and the feature looks fine until you reload. That’s exactly the kind of thing you’d expect a comment to help with. All six runs found it, with and without comments.
Why one run is not enough
My first plan was to run each branch once. I’m glad I didn’t.
On the bigger task, the three runs with comments used 8.21M, 8.79M and 10.17M tokens. The three runs without comments used 7.01M, 9.70M and 10.64M.
If I had picked one run from each branch, I could have written two opposite blog posts. Comparing 10.64M with 8.21M, removing comments makes the agent 30% more expensive. Comparing 7.01M with 10.17M, it makes the agent 31% cheaper. Same task, same code, same day.
Agents are not deterministic. If you’re measuring one, run it more than once.
How I ran it
The agent: Claude Code with Opus 5.5 at high effort. Same model and settings for every run.
The two codebases: our main branch, and a copy with the comments removed. I compiled both and checked that the resulting code is identical. The only comments left are the ones the tools need to work, such as lint directives and plugin headers, about 800 lines.
The tasks: two real features, with the same prompt on both branches.
The checks: the project’s own lint, type checks and tests. On the bigger task, also a hidden test I added after the agent finished, so it couldn’t write code just to pass it.
The judge: a separate Claude session read each change and scored it against a checklist written before the runs: does it work, does it follow the project’s conventions, does it have tests, and so on. The changes were labelled with random names, so the judge didn’t know which branch each one came from.
The runs: three per branch per task, alternating branches so that time of day affected both equally.
My conclusion
For the agent, code comments don’t make a difference to the quality of the code it writes. They don’t help, and they don’t hurt.
So keep a comment or delete it based on what it does for the people reading the code, not for the agent.
This doesn’t prove comments have zero effect. I tested one model, two tasks and three runs per branch, which is enough to rule out a big effect, not a small one.
Next: comments made no difference, but removing our docs/ folder and AGENTS.md did. That’s the next post.
I’ve been wondering how far a theme can take OpenStation. Not just a wallpaper and a different color, but everything: windows, dock, menus, fonts, icons, layouts, etc. So I tried to make wp-admin look like two operating systems from a long time ago.
Can you believe that this is still WordPress? Turns out that the web is still fun! You only need WordPress, OpenStation, and one of these two themes.
Retro 95 reimagines wp-admin as Windows 95. It even comes with a Start menu! And the classic clock sitting in the bottom-right corner is also there. You can try it live.
Retro 84 is the counterpart for Apple fans. It turns wp-admin into the first graphical OS that many people ever saw: the original Macintosh’s System 1. The beloved monochrome display, the classic pixelated font, and more! Check out the live demo.
And here’s a fun fact: every icon is pixel art typed into a text file, one character per pixel. The fonts were also made the same way, letter by letter.
Underneath, it’s the same wp-admin as always, just a few decades older.
If you want to build your own theme, the docs list everything a theme can change. Maybe it’s time for a proper Windows Vista comeback.
A few days ago, someone opened a support thread about AllTerrain Forms and, in the middle of otherwise useful feedback, wrote something very direct: “I hate OpenStation.”
Obviously that is not the nicest sentence to read when you are working on the product, but at the same time it immediately got my attention because this is exactly the kind of feedback that can be useful if you don’t take it personally.
So instead of trying to explain why OpenStation is good, or why we made certain decisions, I asked a very simple question: what exactly makes you hate it?
Her answer was actually very good.
She works on a laptop, so screen space matters a lot. OpenStation was opening windows too small for her workflow, which meant that one of her first actions was always maximizing them. She also didn’t like losing the visible URL because she regularly copies URLs into emails, project trackers or messages. On top of that, her users are not very technical, and from her point of view OpenStation was adding another layer to WordPress that she would eventually have to explain and support.
She basically said that browser tabs already exist, users understand them, they use the whole screen, and they don’t hide the URL.
And I think this is exactly where building software becomes interesting, because from our side all of those decisions had reasons behind them, but reasons don’t really matter if the final experience is worse for the person using it.
None of these are theoretical product discussions. They are very concrete things that someone hit while trying to use the software for real work.
That matters a lot to me.
We started discussing these points immediately, and one of them has already made it into the next OpenStation release.
Users will now be able to choose how new windows open: using the current default behaviour, maximized, or focused. Focused mode maximizes the new window and minimizes the other windows on the same desk, so people working on smaller screens can have something much closer to the experience they expect.
This came directly from that kind of feedback, and the implementation is already merged:
We obviously have our own vision for OpenStation. We believe WordPress can have a much better working environment than the traditional admin experience, and there are many things we still want to explore there. But having a strong idea of where the product should go does not mean pretending every decision we make is correct.
Sometimes the most useful feedback is not “great release” or “this looks amazing”. Sometimes it is someone telling you that a window is too small, that they want the URL back, that something scrolls when it shouldn’t, or simply that they don’t see the benefit of what you built.
That kind of feedback forces you to look at the product from outside your own head, which is probably one of the hardest things to do when you have been working on it every day for months.
For me, OpenStation becoming more mature is not only about adding more apps, more features or more ambitious ideas. A big part of maturity is improving all those small things that make the product feel natural, predictable and less annoying to use.
And I think there is also something important here about open source. People can complain, explain exactly what does not work for them, and a few days later they can literally see the code that changes that behaviour.
That is a pretty healthy way to build software.
So yes, tell us when OpenStation is great, but especially tell us when it sucks. We may not agree with every suggestion, and we obviously cannot build every requested feature, but if there is a real problem behind the feedback, we want to understand it.
In this case, someone said “I hate OpenStation.”
Fair enough.
A few days later, OpenStation got better because of it.
15 years stuck in the same wp-admin, why don’t you try in playground the new wp-admin experience?
WordPress has spent the last fifteen years becoming capable of doing almost everything, yet somehow we have continued interacting with wp-admin in fundamentally the same way: click somewhere, load another screen, go back, open another tab because you do not want to lose the previous one, and after a while end up with ten different WordPress tabs scattered across your browser.
I find it quite funny that we all accepted this as completely normal.
Today WordPress is used to run stores, publications, membership sites, communities, LMS platforms, agencies and entire businesses. We have plugins that are effectively full applications, incredibly complex editing experiences, analytics, forms, CRM systems, media tools, commerce, automation and thousands of other things living inside the same installation. Yet the interface connecting all of them still assumes that, most of the time, you want to look at one thing at once.
And when you don’t, the browser has to solve the problem for us.
Browser tabs have essentially become the window manager of WordPress.
That is one of the ideas that eventually led us to OpenStation.
Why don’t we have windows?
It sounds ridiculously obvious when you phrase it like that, but that is exactly why I find the question interesting.
On a normal computer I can have my editor open next to a browser, keep a terminal in the background, drag files around, minimize something I want to return to later, or simply arrange my workspace around whatever I am doing at that moment. Nobody thinks about this as a feature anymore because it is just how computers work.
Then we open WordPress and suddenly that whole model disappears.
If I am editing a post and need something from the Media Library, I navigate away or open another tab. If I am checking an order while editing a product, another tab. If I want to compare two posts, another tab. If I am configuring something and need to check how another part of the site is set up, another tab.
There is nothing technically wrong with that, of course, and it has worked for years, but after building and using OpenStation every day I started noticing how much context we constantly throw away simply because wp-admin was designed around pages rather than workspaces.
That distinction matters much more today than it probably did fifteen years ago.
WordPress quietly became something much bigger
I keep describing WordPress as the operating system of the web, and obviously I do not mean that literally. What I mean is that WordPress has gradually accumulated many of the characteristics you would expect from a platform where applications live.
Plugins install capabilities into it. Users have identities and permissions. Applications share data. We have APIs, scheduled processes, notifications, media, editors, databases and an enormous ecosystem of software that knows how to work with the same underlying environment.
The strange part is that the interface never fully made the same transition.
We kept adding more applications to WordPress, but we continued presenting them largely as destinations in a menu.
OpenStation started from a very simple thought: what happens if, instead of redesigning every individual wp-admin page again, we change the environment in which those pages live?
That immediately opens a much larger set of possibilities.
A post editor does not need to replace your media library on screen. A WooCommerce order does not need to replace the product you were editing. A plugin screen does not necessarily need to occupy the entire browser just because you clicked its menu item.
They can simply be windows.
You can move them, resize them, minimize them, keep several of them open, organise them across different desktops and return to exactly what you were doing without recreating the context again.
The funny thing is that none of this feels particularly futuristic. Quite the opposite. We have been using computers this way for decades.
We just somehow never brought that interaction model into wp-admin.
The interesting part is not actually the windows
The windows are what people notice first because they are visual, but I think the more important idea is what happens once WordPress stops assuming that navigation must destroy context.
Suddenly the admin becomes a workspace.
You can have the Media Library next to the editor instead of travelling between them. You can keep an order visible while checking something else. You can open notes or widgets without abandoning your current task. Applications can coexist on the same desktop and eventually interact with each other in ways that become much harder when everything is isolated in separate browser tabs.
This is also where things like drag and drop become much more interesting.
If two applications are part of the same environment, moving an image, a product, a post or another WordPress entity between them can become an actual interaction instead of a sequence of copy, navigate, search, paste and navigate back.
And once you start thinking about WordPress this way, a lot of things that initially looked like unrelated OpenStation features start making sense together: windows, the dock, multiple desktops, widgets, the command palette and applications are all different pieces of the same idea.
The goal is not to decorate wp-admin until it looks like a desktop operating system. The goal is to make working in WordPress feel less like navigating a website and more like working inside an environment.
We don’t need to replace wp-admin to do this
This is probably the part I like the most about the approach.
WordPress already has an enormous ecosystem and rebuilding everything would be both unrealistic and, in my opinion, the wrong problem to solve. There are thousands of admin interfaces that already work, plugins developers have spent years building, and workflows users already understand.
OpenStation can sit on top of that rather than asking the ecosystem to start again.
The existing WordPress admin can continue being WordPress. Existing plugins can continue exposing their interfaces. What changes is how those interfaces are presented and how you move between them.
In some ways, I think that is much more interesting than simply designing another admin UI.
We are not trying to decide what every WordPress application should look like. We are trying to give those applications a better place to live.
And once you have that place, building actual OpenStation-native applications becomes possible as well. We have already been experimenting with things like a photo editor, project management tools and forms, but what excites me is not any individual application. It is the idea that WordPress can host an entire collection of tools that feel like they belong to the same workspace instead of a collection of isolated screens connected by a sidebar.
So why did it take fifteen years?
Probably because there was never a single moment where the old model stopped working.
WordPress evolved gradually. A new menu here, another plugin there, a more sophisticated editor, WooCommerce, custom post types, page builders, analytics, SEO tools and so on. Each addition fitted reasonably well into what already existed, so there was never an obvious reason to stop and question the basic interaction model.
But those small changes accumulated.
The WordPress of today asks considerably more from wp-admin than the WordPress of fifteen years ago did, and I think that eventually creates an opportunity to revisit assumptions that once seemed completely reasonable.
The assumption we are questioning with OpenStation is a very simple one:
Why should opening something in WordPress mean leaving everything else behind?
After spending months working this way, I now notice it every time I go back to the traditional flow. I open something, realise I need another part of WordPress, create another browser tab and immediately think: why am I doing this outside WordPress when WordPress itself could manage the workspace?
That is probably the best way I can explain what we are building.
WordPress has had applications for a very long time.
Perhaps what it has been missing all these years is somewhere for those applications to actually live together.
By the way, don’t forget you can always try OpenStation without even installing it in your site, using WordPress playgrounds
Formerly Desktop Mode, now a new way to feel at home in wp-admin.
A plugin can accumulate installs. It is rarer for people to describe it as a new way of thinking. As of September 25, 2026, OpenStation, known in its earliest releases as Desktop Mode, has inspired 23 public WordPress.org reviews: 22 five-star and one four-star.
OpenStation turns the WordPress admin into a spatial workspace: movable windows, a dock, a taskbar, widgets and virtual desktops. That is the feature list. The feeling is better told by the people who use it.
The words that stopped us in our tracks
1. When a plugin becomes the default
“I can’t imagine using WordPress any other way. I love this plugin so much.”
That may be the highest compliment a tool can earn: not merely useful, but difficult to imagine living without. Nick’s review reads less like a rating and more like an invitation to join a movement.
OpenStation begins as a striking visual idea, then quietly rewires expectations. Once several admin screens can live together, the old one-page-at-a-time flow feels surprisingly distant.
2. When the metaphor improves the work
“It genuinely feels like using a lightweight operating system inside WordPress.”
The operating-system metaphor is not decoration. Windows hold context. The dock makes tools reachable. Virtual desktops separate kinds of work. The familiar desktop grammar turns multitasking into something visible and natural.
“Having several admin screens open at once changed how I work more than I expected.”
Juan’s review is especially telling: he has run OpenStation in production since the Desktop Mode days and builds integrations against it. The novelty faded; the workflow remained.
3. When delight becomes productive
“The desktop-style layout, draggable windows, dock, and taskbar make the admin area feel completely different in the best way.”
Productivity software does not have to be joyless. The best interfaces reduce friction and add a little momentum, the feeling that the workspace is helping rather than merely waiting.
“This plugin blowed my mind. It turns your wordpress admin in such a beautiful dashboard. What an experience.”
Both reviews point to the same achievement: OpenStation is not chasing a generic “modern admin” look. It has a point of view—spatial, extensible and unmistakably its own.
From Desktop Mode to OpenStation
The project’s name changed because its ambition outgrew a mode. “Desktop Mode” described the first transformation. OpenStation describes the platform emerging around it: a place where WordPress apps, windows, widgets and workflows can meet.
“The integration surface is unusually well behaved for a plugin this ambitious.”
That sentence matters as much as the praise for the interface. The magic users see is supported by a public API that plugin authors can build on, frequent releases and an opt-in design that keeps classic WordPress one click away.
The best roadmap is a chorus
Names change. Interfaces evolve. Code ships, breaks, improves and ships again. What stays constant in these reviews is the feeling that WordPress can be more personal, more spatial and more alive.
OpenStation is still moving fast. But if the people already living in it are any guide, the destination is worth watching, and the journey is already changing how they work.
Then, as usually happens, I needed a picture, so I dragged one straight from my desktop into OpenStation. No downloading, no extra tabs needed, no extra spaces in the editor, no more “in which tab was the image!?”… I just dragged it from my desktop…
Done!
And then I thought the post was already descriptive enough to tell how much we enjoy creating content in OpenStation… But I missed the preview. I wanted to see what the post would look like and edit it in real time. And it happened, I just had to click on the eye icon in the title bar of this editor.
This is probably my favourite kind of productivity, the boring stuff becoming pleasantly simple…
And yes, this whole post was written while recording the video 🙂
But I thought that a quick sanity review from one of my bots would make the post nicer for SEO. So I just saved the draft, and gave it to my agent 😉
And the best part, is that EVERYTHING that my Agent did, is traceable.
I have been using WordPress for a long time, and I still love it. But wp-admin has basically worked in the same way for years.
OpenStation is our attempt to change that.
It’s a simple idea: instead of moving from one admin page to another, you have a desktop where you can open different parts of WordPress at the same time.
Your WordPress. Your workspace.
You can open your posts, pages, media, plugins, WooCommerce or any OpenStation app in different windows.
You can move them around, minimize them or put two things next to each other.
It may sound like a small difference, but once you start using WordPress this way, it changes a lot.
Real-time previews
You can also see your changes while you are working on them.
No need to constantly jump between wp-admin and the frontend just to check how something looks.
Apps inside WordPress
This is one of my favorite parts.
We are building apps like AllTerrain Forms, Photo Editor (And more!) specifically for OpenStation.
They are still WordPress plugins, but they feel much more like normal desktop apps.
WordPress on your phone
We also wanted OpenStation to work properly on mobile.
You can install it as a PWA and use WordPress from your phone almost like any other app.
Performance Is Fast. Really fast.
OpenStation is not only about changing how WordPress looks.
We have put a lot of work into making it fast. In many cases, opening and moving between WordPress screens is faster than using them directly from wp-admin.
We are also working on caching and preloading parts of WordPress before you need them.
The goal is very simple: you click something and it opens FAST.
And it is still WordPress
This is important.
We are not trying to replace WordPress or build another platform on top of it.
Your plugins are still your plugins. WooCommerce is still WooCommerce. Your content stays in WordPress.
OpenStation just gives you a different way to use all of it.
And, of course, it is open source.
Thank you
And finally, a big thank you to everyone in the WordPress community who has tried OpenStation, shared feedback, reported bugs or simply told others about it.
And especially to all the contributors who are helping us build it. OpenStation would not be what it is today without you.
There is still a lot we want to do, and seeing people contributing, experimenting and building things with OpenStation is probably the best part of the whole project.
This post is long overdue, but here it is. The process behind the OpenStation brand, which is, to date, one of the most fun projects I’ve ever worked on. 💜
A name we didn’t have
Here’s the crazy part: I started designing the brand before we even had a name. We had vibes, we had concepts, we had people brainstorming names, and zero idea what would come out. Eventually, after a lot of back and forth, we settled on OpenStation.
That opened the door to many possibilities. Mostly it opened the door to me finally being allowed to draw.
Visual chaos
I started where I always start, which is paper. Advanced technology.
Ugly little drawings, lines, the same shape drawn thirteen times… Then a couple (or a hundred) of hours on Pinterest saving anything that sparkled in my eyes, and a Figma board where I dumped it all and started grouping.
And then, I started feeding the machines.
I dumped my chaos to AI: a sketch, a color, a screenshot, a note that said not this, more the other (which is apparently a valid prompt now). It came back with fifteen things, half of them wrong. That wrongness sent me back to the board. I drew again. I fed it again. AI → Figma → Pinterest → AI → Figma… and repeat.
This, for three days.
Locking the concept: Spaceholowave
Don’t search for that because I invented it.
It’s a mix between Space + Holodoor + Synthwave. I kinda wanted to play with some holographic and vibrant elements, Cyberpunk style, floating on the dark void.
I won’t go into the details of why I know this game or how many hours I spent playing it, but I also will add that on top of that visual reference, I had the Stargate door and Dragon Ball capsules.
You see where I’m going with this, right? Forcing all my nerd references into something that had to make sense.
The logo + Mio
Is it a holo window? A helmet? A candy? A marble? Yes. Or no. You decide, honestly, I’ve stopped thinking at this point.
What I knew was that the O and the S had to live inside the same shape, so it went through a lot of shapes until it became this:
I don’t know if Mio came before the logo or after. I think they happened to each other, actually.
But basically, the mark has two shapes: the ring, and the curve carved out of it, which looks like a blob. That’s Mio. Our station resident. He’s the logo’s negative space and turned into a small ghost that glows, making your space a tad more lively.
Designing Mio is probably one of the most fun things I’ve done in my adult years. 💜
Merchandise makes things real
Logo and Mio in hand, I let the AI go bananas on merchandise. Holographic stickers, enamel pins, the works. We didn’t need stickers on day two. But nothing tells you whether a brand holds up like seeing it on a pin the size of a one-euro coin. If it survives that, it survives a favicon.
And little by little the brand was forming.
The types are Geist and Geist Mono: open source, Vercel did a lovely job with them, and they sit right where we live, somewhere between space and a terminal.
Colors were obvious: holo pink over the void. Something that stands out on a dark screen and, big point here, stays accessible.
The brand is alive
Three days of brand sprint saved us weeks of “should this be rounder” conversations.
Not because the brand is perfect. Because the brand guideline is alive, public, and hooked into the agents we use, so anyone on the team can make a wallpaper or a widget icon and it comes out looking like part of one big happy Mio family.
OpenStation turns your WordPress admin into a desktop: windows, a dock, screens you can leave open while you work on something else. Last time we measured how fast it starts. This time we went screen by screen, head to head against classic wp-admin, on the same site, the same account, the same sitting.
Every number below was measured on the site you are reading right now, over a real network, on real WordPress.com hosting.
The short version
Opening a screen: 25% to 54% less time in the browser, on all four screens we tried.
Going back to a screen you already have open: instant, because nothing reloads. Classic makes you wait 2.4 to 3.7 seconds for the same thing.
Starting the desktop: about 1.7 seconds slower than a classic Dashboard, once. That one goes to classic wp-admin, and we will come back to it.
Opening a screen
This is the part you feel all day. The numbers are the time the browser spent, measured as load minus time-to-first-byte (TTFB). Subtracting TTFB takes the hosting out of it: the server does the same work either way, so what is left is the part we are responsible for.
Screen
OpenStation
Classic wp-admin
Difference
Posts
1172 ms
1559 ms
25% less
Media
823 ms
1528 ms
46% less
Plugins
782 ms
1711 ms
54% less
Post editor
895 ms
1960 ms
54% less
Time in the browser after the first byte. Medians, nine samples per screen (five for the editor).
The heavier the screen, the bigger the gap. The post editor, the heaviest thing in wp-admin, saves the most: about a second, every time you open a post. TTFB stayed level between the two, within 100 ms on every screen, which is what you would expect when the server is doing identical work.
We checked whether the averages were lying
A median can hide a lot, so here is every sample, slowest to fastest. On three of the four screens the two ranges never touch: our slowest run still beat their fastest one.
Screen
OpenStation
Classic wp-admin
Overlap
Posts
740 to 1381 ms
1220 to 2012 ms
slight
Media
606 to 1235 ms
1363 to 1916 ms
none
Plugins
502 to 1052 ms
1384 to 1867 ms
none
Post editor
701 to 1243 ms
1510 to 2293 ms
none
Posts is the only screen where the two graze each other. Everywhere else there is clean air between them.
The part where we lose
The desktop has to boot before it can show you anything, and classic wp-admin does not. Loading the shell with the Dashboard in a window took 7.2 seconds, against 5.5 for the classic Dashboard. That is about 1.7 seconds more, once, when you arrive.
Then it starts paying you back. Every screen you open gives back roughly 760 ms, so you are ahead by the third one, and each time you return to something already open you save another 2.5 seconds. Three screens and you have broken even. A working morning is not close.
Why it is faster
None of this is a measurement trick, it is just how the two work. Classic wp-admin throws the whole admin away every time you click: the menu, the toolbar, the shared scripts and styles, rebuilt from scratch, every time. OpenStation loads that once and keeps it. A window then fetches a stripped-down admin page that does not build the toolbar or the menu at all, and whose stylesheets were already fetched the first time you opened it.
And going back to an open window is not a page load at all. It is a focus change, so there is nothing to wait for.
How we measured it
One site, one account, one sitting. The two sides alternated in blocks, so a slow minute on the host hits both of them equally.
The same metric on both sides. Both report PerformanceNavigationTiming from the document you are actually looking at. For OpenStation that is the window’s own document. No mismatched metrics, no thumb on the scale.
A real baseline. Classic wp-admin was rendered on this same site through a per-request flag, checked on every sample: no desktop, with the admin menu and toolbar exactly where they should be.
Two samples binned. Two classic readings were taken before the load event had fired, so Posts has seven samples on that side instead of nine.
Warm cache, live host. TTFB wandered between 788 and 1825 ms across the session, which is exactly why we report it separately.
One thing we did not measure: a properly cold cache. Emptying it properly also means clearing the site data, which signs you out, and that was not something we were going to do before every single sample on a live site. It is the rarer case anyway. You pay for a cold cache once per browser, not once per session, so the warm numbers are the ones you actually live with.
Everything above is OpenStation 1.1.4, measured against classic wp-admin on the same site. It is the desktop against the classic admin, not one release against another.
And if you don’t believe me, watch these YouTube videos:
Note: AI was used for the measurement and the first draft, I did the editing. If you want the method and every number we collected, the technical report is here.
