With Microsoft's decision to end development of its own Web rendering engine and switch to Chromium, control over the Web has functionally been ceded to Google. That's a worrying turn of events, given the company's past behavior.
Chrome itself has about 72 percent of the desktop-browser market share. Edge has about 4 percent. Opera, based on Chromium, has another 2 percent. The abandoned, no-longer-updated Internet Explorer has 5 percent, and Safari—only available on macOS—about 5 percent. When Microsoft's transition is complete, we're looking at a world where Chrome and Chrome-derivatives take about 80 percent of the market, with only Firefox, at 9 percent, actively maintained and available cross-platform.
The mobile story has stronger representation from Safari, thanks to the iPhone, but overall tells a similar story. Chrome has 53 percent directly, plus another 6 percent from Samsung Internet, another 5 percent from Opera, and another 2 percent from Android browser. Safari has about 22 percent, with the Chinese UC Browser sitting at about 9 percent. That's two-thirds of the mobile market going to Chrome and Chrome derivatives.
In terms of raw percentages, Google won't have quite as big a lock on the browser space as Microsoft did with Internet Explorer—Internet Explorer 6 peaked at around 80 percent, and all versions of Internet Explorer together may have reached as high as 95 percent. But Google's reach is, in practice, much greater: not only is the Web a substantially more important place today than it was in the early 2000s, but also there's a whole new mobile Web that operates in addition to the desktop Web.
Embrace and extend, Mountain View style
Google is already a company that exercises considerable influence over the direction of the Web's development. By owning both the most popular browser, Chrome, and some of the most-visited sites on the Web (in particular the namesake search engine, YouTube, and Gmail), Google has on a number of occasions used its might to deploy proprietary tech and put the rest of the industry in the position of having to catch up.
Back in 2009, Google introduced SPDY, a proprietary replacement for HTTP that addressed what Google saw as certain performance issues with existing HTTP/1.1. Google wasn't exactly wrong in its assessments, but SPDY was something of a unilateral act, with Google responsible for the design and functionality. SPDY was adopted by other browsers and Web servers over the next few years, and Google's protocol became widespread.
SPDY was subsequently used as the basis for HTTP/2, a major revision to the HTTP protocol developed by the Internet Engineering Task Force (IETF), the consortium that develops Internet protocols with members from across the industry. While SPDY did initiate the HTTP/2 work, the protocol finally delivered in 2015 was extensively modified from Google's initial offering.
The same story is repeating with HTTP/3. In 2012, Google announced a new experimental protocol, QUIC, intended again to address performance issues with existing HTTP/1.1 and HTTP/2. Google deployed QUIC, and Chrome would use QUIC when communicating with Google properties. Again, QUIC became the basis for IETF's HTTP development, and HTTP/3 uses a derivative of QUIC that's modified from and incompatible with Google's initial work.
It's not just HTTP that Google has repeatedly worked to replace. Google AMP ("Accelerated Mobile Pages") is a cut-down HTML combined with Google-supplied JavaScript designed to make mobile Web content load faster. This year, Google said that it would try to build AMP with Web standards and introduced a new governance model that gave the project much wider industry oversight.
Bad actor?
This is a company that, time and again, has tried to push the Web into a Google-controlled proprietary direction to improve the performance of Google's online services when used in conjunction with Google's browser, consolidating Google's market positioning and putting everyone else at a disadvantage. Each time, pushback has come from the wider community, and so far, at least, the result has been industry standards that wrest control from Google's hands. This action might already provoke doubts about the wisdom of handing effective control of the Web's direction to Google, but at least a case could be made that, in the end, the right thing was done.
But other situations have had less satisfactory resolutions. YouTube has been a particular source of problems. Google controls a large fraction of the Web's streaming video, and the company has, on a number of occasions, made changes to YouTube that make it worse in Edge and/or Firefox. Sometimes these changes have improved the site experience in Chrome, but even that isn't always the case.
A person claiming to be a former Edge developer has today described one such action. For no obvious reason, Google changed YouTube to add a hidden, empty HTML element that overlaid each video. This element disabled Edge's fastest, most efficient hardware accelerated video decoding. It hurt Edge's battery-life performance and took it below Chrome's. The change didn't improve Chrome's performance and didn't appear to serve any real purpose; it just hurt Edge, allowing Google to claim that Chrome's battery life was actually superior to Edge's. Microsoft asked Google if the company could remove the element, to no avail.
The latest version of Edge addresses the YouTube issue and reinstated Edge's performance. But when the company talks of having to do extra work to ensure EdgeHTML is compatible with the Web, this is the kind of thing that Microsoft has been forced to do.
As another example, YouTube uses a feature called HTML imports to load scripts. HTML imports haven't been widely adopted, either by developers or browsers alike, and ECMAScript modules are expected to serve the same role. But they're available in Chrome and used by YouTube. For Firefox and Edge, YouTube sends a JavaScript implementation of HTML imports which carries significant performance overheads. The result? YouTube pages that load in a second in Chrome take many seconds to load in other browsers.
These actions may not be deliberate on the part of Google—it's possible that the company simply doesn't care about other browsers, rather than actively trying to hinder them. But even an attitude of "Google first, who cares about the rest?" is not the kind of thing that we should want from a company trusted with so much control over the Web.
The strong get stronger; the weak get weaker
Microsoft's decision both gives Google an ever-larger slice of the pie and weakens Microsoft's position as an opposing voice. Even with Edge and Internet Explorer having a diminished share of the market, Microsoft has retained some sway; its IIS Web server commands a significant Web presence, and there's still value in having new protocols built in to Windows, as it increases their accessibility to software developers.
But now, Microsoft is committed to shipping and supporting whatever proprietary tech Google wants to develop, whether Microsoft likes it or not. Microsoft has been very explicit that its adoption of Chromium is to ensure maximal Chrome compatibility, and the company says that it is developing new engineering processes to ensure that it can rapidly integrate, test, and distribute any changes from upstream—it doesn't ever want to be in the position of substantially lagging behind Google's browser.
But this commitment ties Microsoft's hands: it means that the company can't ever meaningfully fork Chromium and diverge from its development path, because doing so will jeopardize that compatibility and increase the cost and complexity of incorporating Google's changes. This means that, even if Google takes Chromium in a direction that Microsoft disagrees with or opposes, Microsoft will have little option but to follow along regardless.
Web developers have historically only bothered with such trivia as standards compliance and as a way to test their pages in multiple browsers when the market landscape has forced them to. This is what made Firefox's early years so painful: most developers tested in Internet Explorer and nothing else, leaving Firefox compatibility to chance. As Firefox, and later Chrome, rose to challenge Internet Explorer's dominance, cross-browser testing became essential, and standards adherence became more valuable.
Two costs more than three or four
When developers test and design in only a single browser, adding a second into the mix can be relatively expensive and complicated; that second browser will typically reveal unwitting dependencies on the particular behavior of the first browser, requiring lots of changes to stick more closely to the standards. But adding a third tends to be cheaper, and a fourth cheaper still. Moving from one browser to two already means that the worst of the non-standard code and dependence on implementation quirks must be addressed.
With Chrome, Firefox, and Edge all as going concerns, a fair amount of discipline is imposed on Web developers. But with Edge removed and Chrome taking a large majority of the market, making the effort to support Firefox becomes more expensive.
Mozilla CEO Chris Beard fears that this consolidation could make things harder for Mozilla—an organization that exists to ensure that the Web remains a competitive landscape that offers meaningful options and isn't subject to any one company's control. Mozilla's position is already tricky, dependent as it is on Google's funding. But Mozilla is doing important, desirable work—Firefox has improved by leaps and bounds over the last year, and the development of the Rust language—which hopes to wed native code performance with safe memory handling—continues to show promise.
By relegating Firefox to being the sole secondary browser, Microsoft has just made it that much harder to justify making sites work in Firefox. The company has made designing for Chrome and ignoring everything else a bit more palatable, and Mozilla's continued existence is now that bit more marginal. Microsoft's move puts Google in charge of the direction of the Web's development. Google's track record shows it shouldn't be trusted with such a position.
[contf] [contfnew] 
Ars Technica
[contfnewc] [contfnewc]
