Some of the slowness in S3 had nothing to do with the network. While a page loaded, S3 did extra work on every small progress step, and the more tabs you had open, the more work it was. 2.4.4 removes that work.
What was slow
WebKit reports a page's loading progress dozens of times per load. On every one of those reports, S3 recomputed the state of every open tab and redrew its interface three times, on the same thread that handles scrolling and clicks. With a hundred tabs, a hundred progress reports cost about 400 ms of blocked time.
Now a progress-only change skips that recomputation. Loading, address, title, history and error changes are still handled immediately, exactly as before.
100 tabs, 100 progress reports: 403 ms → under 1 ms
Freezes longer than 100 ms across 543 real page loads: 36 → 0
Longest freeze: 2.5 s → 91 ms
Lighter pages
On sites that are allowed to autoplay, S3 used to watch every change on the page and search it for audio and video, even though there was nothing to block. Busy pages like YouTube change constantly. S3 now only watches while a blocking rule is actually on. Your autoplay settings work exactly as they did.
How we measured
Three Codex workers loaded YouTube, ChatGPT, X, Apple and Wikipedia more than 2,200 times on the same Mac, interleaving a plain WebKit view with S3's real configuration and switching S3's features off one at a time. Every run used a throwaway profile; no account was signed in. With a clean profile S3 was within about 0.1–0.2 s of plain WebKit, and YouTube thumbnails filled in on every scroll test. The large freezes came from the session itself, which is what this release fixes.
We also tried a passkey change for sign-in pages. An independent review found it could send some sites down a sign-in path that cannot work here, so we kept the existing, field-tested behavior.
Download S3 Browser 2.4.4 · the update also arrives inside S3: when it is ready, choose Restart to Install.