Má to svůj důvod, stejný, který se objevoval poslední roky jak přecházelo od GCC na Clang také FreeBSD. Clang poskytuje lepší diagnostiku (lepší chybové a jiné hlášky kompilátoru) a kompiluje kód rychleji. Google tak Clang používá pro své programy na Mac OS X již delší dobu, testovací sestavení linuxových verzí také kompiluje Clangem. Až dosud pro linuxové Chrome (a Chromium) bylo používáno GCC 4.6.x, od Chrome 38 tedy Clang.

Přechod proběhl bez vážnějších problémů, díky dřívějšímu užívání Clangu. Ač výsledný kód je podobně rychlý jako ten kompilovaný GCC, velikost binárek je zhruba o 8 % menší. To se může jevit nepodstatné (vždyť kolik MB zabírá Chrome, že), ale pokud bychom se na to modelově podívali kupříkladu z hlediska celého Androidu či Chrome OS, pak úspora diskového prostoru na levných tabletech a smartphonech s omezenou velikostí flash paměti může být významná.

Nevýhody zde jsou, kupříkladu standardně (automaticky) Clangem kompilované binárky nefungují na starších 32bit vydáních Debianu, což je problém, který se podařilo zjistit až s vydáním stabilního Chrome 38. Jistě ale bude mít řešení. Výhodou plynoucí mimo jiné z menší velikosti binárky, je rychlejší spouštění prohlížeče.

Výsledky srovnání jsou ale typicky linuxové: některé subtesty vycházejí lépe pro Clang, jiné pro GCC, celkově je to „±autobus“ plichta. Z technického hlediska je přechod na Clang pro běžného uživatele bezvýznamný. Pro vývojáře v Googlu investicí do budoucnosti a z „politického“ hlediska zavedením vyšší univerzality, pokud by GCC bylo někdy v budoucnu staženo kolem hrdla nějakou ještě restriktivnější licencí „GPLv4“, znemožňující ve svých paragrafech kupříkladu použití GCC kompilované binárky na operačním systému s nekompatibilní licencí. Ale to je spekuluji, nic takového se aktuálně nechystá a i rozestup mezi GPLv2 (6/1991) a GPLv3 (6/2007) nasvědčuje, že i kdyby nastalo worst case scenario, je kýbl času na řešení.