Stopwatch tests on identical hardware, mailbox, and network showed new Outlook took ~10 seconds to open an email versus under a second for Outlook Classic, with 5-15x slowdowns across folder switches, attachment previews, and composition. The numbers reflect a fundamental gap between a WebView2-wrapped web app talking to Exchange over HTTPS and a native Win32/MAPI client reading from a local OST file.
Argues Microsoft's 'still maturing' framing is misleading because the performance gap stems from replacing a native MAPI client with a browser tab wearing a taskbar icon. No amount of optimization closes the latency gap between local OST reads and round-tripping every interaction over HTTPS to Exchange Online.
Frames new Outlook as the consumer face of Project Monarch and the latest entry in a pattern that includes Skype's move from native C++ to Electron and Teams replacing Skype for Business. Each transition was shipped as an upgrade while making the user-facing experience heavier and slower.
Acknowledges that from a Microsoft P&L perspective, collapsing Outlook for Windows, Mac, and web into one web-based codebase is rational: one team, one ship cycle, lower maintenance cost. The tradeoff is borne entirely by end users who now wait 10 seconds to read trivial emails.
Submitted the WindowsLatest piece to Hacker News where it accumulated ~695 points and 481 comments, signaling that performance complaints once confined to enthusiast forums have reached a mainstream technical audience. The strong engagement reflects broad developer frustration with the architectural shift.
WindowsLatest ran a stopwatch test on the same Windows 11 machine, same mailbox, same network: opening a single email in new Outlook took roughly 10 seconds; Outlook Classic opened it in under a second. Folder switches, attachment previews, composing a new message — every interaction came in 5–15x slower on the new client. The piece is the latest in a year-long pile of similar measurements, but the numbers are now coming from a mainstream Windows outlet rather than enthusiast forums, and the Hacker News thread (~695 points) made it impossible to dismiss as nerd grievance.
The story Microsoft will tell you is that the new Outlook is "still maturing" and that performance will close the gap. It won't, because the gap isn't a tuning problem. The new Outlook for Windows is the Outlook on the web codebase, packaged with Microsoft Edge WebView2, talking to Exchange Online over HTTPS. Outlook Classic is a native Win32 / MAPI client that reads and writes a local OST file and only talks to the server to sync deltas. One of these is an architecture optimized for latency. The other is a browser tab with a taskbar icon.
This is the consumer face of what Microsoft internally called Project Monarch — the long-running push to collapse Outlook for Windows, Outlook for Mac, and Outlook on the web into a single web-based client. From a Microsoft P&L perspective the consolidation is rational: one codebase, one team, ship once. From a Tuesday-morning-inbox perspective, you are now waiting 10 seconds to read "Reminder: standup at 10."
The Outlook case isn't isolated; it's the rule. Microsoft has spent a decade replacing fast native Windows apps with slower web-shell equivalents, and shipping each one as an upgrade. Skype went from a native C++ client to Electron and got slower and heavier. Teams replaced Skype for Business — a native client people actually liked — with Electron, then attempted a second rewrite ("Teams 2.0" / WebView2) explicitly because the Electron version was unusable on anything below 16GB RAM. The new Microsoft Store is a web app. Settings is increasingly a web-rendered surface stitched into the old Control Panel. Each migration trades local responsiveness for centralized iteration speed.
The engineering tradeoff is real and worth naming honestly. A web-shell client lets Microsoft ship a feature once and have it appear on Windows, Mac, web, and mobile the same week. A native MAPI client requires a Windows team, a Mac team, and a sync engine team — three separate release trains, three QA matrices, three bug backlogs. For a company optimizing for engineering throughput at planetary scale, the math always points at "one web codebase." The cost just doesn't show up on Microsoft's balance sheet — it shows up in your day, in 10-second increments.
What the HN thread surfaced that the article didn't: a lot of this latency is server round-trips for operations that used to be local. Marking a message read, expanding a folder, searching — Classic does these against the local OST in microseconds. New Outlook posts them to Exchange Online and waits for a response. If you're on a coffee-shop Wi-Fi or your tenant happens to be on a slow Exchange shard, every click is a network event. The "slow on a beefy machine" complaints are the giveaway: faster hardware doesn't fix RTT.
There's a second cost that doesn't get measured in seconds: offline behavior. Classic Outlook is a working email client on a plane with no Wi-Fi. New Outlook degrades to a read-only cache of recently-synced messages with limited functionality, and many users report search and folder navigation breaking entirely without a connection. For a class of professionals — lawyers, sales reps, anyone who lives in transit — this is a regression that no perf tuning will undo.
First, the migration calendar is still real. Microsoft has signaled that Classic Outlook support continues through 2029 for commercial customers, but new tenants are increasingly defaulted to the new client, and the "Try the new Outlook" toggle has become a one-way door in several Insider builds. If you're an IT lead, build your rollout plan around the architecture, not the marketing — assume new Outlook will be the only option, and budget for the help-desk volume that comes with making a power-user tool 10x slower.
Second, the alternatives are narrower than they were five years ago. Thunderbird has had a serious renaissance under MZLA stewardship and now handles Exchange via the Owl add-on or native EWS in recent builds. Mailbird and eM Client are commercial options that still ship native Win32. For teams on Microsoft 365, the Outlook for Mac native client (the pre-Monarch one) is still maintained for now and is the only first-party native option left. None of these are drop-in replacements for an org with 5,000 calendar delegations and a custom add-in, but for individuals, the escape hatch exists.
Third, if you're building desktop software, the Outlook trajectory is a market signal. The Electron / WebView2 wave is producing a generation of apps that are slower than the things they replaced, on hardware that's 10x more powerful than the hardware that ran the originals. Users have noticed, and "native and fast" is becoming a marketing claim again — see the traction of Zed against VS Code, Linear against Jira, Raycast against Spotlight clones. There's an opening for native-first desktop apps in 2026 that didn't exist in 2020.
The interesting question isn't whether new Outlook will get faster — it'll get incrementally better, the way Teams 2.0 was incrementally better than Teams 1.0, without ever closing the gap to Skype for Business. The interesting question is whether the architectural pendulum starts to swing back for the next generation of business software. WebAssembly, local-first sync engines, and SQLite-in-the-browser are making it possible to build web-deployed apps that don't require a server round-trip for every click. The companies that figure out how to ship a single codebase and sub-100ms interactions are going to eat the current incumbents' lunch. Microsoft has the engineering muscle to do this. Whether it has the institutional patience is a separate question.
> Outlook is based on WebView2, and like all web apps, it’s slowFastmail also has a web based email client, which is as fast as (if not faster than) Outlook Classic.The new Outlook is just bad. Load order is wrong, it renders everything on every window, loads unnecessary data, etc. Plain annoying
And to think that the "old" Outlook's splash screen is there for a reason: it used to take a while to open before SSDs became commonplace! Windows in general used to be usable on HDDs; SSDs would blow everyone's pants off making everything open instantly. These days we have 20+ G
Started a new job, with Windows 11. notepad.exe now takes 3 to 4 seconds to load on my work system... (even after closing the last tab and reopening the program).Hah, it even has in-app purchases, for AI writing...
Genuinely curious how quality is so poor at MS. Tech debt and deadlines and red tape?This is the company that invented the term dogfooding and forced everyone to use Exchange until all the bugs were worked out.I’m building a next gen web mail app at work and there are a ton of UX edge cases but the
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Up until 2019, Windows was my daily driver and had been for the prior ~20. years. I had been regularly ssh-ing into Linux machines, but it didn't seem like a place I could live. Then, in 2019, I built a PC and, wanting to get more proficient in Linux environments, I made it a dual boot setup wi