Skip to content

Split View: 브라우저 엔진 2026 — Chromium·Gecko·WebKit·Servo·LadyBird, 누가 진짜로 웹을 그리고 있나

|

브라우저 엔진 2026 — Chromium·Gecko·WebKit·Servo·LadyBird, 누가 진짜로 웹을 그리고 있나

프롤로그 — 세 엔진이 웹을 그린다

당신이 지금 이 페이지를 보고 있는 화면 뒤에는 렌더링 엔진이 있다. HTML을 파싱해 DOM 트리를 만들고, CSS를 매칭해 스타일 트리를 만들고, 둘을 합쳐 박스 트리·레이어 트리·페인트 트리로 내려간 다음, GPU에 텍스처를 던지는 — 수십만 줄짜리 C++ 더미. 우리는 이걸 매일 쓰지만 거의 본 적이 없다.

2026년 5월 기준 데스크톱·모바일·태블릿을 모두 합쳐 보면, 세계 웹의 렌더링은 세 엔진이 거의 다 한다.

  • Blink (Chromium 계열) — 약 81%. Chrome, Edge, Brave, Arc, Opera, Vivaldi, Samsung Internet, 그리고 Electron으로 묶인 거의 모든 데스크톱 앱.
  • WebKit (Apple) — 약 14%. Safari, 그리고 — 적어도 EU 밖에서는 — iOS의 모든 브라우저 (Chrome·Firefox·Edge for iOS 포함, App Store 정책으로 WebKit 강제).
  • Gecko (Mozilla) — 약 3%. Firefox와 그 파생들. 마지막 남은 — 진정한 의미에서 — 비-Chromium·비-Apple 메이저 엔진.

이게 끝이다. 셋이 99%를 가져가고, 나머지 1%는 Pale Moon의 Goanna, Ekioh의 GPU 엔진 Flow, 그리고 — 가장 흥미로운 — 처음부터 다시 쓰고 있는 두 야심작 Servo(Mozilla Rust)와 LadyBird(Andreas Kling, 독립)가 나눠 가진다.

이 글은 그 세 엔진과 — 그 너머에서 부활을 시도하는 — 두 인디 엔진의 2026년 현주소를 정리한다. 그리고 묻는다.

우리는 정말 한 엔진이 80% 넘는 웹을 견딜 수 있는가? 세 엔진이 다양성의 마지노선인가? 그리고 — Servo와 LadyBird가 진짜 프로덕션에 도달할 수 있는가?


1장 · 왜 세 엔진이 남았나 — 30년 압축 역사

웹 엔진의 역사는 짧고도 굵다. 압축하면 이렇다.

1.1 1993–2003: Mosaic, Netscape, IE, 그리고 KHTML

  • Mosaic (1993) — 최초의 그래픽 웹 브라우저. NCSA에서 시작해 Netscape로 분기.
  • Netscape Navigator (1994) — Mosaic 출신들이 만든 상용 브라우저. 엔진은 자체 개발. 1998년 오픈소스로 풀리면서 Mozilla 프로젝트가 시작됐고, 거기서 Gecko가 태어났다.
  • Internet Explorer (1995–) — Microsoft가 Mosaic을 라이선스해 Trident 엔진 개발. 1990년대 말 90% 넘는 점유율로 사실상 웹을 좌우.
  • KHTML (1998) — KDE 프로젝트의 Konqueror 브라우저 엔진. 가볍고 깨끗한 C++ 코드베이스. 2003년 Apple이 이걸 포크해 WebKit을 만든다.

1.2 2003–2013: WebKit이 등장하고, Chrome이 모든 걸 바꾼다

  • WebKit (2003) — Apple이 KHTML을 포크. Safari 1.0과 함께 출시.
  • Chrome (2008) — Google이 WebKit을 포크해 자체 V8 자바스크립트 엔진과 결합. 멀티프로세스 아키텍처로 안정성 점프.
  • Blink (2013) — Google이 WebKit에서 갈라져 나와 자체 엔진 시작. 이때 Opera도 자체 Presto 엔진을 버리고 Blink로 옮긴다.

1.3 2013–2020: 단조화의 가속

  • Microsoft Edge (2015) — IE 종료, 자체 EdgeHTML 엔진. 그러나 점유율 회복 실패.
  • Edge → Chromium (2020) — Microsoft가 EdgeHTML을 버리고 Chromium 기반으로 재출발. 이 시점에 데스크톱 엔진은 사실상 세 개로 압축.
  • Servo (2012–2020) — Mozilla가 Rust로 시작한 차세대 엔진. 2020년 Mozilla 대규모 정리해고 때 외부로 이관. 잠시 동면.

1.4 2020–2026: 부활과 균열

  • Servo (2023) — Linux Foundation Europe(LFE)으로 이관, 활성 개발 재개. 2026년 임베디드 데모와 자체 브라우저 셸 시연.
  • LadyBird (2022–) — Andreas Kling(전 Apple WebKit 엔지니어, SerenityOS 창시자)이 SerenityOS 브라우저를 독립 프로젝트로 분기. 2024년 비영리 LadyBird Browser Initiative 설립, Shopify·GitHub 창업자 등으로부터 자금 확보. 첫 Alpha 출시 목표: 2026년 7월 (Linux/macOS). Windows·Android는 더 늦게.
  • iOS WebKit 강제 해제 (2024 EU DMA) — Apple이 EU 한정으로 iOS에서 비-WebKit 엔진을 허용. Chrome iOS의 Blink 기반 버전이 시범 적용. 실제 사용은 더디지만 — 기둥 하나가 흔들리기 시작한 사건.
  • DOJ vs Google 판결 (2024 8월) — 미국 법원이 Google이 검색 시장에서 독점을 유지한다고 판결. 2025년 구제책 단계에서 DOJ가 Chrome 매각을 권고. 2026년 항소 진행 중. 만약 강제되면 — 웹 엔진 지형이 다시 한 번 흔들린다.

이 챕터의 핵심: 3개 엔진은 "안정 상태"가 아니라 누적된 합병의 결과다. 1990년대에는 4–5개가 있었고, 2010년대 중반에 압축됐고, 2020년대 중반부터는 다시 — 작지만 — 발산이 시작되고 있다.


2장 · 엔진별 정밀 해부

소유자: Google (BSD 라이선스, 오픈소스이지만 사실상 단일 회사가 방향 결정)

자바스크립트 엔진: V8

렌더 파이프라인: Blink → cc(컴포지터) → Viz(GPU 프로세스) → Skia/Dawn

채택 브라우저:

  • Chrome (Google)
  • Edge (Microsoft, 2020년 전환)
  • Brave (사생활 강조)
  • Arc / Arc Search (The Browser Company)
  • Opera (2013년 전환)
  • Vivaldi
  • Samsung Internet
  • Yandex Browser
  • Naver Whale
  • 그 외 수십 개의 마이너 포크
  • Electron 기반 데스크톱 앱 전부 (VS Code, Slack, Discord, Notion, Figma desktop 등)
  • Tauri의 일부 옵션 (기본은 OS WebView지만 Bundled Chromium 옵션도 있음)

강점:

  • 가장 빠른 표준 채택. Container Queries, View Transitions, Anchor Positioning 같은 최신 기능을 가장 먼저 출시.
  • 개발자 도구가 산업 표준.
  • WebGPU, WebRTC, 미디어 코덱 지원이 가장 광범위.

약점:

  • 단일 회사가 사실상의 표준을 정의하는 구조. "Blink가 지원하면 표준" 압력.
  • 메모리 사용량이 큼. 탭 하나당 수백 MB.
  • Manifest V3 같은 확장 API 변경에서 사생활/광고 차단 측면 논란.

거버넌스: 형식적으로는 오픈소스이지만 커밋의 거의 100%가 Google 직원. Microsoft가 Edge 채택 이후 일부 기여 (특히 Windows·접근성). Igalia(스페인 컨설팅)가 외부 컨트리뷰터로 의미 있는 비중 차지 — Container Queries, MathML 같은 기능 다수.

2.2 WebKit — Apple의 정원

소유자: Apple (LGPL/BSD 혼합)

자바스크립트 엔진: JavaScriptCore (JSC)

렌더 파이프라인: WebCore → WebKit2 (멀티프로세스) → Metal/CoreAnimation

채택 브라우저/플랫폼:

  • Safari (macOS, iOS, iPadOS, visionOS)
  • iOS의 거의 모든 브라우저 — App Store 정책으로 WebKit 강제 (Chrome iOS, Firefox iOS, Edge iOS, Brave iOS 모두 WebKit 래퍼)
  • 2024년 EU DMA 이후 EU 한정 iOS에서 비-WebKit 허용, 실제 적용은 점진적
  • macOS의 SwiftUI WebView, AppKit WKWebView
  • PlayStation 5 시스템 브라우저
  • Amazon Kindle, BlackBerry, Tizen 등 일부 임베디드

강점:

  • macOS·iOS에서 GPU·미디어 통합이 우수 (Metal 백엔드).
  • 에너지 효율 — 노트북·모바일 배터리 최적화.
  • 사생활 보호 — Intelligent Tracking Prevention(ITP) 선도.

약점:

  • 표준 채택이 느린 경우 다수. WebGPU·WebRTC·OffscreenCanvas·Service Worker 같은 기능에서 Blink/Gecko 대비 1–2년 늦었음.
  • iOS의 WebKit 강제는 진정한 의미에서 — 적어도 EU 밖에서는 — 사용자에게 엔진 선택권을 주지 않음.
  • 개발자 도구가 Blink·Gecko 대비 약함.

거버넌스: Apple 직원이 거의 모든 커밋. Igalia가 외부 기여 의미 있음 (특히 WPE WebKit이라는 임베디드 변종). Sony가 PlayStation 브라우저 관련 일부 기여.

2.3 Gecko — 마지막 비-Chromium 깃발

소유자: Mozilla Foundation / Mozilla Corporation (MPL 2.0)

자바스크립트 엔진: SpiderMonkey

렌더 파이프라인: Gecko → WebRender (Rust 기반 GPU 컴포지터) → Direct3D/Metal/OpenGL

채택 브라우저:

  • Firefox (데스크톱, Android)
  • Firefox ESR (장기 지원)
  • LibreWolf (사생활 강화 포크)
  • Waterfox (오래된 확장 호환)
  • Tor Browser (Firefox ESR 기반)

강점:

  • 가장 강한 사생활 보호. 추적 차단·핑거프린팅 방지가 기본.
  • WebRender — Rust로 다시 쓴 GPU 컴포지터. 합성 단계에서 효율적.
  • 표준 위원회에서 — 비록 작아도 — 균형추 역할.

약점:

  • 인력과 자원이 작음. Mozilla는 2020년·2024년에 큰 정리해고를 거쳤고 2026년 현재 풀타임 엔진 엔지니어는 한 자릿수 후반/두 자릿수 초반.
  • 표준 채택이 종종 Blink보다 6–12개월 늦음. WebGPU는 2025년 후반에야 안정화.
  • 모바일 점유율이 매우 작음 (Android에서 한 자릿수 초반, iOS는 WebKit 래퍼라 실질 점유 0).

거버넌스: Mozilla 단일 회사 주도. 외부 기여가 있긴 하지만 비중 작음. 2024년 이후 — Mozilla가 광고·AI로 사업 다각화를 시도하면서 — "엔진 투자가 줄고 있는 것 아닌가" 하는 논란이 커지는 중. 이른바 "Mozilla의 사명 표류" 논쟁.

2.4 Servo — Rust로 다시 쓰는 미래

소유자: 현재는 Linux Foundation Europe (LFE) 산하 프로젝트 (2023년 이관)

자바스크립트 엔진: SpiderMonkey (Gecko에서 가져옴)

렌더 파이프라인: Rust 풀스택. 병렬 레이아웃·병렬 페인트 — 멀티코어 활용이 설계 핵심.

역사:

  • 2012년 Mozilla Research에서 시작. Rust 언어 자체가 Servo를 위해 진화한 측면이 있음.
  • 일부 Servo 컴포넌트(스타일 시스템, WebRender)는 Gecko로 통합되어 Firefox에 사용됨.
  • 2020년 Mozilla 정리해고로 거의 동면.
  • 2023년 LFE가 운영을 맡고 — Igalia·Huawei·자원봉사자가 기여 — 활성 개발 재개.

2026년 현주소:

  • Linux/macOS에서 단순한 페이지·CSS·JS는 렌더링 가능.
  • 자체 미니 브라우저 셸이 데모 가능.
  • 임베디드 사용 사례에 집중 — 자동차 인포테인먼트, 키오스크, 가전제품 UI 등.
  • Tauri의 실험적 백엔드 옵션으로 검토 중.

프로덕션 도달 거리: 데스크톱 일반 사용자용 브라우저로 도달하려면 — 여전히 멀다. 사이트 호환성 작업이 어마어마하다.

2.5 LadyBird — 가장 흥미로운 인디

소유자: LadyBird Browser Initiative (501(c)(3) 비영리, 2024 설립)

자바스크립트 엔진: LibJS (자체)

언어: C++23 (이전엔 SerenityOS의 LibWeb 컴포넌트로 시작)

역사:

  • 2019년 Andreas Kling이 SerenityOS 부속 컴포넌트로 시작.
  • 2022년 독립 프로젝트로 분기.
  • 2024년 LadyBird Browser Initiative 비영리 설립. 초기 자금 GitHub·Shopify 창업자(특히 Chris Wanstrath, Tobi Lütke), 그리고 후속 후원자들로부터 수백만 달러 규모.
  • 풀타임 엔지니어 10명 안팎.

2026년 현주소:

  • 첫 Alpha 출시 목표: 2026년 7월 — Linux/macOS.
  • Web Platform Tests 통과율이 빠르게 상승 중 (2024년 중반 약 80% → 2026년 초 90%+ 일부 영역).
  • HTTPS, HTML5, 대부분 CSS, JavaScript ES2022 수준, 일부 Web API. 멀티프로세스 아키텍처 — 탭마다 ProcessIsolation.
  • WebGPU·WebRTC·미디어 코덱은 아직 미지원 또는 초기 단계.

철학:

  • 독립성 우선 — 광고 수익·VC·검색 거래 받지 않음. 기부와 후원으로만 운영.
  • 밑바닥부터 다시 — 기존 엔진 포크 아님. 100% 새 코드.
  • 표준 준수 — 사용자 트래킹 없음. 사이트 호환성 우선.

프로덕션 도달 거리: Alpha는 "기술적 가능성 증명". 일반 사용자 일일 사용은 — 낙관적으로 봐도 — 2028년 이후. 그러나 30년 만에 처음으로 새 메이저 엔진이 등장하고 있다는 사실 자체가 의미가 크다.

2.6 Flow — 상용 인디

소유자: Ekioh (영국 케임브리지 소재)

언어: C++, 자체 GPU 가속 라이브러리

용도: 임베디드·키오스크·셋톱박스·차량 인포테인먼트 등 — 일반 소비자 브라우저 아님.

특징:

  • 모든 것을 GPU에서 합성 — CPU 부담 최소화.
  • 멀티스레드 레이아웃.
  • 표준 채택은 선택적 — 클라이언트 요구에 맞춰.

왜 흥미로운가: "독립적으로 메이저 사이트 일부를 렌더링 가능한" 두 번째 인디 엔진이라는 점. LadyBird와 함께 — 인디 엔진이 가능하다는 — 살아 있는 증거.

2.7 Goanna — 보존주의자의 깃발

소유자: Moonchild Productions (Pale Moon 개발사)

기원: 2015년 Gecko에서 분기. XUL 확장 같은 — Firefox가 버린 — 기능을 유지하려는 의도.

용도: Pale Moon, Basilisk 브라우저.

현실: 점유율 0.1% 미만. 표준 채택이 매우 느림. 모던 웹사이트의 상당수가 작동하지 않음. 그러나 — 마지막 진정한 의미의 "사용자 통제"를 추구하는 — 작은 커뮤니티가 유지.


3장 · 기능 커버리지 매트릭스

엔진별 기능 지원을 한눈에 보자. O = 안정 지원, △ = 부분/플래그, X = 미지원, − = 적용 불가.

기능Chromium / BlinkWebKit (Safari 26)Gecko (Firefox 130)Servo (2026 nightly)LadyBird (Alpha)
HTML5 코어OOOOO
CSS Grid / FlexboxOOOOO
Container QueriesO (2022)O (2023)O (2023)
View Transitions APIO (2023)△ (2026 Safari 26 부분)△ (2026 Firefox 130 nightly)XX
Anchor PositioningO (2024)XX
CSS NestingOOOO
WebGPUO (2023)O (2026 Safari 26)O (2025 Firefox 121)XX
WebGL 2OOO
WebRTCOOOXX
OffscreenCanvasOO (2024 Safari 17)OX
Web ComponentsOOO
ES Modules in WorkersOOO
WebAssembly SIMDOOO
WebAssembly ThreadsOOOXX
Web CodecsO△ (2026 일부)OXX
Web StreamsOOO
Service WorkerOOOXX
WebAuthn / PasskeysOOOXX
Web Share Level 2OO (iOS)XX
File System Access APIOXXXX

Web Platform Tests 통과율 (대략, 2026년 1분기 기준 — 발표 수치 참조):

엔진WPT 통과율
Blink (Chromium)약 98%
WebKit약 96%
Gecko약 96%
Servo약 78%
LadyBird약 88% (선택 영역)

LadyBird의 WPT 통과율이 빠르게 오르고 있다는 점이 — 작은 팀이 6년 만에 만든 엔진치고는 — 인상적이다.


4장 · 어떤 사이트가 어디서 깨지나 — 실전 호환성

표준 표는 깨끗하지만 현실은 그렇지 않다. 실제로 어떤 사이트가 어떤 엔진에서 깨지는가 — 2026년 5월 기준으로 정리하면.

4.1 Safari/WebKit에서 자주 깨지는 패턴

  • <input type="date"> 인터랙션 차이 — iOS Safari가 네이티브 피커 강제, 데스크톱 Safari는 비표준 UI.
  • 강제 PWA 제약 — Add to Home Screen은 가능하지만 Service Worker 캐시 용량·푸시 알림에서 제약. 2024년 EU 정책 변화 이후에도 흔적 남음.
  • IndexedDB 트랜잭션 타이밍 차이 — Safari의 IDB는 다른 엔진보다 더 자주 — 미묘한 — 락 충돌을 보임.
  • WebRTC ICE candidate 협상에서 가끔 — 특히 모바일 — 비대칭 NAT에서 더 자주 실패.
  • 미디어 코덱 — VP9·AV1 데스크톱은 지원하지만 모바일에서 제한적. H.264·HEVC는 우대.
  • File System Access API 부재 — 데스크톱 앱 수준의 파일 워크플로우 불가.

4.2 Firefox/Gecko에서 자주 깨지는 패턴

  • 일부 광고/추적 차단이 — 의도적으로 — 사이트 자체를 깨뜨림. 사이트가 트래커 의존이면 빈 화면.
  • WebGPU·OffscreenCanvas는 안정화됐지만 — Blink보다 6–12개월 지연 — 그 기간의 사이트가 가끔 깨짐.
  • 모바일 Firefox(Android) 점유율이 작아 사이트가 거의 테스트하지 않음. 종종 — Chromium 전용 CSS를 — 그냥 안 처리.
  • DRM 콘텐츠는 — Widevine을 별도 모듈로 로드 — 일부 환경에서 비활성.

4.3 Chromium에서도 깨질 수 있다

이건 자주 잊힌다. "Chrome이면 무조건 된다"는 거짓말이다.

  • Manifest V3 이후 확장 API 변경으로 일부 확장이 — 특히 컨텐츠 차단·고급 자동화 — 기능 저하.
  • Origin Trials로만 활성화된 기능을 코드가 가정하면 — 트라이얼 만료 후 갑자기 — 깨짐.
  • ChromeOS·Android WebView·Electron 사이의 미묘한 행동 차이.
  • Edge·Brave·Opera 등 파생 브라우저가 — 광고·추적 차단을 — 끼워 넣은 결과 사이트가 깨짐.

4.4 호환성 테스트 매트릭스 (현실판)

작은 팀이 합리적으로 테스트할 수 있는 최소 매트릭스를 정하자면.

우선순위엔진/플랫폼이유
P0Chrome 데스크톱약 50% 트래픽
P0Safari iOS모바일 25–35%
P1Chrome Android모바일 50%+
P1Safari macOS데스크톱 15%
P2Firefox 데스크톱3% 이지만 — 호환성 카나리 — 역할
P3Edge 데스크톱대부분 Chrome과 동일, 기업 환경 한정
P3Samsung Internet한국·중동 모바일 점유
P4Firefox Android정말 여유 있을 때만

Servo·LadyBird는 — 2026년 기준 — 일반 사이트 호환성 테스트 대상이 아니다. 그건 — 엔진 쪽이 사이트에 맞춰야지 — 사이트가 엔진에 맞출 단계가 아니다.


5장 · 정치 — DOJ, DMA, 그리고 Mozilla의 사명 표류

5.1 DOJ vs Google — Chrome 분리가 될까?

2024년 8월, 미국 연방법원이 Google이 검색 시장에서 — 셔먼 법 2조를 위반해 — 독점을 유지했다고 판결했다. 2025년 구제책 단계에서 DOJ는 다음을 권고했다:

  1. Chrome 매각 — Google이 Chrome 브라우저 사업을 분리해 매각.
  2. 검색 거래 금지 — Apple과 — 매년 200억 달러 — 기본 검색 거래 금지.
  3. 데이터 공유 — 검색 인덱스·랭킹 시그널 일부를 경쟁사에 — 일정 조건으로 — 공유.

Google은 항소했고, 2026년 5월 현재 항소법원 단계에서 진행 중이다. 결과는 — 가장 빨라도 2027년 — 나올 가능성이 크다.

만약 Chrome 매각이 강제된다면:

  • Chromium 오픈소스 거버넌스가 흔들린다. Google이 운영비를 댔던 부분을 — 새 주인이 — 어떻게 처리할 것인가?
  • V8·Blink의 발전 속도가 — 단기적으로는 — 느려질 수밖에.
  • Microsoft Edge가 — 이미 Chromium 기반이라 — 영향을 적게 받음. 사실상 — 표준 이전이 Microsoft 쪽으로 — 일부 이동 가능성.
  • 다양성에는 — 역설적으로 — 좋은 신호일 수 있다. 단일 주체의 통제가 약해진다.

5.2 EU DMA — iOS WebKit 강제의 종말?

2024년 3월, EU의 Digital Markets Act (DMA)가 발효되면서 Apple은 — EU 한정으로 — iOS에서 비-WebKit 엔진 브라우저를 허용해야 했다.

2026년 현주소:

  • Chrome iOS의 Blink 기반 버전이 EU 사용자에게 단계적 배포 중. 그러나 — 광고처럼 — 메인 앱이 아니라 별도 SKU로 배포되고, 사용자의 자발적 선택 필요.
  • Firefox iOS의 Gecko 기반 버전은 — 2025년 시범 — 2026년 EU 정식 배포.
  • Apple은 — DMA 규정을 — 가능한 한 빡빡하게 해석. WebKit 시작 화면, JIT 컴파일러 제약, 데이터 보안 모델 차이 등으로 비-WebKit 엔진의 초기 사용 경험이 — 의도적으로 — 거칠다는 비판.
  • EU 밖(미국·아시아·일본 등)은 변화 없음. 미국 의회의 비슷한 법안은 표류 중.

이건 — 적어도 EU 안에서는 — 엔진 다양성의 작은 승리다. 그러나 실제 사용자 점유율 변화는 — 2026년 현재 — 의미 있는 수치까지 도달하지 못했다.

5.3 Mozilla의 사명 표류 논쟁

Mozilla는 — 비-Google·비-Apple 엔진을 유지하는 — 사실상 유일한 메이저 기관이다. 그러나 2020년대 들어 — 다음 패턴이 — 반복되며 비판이 커지는 중이다.

  • 2020년 정리해고 — Servo 팀 포함 대규모 감원.
  • 2022년부터 AI·광고·사생활 도구 신사업 강조 — Mozilla.ai 설립, AI 광고 서비스 Anonym 인수.
  • 2024년 추가 정리해고 (약 60명) — 표준 위원회 참여 일부 축소.
  • 2026년 현재 풀타임 Gecko 엔진 엔지니어 — 2010년대 중반 수백 명에서 — 한 자릿수 후반 / 두 자릿수 초반으로 축소된 것으로 추정.

지지자의 입장: "수입원을 다각화해야 — Google 검색 거래 — 의존을 줄일 수 있다." Mozilla의 수입 80%+는 Google과의 검색 기본 거래에서 나온다. 이 거래가 위 DOJ 판결로 금지될 수 있는 상황에서 — 다각화는 필수.

비판자의 입장: "엔진 투자가 마이너스인데 AI에 투자할 여력이 있는가? 사명이 '인터넷이 모두를 위한 공공자산'인 단체가 광고 회사를 인수하는 게 맞는가?"

이건 — 단순한 옳고 그름이 아니라 — 자원 배분의 어려운 질문이다. 그러나 분명한 건: Gecko 엔진은 — 한 회사 하나에 — 너무 많이 의존하고 있다.


6장 · 왜 다양성이 중요한가 — 단조 경관의 위험

"Chromium이 충분히 잘 한다" — 흔한 반론이다. 표준 채택은 빠르고, 개발자 도구는 좋고, 오픈소스고. 굳이 다른 엔진이 필요한가?

답: 그래도 필요하다. 이유 몇 가지.

6.1 한 회사가 표준을 정의하면 표준이 아니다

W3C·WHATWG 표준 작성에 Blink가 — 사실상 — 거부권을 가진다. Blink가 구현하지 않은 기능은 — 실질적으로 — 표준이 아닌 것과 같다. 반대로 Blink가 시작하면 — 다른 엔진이 — 따라가야 할 압박.

이건 IE 시대의 반복이다. 1990년대 말 IE가 90% 점유율이었을 때 — 마이크로소프트가 — ActiveX·VBScript·HTC 같은 — 사실상 표준이 아닌 — 자체 기술을 표준처럼 밀었다. 결과는 — 웹 전체가 — IE에 묶였고, 다른 브라우저는 — 깨졌다.

지금 Blink가 — 의도적으로 그런다는 게 아니라 — 구조적으로 그 위치에 있다. 그건 — 좋고 나쁨을 떠나 — 위험하다.

6.2 광고·추적 모델 단일화

Manifest V3는 — 합법적 이유가 — 있다. 그러나 결과적으로 광고 차단 확장의 기능을 — 일부 — 저하시켰다. 이건 — Google의 — 주요 수익원이 광고라는 사실과 — 충돌할 수밖에 없다.

Gecko가 — 점유율이 작아도 — 다른 신호를 보낸다. uBlock Origin이 Firefox에서 — Manifest V3가 아닌 — 더 강력한 API로 동작한다. 그게 — 신뢰성 — 면에서는 다양성의 가치다.

6.3 보안 단일 장애점

CVE 하나가 Blink에 있으면 — Chrome·Edge·Brave·Arc·Electron 앱 전부에 영향. 2022년 Chromium의 V8 0-day가 발견됐을 때 — 패치 적용 전 — 사실상 데스크톱의 거의 모든 사용자가 노출.

엔진 다양성은 — 보안 측면에서 — 정확히 — 자연 생태계의 — 종 다양성과 같다. 한 병원체에 모두가 — 동시에 — 쓰러지지 않는다.

6.4 혁신은 경쟁에서

WebKit이 Service Worker를 늦게 받아들였을 때 — Blink와 Gecko가 — 빠르게 구현 — 결국 Apple도 따라옴. Gecko의 WebRender가 — 합성 효율을 — 새로운 수준으로 — Blink가 일부 차용. 경쟁이 없으면 — 누구든 — 정체한다.


7장 · Servo와 LadyBird가 프로덕션까지 가려면

그래서 — 진짜 — 새로운 엔진이 메이저가 될 수 있을까? 두 인디 엔진을 — 정직하게 — 평가하자.

7.1 Servo

남은 일:

  • 사이트 호환성 — 실제 웹의 — 99%를 처리하려면 무수한 엣지 케이스. WPT 통과율이 78%에서 95%까지 — 마지막 — 17%가 가장 어렵다.
  • DOM·CSS·JS 표면적 풀 커버. 일부 API(WebRTC, WebAuthn, Service Worker 등) 미구현.
  • 개발자 도구.
  • 확장 시스템 — 또는 의도적으로 — 안 만들기.
  • 자금. LFE 산하에 있지만 풀타임 엔지니어 수가 한 자릿수.

기회:

  • 임베디드 우선 전략 — 자동차·키오스크·가전이 — 일반 브라우저보다 — 사이트 호환성 요구가 낮다.
  • Rust 생태계의 다른 컴포넌트와 결합 — Tauri·다른 임베디드 프레임워크.

현실적 일정: 데스크톱 일반 브라우저 = 5+년. 임베디드 일부 채택 = 2027–2028.

7.2 LadyBird

남은 일:

  • Alpha를 출시(2026년 7월 목표). 그 후 사이트 호환성·성능·안정성 — 모두 — 빠르게 — 끌어올려야 한다.
  • WebGPU·WebRTC·미디어 코덱 — 인디 팀이 직접 만들기엔 — 어마어마한 — 작업량. 라이브러리 재사용 전략 — Skia·FFmpeg 등 — 검토 중.
  • Windows·Android 포팅. iOS는 — 적어도 — 정책상 어려움.
  • 자금 지속성. 2024년 시드 자금이 — 몇 년 — 운영을 보장하지만 그 이후?

기회:

  • 진정한 의미의 독립. 광고·검색 거래·VC 압력 없음. 오로지 — 사용자 경험 — 기준으로 결정.
  • 30년 만의 첫 진정한 새 엔진이라는 — 상징성·홍보 — 효과.
  • LadyBird 코드베이스가 — 의도적으로 — 깨끗. 기여 진입 장벽 낮음.

현실적 일정: Alpha = 2026 7월. Beta(일반 사용 가능, 알려진 한계 있음) = 2027–2028. 일반 사용자 일일 사용 = 2028–2030.

7.3 둘 다 — 실패한다 해도

설령 둘 다 — 메이저 — 점유율에 도달하지 못해도 — 의미가 크다. 이유.

  • 표준 위원회에 새로운 목소리 — 인디 엔진 한 명이 있다는 사실만으로도 — 논의가 — 더 신중해진다.
  • Chromium에 압력 — Chrome이 — 단조 경관의 유일한 — 옵션이 아니라는 — 사회적 인식.
  • 다음 세대를 위한 학교 — Servo의 Rust·LadyBird의 C++23로 새 엔지니어가 길러진다.
  • 임베디드·특수 환경의 대안 — 차량·키오스크·임베디드는 — 라이선스·제어권 — 면에서 인디 엔진이 매력적.

8장 · 실무자 — 무엇을 해야 하나

이 글을 읽는 당신이 — 웹 개발자라면 — 무엇을 — 다르게 해야 할까?

8.1 다중 엔진 테스트를 — CI에 — 포함

GitHub Actions나 다른 CI에서 — Playwright가 Chromium·WebKit·Firefox를 — 모두 자동 실행한다. 무료다. 핑계가 없다.

# .github/workflows/test.yml (예시 — 코드 블록 안에서만)
name: cross-browser-tests
on: [push, pull_request]
jobs:
  test:
    strategy:
      matrix:
        browser: [chromium, webkit, firefox]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install ${{ matrix.browser }} --with-deps
      - run: npx playwright test --project=${{ matrix.browser }}

8.2 기능 사용은 — Baseline 기준으로

web.dev/baseline 또는 caniuse — 어떤 기능이 — 세 엔진 모두에서 — 안정 채택됐는지 — 확인.

Baseline 2024+에 들어간 기능은 — 안전하게 — 사용. Baseline 미만은 — 폴리필 / 프로그레시브 인핸스먼트 — 또는 사용 보류.

8.3 Origin Trials는 — 차분히

Chromium의 Origin Trials는 — 코드를 — 새 기능에 의존하게 만든다. 트라이얼이 만료되면 — 그 기능을 사용하던 모든 사이트가 — 갑자기 — 깨진다. 가능하면 — 안 쓰거나 — 폴리필을 — 강제.

8.4 사용자 점유율이 작은 엔진도 — 무시하지 말 것

Firefox가 3%라고 — 무시하면 — 일부 사용자가 — 일부 기능 — 사용할 수 없다. 작은 노력으로 — 큰 차이.

8.5 표준 — 우선

벤더 프리픽스 (-webkit-, -moz-) 사용 시 — 표준 버전을 항상 — 함께 쓰기. 사이트가 — 한 엔진에 — 묶이는 — 패턴을 — 피하기.


에필로그 — 30년 만의 분기점

웹 엔진의 역사를 — 압축해 보면 — 분기점은 — 드물게 — 온다. 1994년 Netscape, 2003년 WebKit, 2008년 Chrome, 2013년 Blink — 그리고 2026년 — 어떤 식으로든 — 다음 페이지가 — 열리고 있다.

LadyBird의 Alpha, Servo의 부활, DOJ의 Chrome 매각 권고, EU DMA의 iOS 엔진 강제 해제, Mozilla의 사명 표류 — 어느 하나도 — 즉시 — 결과를 — 만들지는 않는다. 그러나 — 누적되면 — 2030년대의 웹은 — 2020년대와는 — 다르게 — 그려질 수 있다.

체크리스트

  • 우리 사이트는 Chrome·Safari·Firefox에서 — 회귀 없이 — 동작하는가?
  • Playwright 또는 동등한 도구로 — 세 엔진 — CI 자동 테스트를 — 운영하는가?
  • Baseline 미만의 기능은 — 폴리필 또는 — 프로그레시브 인핸스먼트로 — 감싸는가?
  • 벤더 프리픽스 옆에 — 표준 — 버전을 — 함께 — 작성하는가?
  • Origin Trials에 — 코드가 — 의존하지 않는가?
  • 사이트의 — 핵심 기능이 — JS 없이도 — 동작하는가?

안티패턴

  • "Chrome에서만 테스트한다" — 다른 엔진에서 — 알게 모르게 — 깨지고 있을 가능성.
  • "user-agent로 분기 처리" — 거의 항상 — 미래에 — 깨진다.
  • "Service Worker가 있다고 가정" — Safari/iOS의 — 미묘한 — 차이 무시.
  • "내 사용자 통계상 Firefox는 작으니 — 무시" — Firefox는 — 호환성 — 카나리.
  • "Manifest V3 확장이 — Manifest V2와 동일하다" — 거짓.

다음 글 예고

다음 글에서는 — 이 엔진들을 — 임베드해 데스크톱 앱을 만드는 — Electron·Tauri·WebView 비교를 — 깊이 파고들 예정. Chromium을 통째로 번들할 것인가 (Electron), OS WebView를 빌려 쓸 것인가 (Tauri), 새 길을 갈 것인가 (WebView2 / WKWebView 직접) — 그리고 — 각각의 — 보안·메모리·번들 크기 트레이드오프.


참고 / References

Browser Engines 2026 — Chromium, Gecko, WebKit, Servo, LadyBird: Who Is Actually Rendering the Web

Prologue — Three engines paint the web

Behind the screen you are reading right now sits a rendering engine: hundreds of thousands of lines of C++ that parse HTML into a DOM, match CSS to produce a style tree, fold both into box and layer and paint trees, and finally hand textures to the GPU. We use this stack every day. We almost never look at it.

As of May 2026, across desktop, mobile, and tablet combined, three engines account for essentially all of the web's rendering:

  • Blink (Chromium family) — about 81%. Chrome, Edge, Brave, Arc, Opera, Vivaldi, Samsung Internet, and almost every desktop app shipped on Electron.
  • WebKit (Apple) — about 14%. Safari, and — at least outside the EU — every browser on iOS, because the App Store mandates WebKit (Chrome iOS, Firefox iOS, Edge iOS are all WebKit wrappers).
  • Gecko (Mozilla) — about 3%. Firefox and its derivatives. The last major engine that is genuinely neither Chromium nor Apple.

That is the entire picture. The three of them together carry 99%. The remaining 1% is split between Pale Moon's Goanna, Ekioh's GPU-accelerated commercial engine Flow, and — most interestingly — two ground-up rewrites: Servo (Mozilla's Rust engine) and LadyBird (Andreas Kling's independent C++ engine).

This post maps those three engines and the two indies trying to crack the picture in 2026. And it asks:

Can we really survive on one engine owning more than 80% of the web? Are three engines enough diversity? And — can Servo or LadyBird actually reach production?


1. How we ended up with three engines — thirty years compressed

The history of browser engines is short and dense. Compressed:

1.1 1993–2003: Mosaic, Netscape, IE, KHTML

  • Mosaic (1993) — the first graphical browser. NCSA, then forked off into Netscape.
  • Netscape Navigator (1994) — built by Mosaic veterans, with a proprietary engine. Open-sourced in 1998 — the seed of the Mozilla project, and from there, Gecko.
  • Internet Explorer (1995–) — Microsoft licensed Mosaic, built the Trident engine. By the late 1990s IE held more than 90% of the market and effectively defined the web.
  • KHTML (1998) — KDE's Konqueror browser engine. A clean, small C++ codebase. Apple forked it in 2003 to create WebKit.

1.2 2003–2013: WebKit appears, Chrome changes everything

  • WebKit (2003) — Apple forks KHTML, ships with Safari 1.0.
  • Chrome (2008) — Google forks WebKit, pairs it with the V8 JavaScript engine, and introduces the multi-process architecture that defines modern browsers.
  • Blink (2013) — Google diverges from WebKit into its own engine. Opera abandons its Presto engine and adopts Blink the same year.

1.3 2013–2020: The acceleration of monoculture

  • Microsoft Edge (2015) — IE retired, replaced by EdgeHTML. The new engine never gains share.
  • Edge — Chromium (2020) — Microsoft drops EdgeHTML and rebases Edge on Chromium. At this moment, the desktop engine count collapses to three.
  • Servo (2012–2020) — Mozilla's parallel Rust engine. Dormant after the 2020 Mozilla layoffs.

1.4 2020–2026: Revival and cracks

  • Servo (2023) — Moved to Linux Foundation Europe (LFE), development restarts. By 2026 Servo demos an embedded use case and a minimal browser shell.
  • LadyBird (2022–) — Andreas Kling (ex-Apple WebKit, founder of SerenityOS) spins out LadyBird as an independent project. The non-profit LadyBird Browser Initiative is incorporated in 2024. Funded by GitHub/Shopify founders (notably Chris Wanstrath and Tobi Lutke). Roughly ten full-time engineers. First Alpha targeting July 2026 for Linux and macOS. Windows and Android come later.
  • EU DMA lifts iOS WebKit mandate (2024) — In the EU only, Apple must allow non-WebKit engines on iOS. Chrome iOS ships a Blink variant in pilot. Real usage moves slowly, but one of the pillars has wobbled.
  • DOJ vs Google ruling (August 2024) — A US federal court rules Google illegally maintains a monopoly in search. The 2025 remedies phase sees the DOJ recommend divesting Chrome. As of mid-2026, the appeal is still in progress. If forced, the browser landscape shifts again.

The point of this chapter: the three-engine state is not equilibrium. It is the residue of accumulated mergers. Four to five engines existed in the late 1990s. The mid-2010s compressed them into three. The mid-2020s have begun to diverge again — slowly, but visibly.


2. Engine-by-engine anatomy

Owner: Google (BSD-style open source, but a single company effectively drives direction)

JS engine: V8

Render pipeline: Blink — cc (compositor) — Viz (GPU process) — Skia / Dawn

Browsers:

  • Chrome (Google)
  • Edge (Microsoft, switched in 2020)
  • Brave (privacy focus)
  • Arc / Arc Search (The Browser Company)
  • Opera (switched 2013)
  • Vivaldi
  • Samsung Internet
  • Yandex Browser
  • Naver Whale
  • Dozens of minor forks
  • Electron-based desktop apps (VS Code, Slack, Discord, Notion, Figma desktop, etc.)
  • Some Tauri configurations (Tauri defaults to OS WebView, but a Bundled Chromium option exists)

Strengths:

  • Fastest standards adoption. Container Queries, View Transitions, Anchor Positioning all shipped first.
  • Industry-standard developer tools.
  • Broadest WebGPU, WebRTC, and media codec support.

Weaknesses:

  • One company effectively defines de facto standards. "Blink supports it" is treated as equivalent to "it is a standard."
  • High memory footprint — hundreds of megabytes per tab.
  • Manifest V3 has degraded extension capabilities, especially for content blocking — uncomfortable given Google's ad business.

Governance: Open in form, but commits are almost entirely from Google. Microsoft contributes around Windows and accessibility since adopting Edge. Igalia, a Spanish consultancy, is the most significant external contributor — Container Queries, MathML, and other features.

2.2 WebKit — Apple's walled garden

Owner: Apple (mixed LGPL / BSD)

JS engine: JavaScriptCore (JSC)

Render pipeline: WebCore — WebKit2 (multi-process) — Metal / CoreAnimation

Browsers / platforms:

  • Safari (macOS, iOS, iPadOS, visionOS)
  • Effectively all iOS browsers — App Store policy enforces WebKit (Chrome iOS, Firefox iOS, Edge iOS, Brave iOS are all WebKit wrappers)
  • Since 2024 EU DMA, EU-only iOS allows non-WebKit, gradual adoption
  • macOS SwiftUI WebView and AppKit WKWebView
  • PlayStation 5 system browser
  • Amazon Kindle, BlackBerry, Tizen, and other embedded platforms

Strengths:

  • Excellent GPU and media integration on macOS / iOS (Metal backend).
  • Energy efficiency — leader in battery-aware design for laptops and phones.
  • Privacy — Intelligent Tracking Prevention (ITP) pioneered modern anti-tracking.

Weaknesses:

  • Slow standards adoption for many features. WebGPU, WebRTC, OffscreenCanvas, Service Worker all arrived one to two years after Blink and Gecko.
  • iOS WebKit enforcement — outside the EU — denies users genuine engine choice.
  • Developer tools are weaker than Blink and Gecko.

Governance: Almost all commits from Apple. Igalia maintains WPE WebKit, the embedded variant. Sony contributes around the PS5 browser.

2.3 Gecko — the last non-Chromium flag

Owner: Mozilla Foundation / Mozilla Corporation (MPL 2.0)

JS engine: SpiderMonkey

Render pipeline: Gecko — WebRender (Rust-based GPU compositor) — Direct3D / Metal / OpenGL

Browsers:

  • Firefox (desktop, Android)
  • Firefox ESR
  • LibreWolf (privacy-hardened fork)
  • Waterfox (legacy extension compatibility)
  • Tor Browser (built on Firefox ESR)

Strengths:

  • The strongest default privacy posture. Tracking protection and fingerprint resistance ship as defaults.
  • WebRender — a Rust-rewritten GPU compositor, very efficient at the composition stage.
  • A genuine counterweight in standards committees, however small.

Weaknesses:

  • Resources are thin. Mozilla went through major layoffs in 2020 and again in 2024. As of 2026, the full-time Gecko engine engineer count is somewhere in the high single digits to low double digits.
  • Standards adoption often lags Blink by six to twelve months. WebGPU only stabilized in late 2025.
  • Tiny mobile share — low single digits on Android, effectively zero on iOS where it is a WebKit wrapper.

Governance: Mozilla-led. External contributions exist but are small in share. From 2024 onward, the diversification of Mozilla into advertising, AI, and other businesses has fueled the "Mozilla mission drift" debate — is Gecko investment actually decreasing?

2.4 Servo — the Rust rewrite

Owner: Linux Foundation Europe (since 2023)

JS engine: SpiderMonkey (borrowed from Gecko)

Render pipeline: Pure Rust. Parallel layout, parallel paint — multi-core utilization is the design center.

History:

  • Started in 2012 at Mozilla Research. Parts of Servo (the style system, WebRender) were upstreamed into Gecko.
  • Went dormant in the 2020 Mozilla layoffs.
  • LFE took over operations in 2023. Igalia, Huawei, and volunteers contribute. Active development has resumed.

Status in 2026:

  • Renders simple pages, CSS, and JS on Linux and macOS.
  • A demo browser shell is shippable.
  • Focus on embedded use cases — automotive infotainment, kiosks, appliance UIs.
  • Under review as an experimental backend for Tauri.

Distance to production: For a general-purpose desktop browser, the gap is still enormous. Site compatibility is the hard part.

2.5 LadyBird — the most exciting indie

Owner: LadyBird Browser Initiative (501(c)(3) non-profit, founded 2024)

JS engine: LibJS (custom)

Language: C++23 (originated as the SerenityOS LibWeb component)

History:

  • Began in 2019 as a SerenityOS subcomponent built by Andreas Kling.
  • Split into an independent project in 2022.
  • The LadyBird Browser Initiative non-profit was created in 2024. Initial funding from GitHub and Shopify founders (Chris Wanstrath, Tobi Lutke) plus follow-on donors. Multi-million-dollar runway.
  • Around ten full-time engineers.

Status in 2026:

  • First Alpha targeting July 2026 — Linux and macOS.
  • Web Platform Tests pass rate has risen quickly (roughly 80% in mid-2024 — 90% or higher in selected areas by early 2026).
  • HTTPS, HTML5, most CSS, JavaScript at the ES2022 level, plus some Web APIs. Multi-process architecture with per-tab process isolation.
  • WebGPU, WebRTC, and media codecs are not yet usable or are very early.

Philosophy:

  • Independence first — no ad revenue, VC, or search deals. Donations and grants only.
  • Built from scratch — not a fork.
  • Standards-pure — no user tracking. Site compatibility is a stated priority.

Distance to production: The Alpha proves technical feasibility. Daily use for general users is, optimistically, 2028 or later. But for the first time in roughly 30 years there is a genuinely new major browser engine in active development. That fact alone matters.

2.6 Flow — commercial indie

Owner: Ekioh (Cambridge, UK)

Language: C++, custom GPU-acceleration library

Use case: Embedded — kiosks, set-top boxes, automotive infotainment. Not a consumer browser.

Distinctives:

  • Everything composited on GPU — minimal CPU overhead.
  • Multi-threaded layout.
  • Standards adoption is selective based on customer requirements.

Flow matters because it is a second indie engine that already renders parts of major sites. Together with LadyBird, it is living proof that independent engines remain feasible.

2.7 Goanna — the preservationist flag

Owner: Moonchild Productions (Pale Moon)

Origin: Forked from Gecko in 2015, to preserve XUL extensions and other capabilities Firefox dropped.

Use case: Pale Moon, Basilisk.

Reality: Share below 0.1%. Standards adoption is slow. Modern sites often break. But it preserves a small community focused on user control.


3. Feature coverage matrix

A snapshot of feature support by engine. O = stable, ~ = partial or behind a flag, X = not supported, - = not applicable.

FeatureChromium / BlinkWebKit (Safari 26)Gecko (Firefox 130)Servo (2026 nightly)LadyBird (Alpha)
HTML5 coreOOOOO
CSS Grid / FlexboxOOOOO
Container QueriesO (2022)O (2023)O (2023)~~
View Transitions APIO (2023)~ (Safari 26 partial)~ (Firefox 130 nightly)XX
Anchor PositioningO (2024)~~XX
CSS NestingOOO~O
WebGPUO (2023)O (Safari 26, 2026)O (Firefox 121, 2025)XX
WebGL 2OOO~~
WebRTCOOOXX
OffscreenCanvasOO (Safari 17, 2024)O~X
Web ComponentsOOO~~
ES Modules in WorkersOOO~~
WebAssembly SIMDOOO~~
WebAssembly ThreadsOOOXX
Web CodecsO~ (partial, 2026)OXX
Web StreamsOOO~~
Service WorkerOOOXX
WebAuthn / PasskeysOOOXX
Web Share Level 2OO (iOS)~XX
File System AccessOXXXX

Approximate Web Platform Tests pass rates in early 2026:

EngineWPT pass rate
Blink (Chromium)about 98%
WebKitabout 96%
Geckoabout 96%
Servoabout 78%
LadyBirdabout 88% (selected areas)

LadyBird climbing this quickly is remarkable for a team this small over six years.


4. Where sites actually break — real compatibility today

Tables stay clean. Reality does not. Here is what tends to break, by engine, as of May 2026.

4.1 Safari / WebKit patterns

  • <input type="date"> interaction differences — iOS Safari forces the native picker, desktop Safari uses a non-standard UI.
  • PWA constraints — Add to Home Screen works, but Service Worker storage and push notification capabilities lag, even after 2024 EU policy changes.
  • IndexedDB transaction timing — Safari's IDB hits subtle lock conflicts more often than other engines.
  • WebRTC ICE candidate negotiation occasionally fails on asymmetric NAT, especially on mobile.
  • Media codecs — VP9 and AV1 work on desktop, are limited on mobile. H.264 and HEVC get priority.
  • No File System Access API — desktop-class file workflows are not possible.

4.2 Firefox / Gecko patterns

  • Aggressive tracking protection — by design — breaks sites that depend on trackers. Blank screens are not unusual.
  • WebGPU and OffscreenCanvas are stable now but arrived six to twelve months after Blink. Sites from that window sometimes break.
  • Tiny mobile share means sites barely test on Firefox Android. Chromium-only CSS features just go unhandled.
  • DRM content uses Widevine as a separately loaded module — sometimes disabled in hardened configurations.

4.3 Chromium can break too

This gets forgotten. "Chrome" does not mean "guaranteed."

  • Manifest V3 has degraded extensions, especially advanced content blocking and automation tooling.
  • Origin Trials — code that assumes a trial-only feature will silently break once the trial expires.
  • Subtle behavior differences between ChromeOS, Android WebView, and Electron.
  • Edge, Brave, Opera, and other derivatives bundle ad and tracker blocking that can break sites in ways the upstream Chrome team did not.

4.4 A realistic cross-engine test matrix

For small teams. The minimum sensible matrix:

PriorityEngine / platformWhy
P0Chrome desktopAbout 50% of traffic
P0Safari iOS25 to 35% of mobile
P1Chrome Android50% or more of mobile
P1Safari macOSAbout 15% of desktop
P2Firefox desktop3%, but the canary for cross-engine compat
P3Edge desktopMostly Chromium-equivalent; enterprise only
P3Samsung InternetKorea, Middle East mobile share
P4Firefox AndroidOnly when you have slack capacity

Servo and LadyBird, as of 2026, are not part of mainstream site testing. At this stage the engines should accommodate sites, not the other way around.


5. Politics — DOJ, DMA, and Mozilla's drift

5.1 DOJ vs Google — will Chrome get split?

In August 2024 a US federal court ruled that Google illegally maintains a monopoly in search under Sherman Act Section 2. In the 2025 remedies phase the DOJ recommended:

  1. Divest Chrome — Google sells off the Chrome browser business.
  2. Ban search defaults deals — prohibit the roughly USD 20 billion-per-year Apple default search deal.
  3. Data sharing — open parts of the search index and ranking signals to competitors under conditions.

Google appealed. As of May 2026 the case sits in the appeals court. A final outcome is unlikely before 2027.

If a Chrome divestiture is forced:

  • Chromium open-source governance becomes uncertain. Who pays the operating costs Google was funding?
  • V8 and Blink development would slow in the short term.
  • Microsoft Edge is already Chromium-based and is less affected. Effective influence over the platform partly shifts to Microsoft.
  • For diversity, it is paradoxically a positive signal. A single actor's control loosens.

5.2 EU DMA — the end of iOS WebKit enforcement?

The EU Digital Markets Act (DMA) took effect in March 2024. In the EU only, Apple must permit non-WebKit engines on iOS.

As of 2026:

  • Chrome iOS with a Blink-based variant is rolling out to EU users — not as the main app, but as a separate SKU users must actively opt into.
  • Firefox iOS with Gecko piloted in 2025 and went into wider EU rollout in 2026.
  • Apple has interpreted the DMA narrowly — JIT restrictions, a separate security model, and additional warnings ensure the first-run experience of non-WebKit engines is intentionally rough, critics say.
  • Outside the EU (United States, Asia, Japan, etc.), nothing changes. Similar US legislation has stalled.

For engine diversity inside the EU, this is a small win. But meaningful share shifts have not happened yet.

5.3 The Mozilla mission drift debate

Mozilla is effectively the only major institution preserving a non-Google, non-Apple engine. But the 2020s pattern has fueled growing criticism:

  • 2020 layoffs — large cuts, including most of the Servo team.
  • 2022 onward — emphasis on AI, advertising, and privacy products. Mozilla.ai founded. The advertising company Anonym acquired in 2024.
  • 2024 additional layoffs — around 60 people, including some standards-committee participation.
  • 2026 — full-time Gecko engineers are estimated at high single digits to low double digits, down from hundreds in the mid-2010s.

The case for: "Revenue diversification is essential. We cannot keep depending on the Google search deal." More than 80% of Mozilla's revenue comes from that deal. If the DOJ remedies forbid it, diversification is survival.

The case against: "Investment in the engine is going negative, but Mozilla is funding advertising and AI? Is it appropriate for an organization with a public-interest mission to acquire an ad company?"

There is no clean right answer. Resource allocation is hard. What is clear: Gecko is too dependent on one organization.


6. Why diversity matters — the monoculture risk

"Chromium does well enough" is a common counterargument. Standards adoption is fast, the dev tools are great, and it is open source. Do we really need other engines?

We do. A few reasons.

6.1 If one company defines a standard, it is not a standard

W3C and WHATWG standards are effectively vetoed by Blink. A feature Blink does not implement is, practically, not a standard. A feature Blink starts puts pressure on other engines to follow.

This is the IE era repeating. In the late 1990s, with IE at 90% share, Microsoft pushed ActiveX, VBScript, and HTC as quasi-standards. The web got locked to IE. Other browsers broke.

Blink is not doing this intentionally. It is structurally in that position. Good or bad, that is dangerous.

6.2 Ad and tracking model monoculture

Manifest V3 has legitimate justifications. It also reduced ad-blocker capabilities. That conflicts with the fact that Google's core revenue is advertising.

Gecko sends a different signal even at small share. uBlock Origin runs on Firefox with stronger APIs than under Manifest V3. That is the value of diversity in trust.

6.3 Security single point of failure

A CVE in Blink affects Chrome, Edge, Brave, Arc, and the entire Electron app ecosystem at once. When a V8 zero-day was found in 2022, essentially every desktop user was exposed until patches rolled out.

Engine diversity, in security, is exactly like species diversity in an ecosystem. One pathogen should not knock everyone over at once.

6.4 Competition drives innovation

When WebKit was slow on Service Worker, Blink and Gecko pushed it forward and eventually Apple followed. Gecko's WebRender pushed composition efficiency to a new level and Blink borrowed parts. Without competition, everybody stalls.


7. What it would take to get Servo and LadyBird to production

So can a genuinely new engine become major? Let us be honest.

7.1 Servo

What is left:

  • Site compatibility. Reaching 99% of real-world sites means handling endless edge cases. WPT pass rate from 78% to 95% — the final 17% is the hardest.
  • Full DOM, CSS, and JS API surface. WebRTC, WebAuthn, Service Worker not yet implemented.
  • Developer tools.
  • An extension system — or a deliberate decision not to have one.
  • Funding. LFE provides governance, but full-time engineer count is single digits.

Opportunities:

  • Embedded-first strategy. Automotive, kiosks, and appliances tolerate looser site-compatibility requirements.
  • Integration with the rest of the Rust ecosystem — Tauri and other frameworks.

Realistic timeline: A general-purpose desktop browser is 5+ years out. Embedded adoption: 2027 to 2028.

7.2 LadyBird

What is left:

  • Ship the Alpha (target July 2026). Then crank site compatibility, performance, and stability quickly.
  • WebGPU, WebRTC, media codecs — enormous bodies of work for a small indie team. Strategies include reusing Skia, FFmpeg, and similar libraries.
  • Port to Windows and Android. iOS is hard on policy grounds alone.
  • Funding longevity. The 2024 seed funding buys years. After that, what?

Opportunities:

  • True independence. No ad pressure, no search deals, no VC pressure. Decisions are based on user experience.
  • The narrative power of the first real new engine in 30 years.
  • A deliberately clean codebase that lowers the bar for new contributors.

Realistic timeline: Alpha in July 2026. Beta (usable with known limitations) in 2027 to 2028. Daily use for general users: 2028 to 2030.

7.3 Even if both fail

Even if neither reaches major share, the work matters. Reasons:

  • New voices in standards committees — one indie engine present makes deliberations more careful.
  • Pressure on Chromium — a social signal that Chrome is not the only option in the monoculture.
  • A school for the next generation — Servo's Rust and LadyBird's C++23 train new engine engineers.
  • Embedded and special-purpose alternatives — automotive, kiosks, and embedded prefer indie engines for license and control reasons.

8. What practitioners should actually do

If you are reading this as a web developer, what changes?

8.1 Multi-engine testing in CI

GitHub Actions and equivalents run Playwright across Chromium, WebKit, and Firefox automatically. It is free. There is no excuse.

# .github/workflows/test.yml (example, inside code block only)
name: cross-browser-tests
on: [push, pull_request]
jobs:
  test:
    strategy:
      matrix:
        browser: [chromium, webkit, firefox]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install ${{ matrix.browser }} --with-deps
      - run: npx playwright test --project=${{ matrix.browser }}

8.2 Use features at Baseline, not at the bleeding edge

web.dev/baseline or caniuse will tell you whether a feature is stable across all three engines. Anything in Baseline 2024 or later is safe to use. Anything below it needs a polyfill or a progressive enhancement path.

8.3 Be careful with Origin Trials

Chromium's Origin Trials encourage code to depend on new features. When the trial expires, every site that depended on it breaks suddenly. Avoid if possible, or always polyfill.

8.4 Do not ignore engines with small share

Firefox at 3% is still real users. Small effort gives a meaningful return.

8.5 Standards first

When you use vendor prefixes (-webkit-, -moz-), always include the standard form alongside. Avoid patterns that lock the site to a single engine.


Epilogue — A 30-year inflection

If you compress the history of browser engines, true inflection points are rare. Netscape in 1994, WebKit in 2003, Chrome in 2008, Blink in 2013 — and 2026 may be the next.

LadyBird's Alpha, Servo's revival, the DOJ's recommendation to divest Chrome, the EU DMA prying open iOS, Mozilla's mission drift — none of these create an immediate result on their own. But stacked together, the web of the 2030s could look meaningfully different from the web of the 2020s.

Checklist

  • Does our site run without regressions on Chrome, Safari, and Firefox?
  • Do we run cross-engine CI tests with Playwright or an equivalent tool?
  • Are sub-Baseline features wrapped in polyfills or progressive enhancement?
  • When we use vendor prefixes, do we always include the standard form?
  • Are we free of hard dependencies on Origin Trials?
  • Does our site's core functionality work without JavaScript?

Anti-patterns

  • "Test only on Chrome" — other engines are quietly breaking.
  • "User-Agent sniffing" — almost always breaks in the future.
  • "Assume Service Worker support everywhere" — Safari and iOS quirks.
  • "Firefox share is small, so ignore" — Firefox is the compatibility canary.
  • "Manifest V3 extensions equal Manifest V2 extensions" — they do not.

Next post

The next post will dig into embedding these engines into desktop apps — Electron vs Tauri vs WebView. Bundle the entire Chromium (Electron)? Borrow the OS WebView (Tauri)? Drive WebView2 or WKWebView yourself? With the security, memory, and bundle-size tradeoffs of each.


References