Somebody asked for numbers instead of adjectives. Same Mac, same afternoon, same pages: Search, Chrome and Safari launched one after another and weighed the same way. Every figure is a real run; the runs are at the bottom.

Apple M3 Pro, 36 GB, macOS 26.6.2. Search build 202609231334, the afternoon's build before 1.0; Chrome 153.0.8010.53; Safari 26.6.2. Dia was in use with a live session and could not be measured fairly; only its size appears.

The first measurement was of Search's first build. It has since gained tab sleep, passkeys, Chrome extensions and a Web Store that installs into it, so it was weighed again to see what that cost. Same Mac, same pages, same method; the other two browsers were measured again beside it.

What changed: nothing got heavier where it shows. With no extension installed, support for them costs at most the two megabytes the empty launch gained, and no process. The app itself is smaller than it was: a release build carried the name of every one of its functions, which it never reads while it runs and which had grown to more than half its size: the version this page offered until today is 5.2 MB on disk, 3 MB of it those names. They are left out now. And five pages handed at launch, the one place Search used to trail, is now a lead as well: the window goes up first and the tabs fill in behind it.

The same five tabs for everyone: a 270 KB local test page, en.wikipedia.org/wiki/Web_browser, apple.com, github.com and youtube.com, handed to each browser at launch — what happens when a link is clicked in another app while the browser is closed. Chrome started from an empty profile, no extensions, no session. Search ran as an isolated copy in a test world of its own, wiped before every run: no extensions, nothing restored, every setting as shipped. Safari has no such switch, so it opened its usual start page as well; its numbers carry that. For the empty launch it was told not to reopen its last session, which it otherwise does.

Memory is the physical footprint of every process the app is responsible for, the way Activity Monitor groups them: Chrome's helpers and renderers, Search's and Safari's WebKit content, network and GPU processes. Read with proc_pid_rusage and summed over processes whose responsible process is the app.

Launch is the time from the launch call to the app's first window on screen, taken from the window server. The three were launched in turn, three rounds, on a Mac that was also running the usual things.

The engine tests run inside the page, in each browser's own JavaScript, and report to a local server. Search uses the WebKit that ships with macOS, Safari's engine, which is why those two columns match. Chrome's runs spread widely from one launch to the next; its best run is the fair one. That is the honest finding: Search renders at Safari's speed and costs a fraction of Chrome's memory; it is not faster at JavaScript than Safari and does not claim to be.

A warning for anyone repeating this: a freshly signed build pays macOS's first-launch inspection, about a second on its first three launches. Warm it up before timing it.

Five tabs is one sitting's worth. This is the other case: twenty pages left open, the way tabs pile up over a day. The same twenty for both browsers, handed at launch and weighed a minute later, loaded. Then Search's nineteen background tabs were put to sleep and it was weighed again.

Same Mac, same day, the same builds as above. Safari was not run: it has no empty-profile switch, and twenty pages opened in it would land in its owner's own history.

The honest finding: loaded, Chrome is still the lighter of the two, by about 260 MB across twenty heavy pages, down from 800 on 22 September; WebKit gives each page more room. What changes the picture is what Search does next. A tab nobody has looked at for half an hour gives its page back and keeps its history, its scroll position and a picture of itself, so with nineteen of the twenty asleep the whole browser weighs about 400 MB, the tab on screen included — and picking a sleeping tab paints it again in a fifth to a quarter of a second, at the same place, with Back still going back. Chrome has its own version, Memory Saver, which frees tabs on its own schedule; a fixed clock can't compare the two fairly, so only the loaded state is shown for it.

The first run timed the wrong Wikipedia tab: the one on screen, which never sleeps. A fourth run replaced it for that column only.

The twenty pages: en.wikipedia.org/wiki/Web_browser, apple.com, github.com, youtube.com, developer.mozilla.org, nytimes.com, theverge.com, bbc.com/news, news.ycombinator.com, stackoverflow.com/questions, figma.com, stripe.com, vercel.com, notion.com, airbnb.com, lemonde.fr, medium.com, spotify.com, theguardian.com and en.wikipedia.org/wiki/WebKit. Chrome started from an empty profile each run; Search from an empty test world, its cache and cookies wiped each run. Memory is weighed as above, sixty seconds after launch.

Asleep was reached through the same code the half-hour timer runs, asked for each background tab at once instead of after half an hour, then weighed twenty seconds later; the tab on screen stays awake, as it always does. Back on screen is the time from picking the tab to the page's own first contentful paint, read from the page.

Measured with a small launch-and-weigh tool written for the purpose. Search is a WebKit browser for macOS by Office Commun.