Lilo and WebKit

Lilo fixes WebKit, for everyone.

Lilo runs on WebKit, the engine Safari uses. When a page is slow or broken because of the engine, we fix it in WebKit itself and send the fix upstream, so Safari and every Mac app that shows the web get it too.

See the patches
Download for MacmacOS 26+GitHub
Sent upstream

Fixes in WebKit itself.

Each one has a WebKit bug and a pull request, and leaves this list once it lands in WebKit.

Removing or changing a style sheet no longer recomputes the style of every element. On Gmail, one removal goes from 25 ms to 4 ms. Bug 329822, pull request #79315.
Images with sizes=auto stop requesting their source again each time their width changes, which could starve the page. Bug 328920, pull request #79337.
Changing a CSS variable that a whole page inherits stops comparing every element's variables in full. With a design system's 2000 variables, 44 ms becomes 10 ms. Bug 329909, pull request #79412.
How we work

Measure, reduce, fix the engine.

Measured on real pages. We profile the sites people use most, compare them with Chrome and with the WebKit of macOS, then reduce each slowdown to a small page any WebKit developer can run.
Generic, never per site. No hostname checks and no quirks for one site: a fix changes how the engine works, so every page gets it.
Upstream first. Every patch goes to WebKit with its bug, a performance test and the numbers, for WebKit's own reviewers.
Never a requirement. Lilo works fully on the WebKit of macOS. Its own WebKit build only brings fixes earlier, and runs only while it holds every security fix of your macOS.
Questions

Lilo and its engine.

Is Lilo just a wrapper around WKWebView?

Lilo shows pages with WKWebView, the way Mac apps embed WebKit. Around it, Lilo is a browser of its own in Swift and AppKit: Spaces, Chrome extensions on WebKit's extension runtime with Swift handlers for the APIs it lacks, terminal tabs and an MCP server. And when the engine is the problem, Lilo fixes the engine.

Do I need anything to get these fixes?

No. Once a fix lands in WebKit, it ships with the next Safari and macOS updates, and Lilo runs on that same WebKit. Lilo's own WebKit build can bring the fixes sooner, and you can readhow it stays safe.

Why fix WebKit instead of switching to Chromium?

WebKit is the engine already in macOS: it draws less power, follows every macOS release, and keeps Lilo a native Mac app. Fixing it helps Safari and every Mac app that shows the web, not only Lilo.

Can I report a slow page?

Yes.Open an issue with the page and what you did. If the engine is the cause, the fix goes to WebKit.

A browser that improves its engine.

Try Lilo on the sites you use. Each fix it sends to WebKit reaches Safari once it lands.

Download for MacmacOS 26+GitHub