Zoompf's Web Performance Blog

Note: Archived Content

This is the archived version of the Zoompf blog. Since our acquisition by Rigor, all our new research and posts on web performance are being published on The Rigor Blog

Performance Implications of Opera’s Switch to WebKit

 Billy Hoffman on March 1, 2013. Category: random

Opera recently announced that it was dropping its Presto layout engine and Carakan JavaScript engine and adopting WebKit and V8. Actually, Opera announced they were going to develop “[products] built using the open-source Chromium browser” of which WebKit and V8 are the most visible and well known components. This is a pretty amazing shift and the aspects and implications of the shift have been discussed in numerous places. However most of these discussions have centered on how Opera’s shift may effect other browser vendors. And by that I mean almost everyone decided to write a poorly sourced opinion piece about how this means “Mozilla and/or Microsoft is DOOMED!”

I thought I’d be different and instead focus on this shift improves front-end web performance. I’m excited about Opera’s adoption of technology from Chromium because I see several ways this will improve web performance as a whole while making it easier to write faster sites for web developers.

WebKit Layout Engine

The first big area of improved web performance comes from adopting the WebKit layout engine. This improves performance in several many ways.

First of all, there is now one less set of vendor prefixes you need to add to your CSS files. Forget about needing -o- in the future. It’s also one less vendor you have to wait on to support a new styling feature before removing those vendor prefixes. For those smart web developers using LESS or SASS you didn’t need to worry about this since it was abstracted away. However the net result is that CSS rules, either hand created or programmatically generated, can be slightly smaller. This is good for everyone and is a small performance win.

Second is layout bugs and tag bloat. Often adding an extra empty <div>, or wrapping a block of content in an extra <div> are needed to make an area of a page render properly in all browsers. These flaws affect all browsers for the simple reason that laying out HTML is hard, and the correct way to do it is often vague. Reducing the number of layout engines reduces the number and need for these work arounds, slightly reducing the size of HTML.

Next is CSS performance. The performance or features like text-shadow and box-shadow vary with each layout engine and can be quite slow on mobile. By reducing the number of style/layout engines you need you code to work on, it becomes easier to decide which native CSS features you can or cannot use. This reduces the need for fall backs and results in potentially faster code.

The final benefit is in mobile. While Opera has had little desktop marketshare, they have a huge mobile presence. This switch makes Webkit by far the dominate mobile layout engine across all kinds of mobile devices. In this near-monoculture mobile environment, heavy browser compatibility frameworks like jQuery become less relevant. To be fair, jQuery does provide more than just abstracting away browser differences. In their own words, jQuery provides “a concise, powerful, and expressive API for managing HTML documents that is far better than the original W3C DOM APIs.” However the monoculture of WebKit on mobile means that developers can use a framework like Zepto instead of jQuery. Zepto is more than 75% smaller than jQuery while providing an equally powerful, concise, and expressive API. The net result to mobile developers is less JavaScript to download, parse, and execute, which is a win for front-end web performance.

V8 JavaScript Engine

Opera is also moving to V8 for its JavaScript engine. Reducing the number of JavaScript engines doesn’t have the same impact as reducing the number of HTML layout and rendering engines. Now, there are changes you can make to your code to improve execution on a specific JavaScript engine, such as certain call graph patterns to improve JIT compilation. However these are fairly low level optimizations, are very brittle, and not something that most developers need to worry about. So fewer JavaScript engines to targets doesn’t really improve front-end web performance.

What will help is the raw power of V8 over Opera’s own Carakan JavaScript engine. While Opera has had impressive JS performance in the past, (especially considering its install base), V8 has consistently beaten it. Opera’s switch will result in faster execution of JavaScript, which is a win for front-end web performance.


Bugs happen, and we have all seen bugs that directly affect web performance (protocol relative CSS downloads, caching issues, SPDY’s CRIME attack, etc). To resolve bugs you need two things: users to find the bugs and developers to fix the bugs. Making Opera Chromium based and getting rid of Presto and Carakan concentrates more users and more developers onto Webkit, V8, and other area’s of Chromium like the HTTP/SPDY and caching subsystems. More eyeballs will find more bugs more quickly, and more engineerings resources will resolve those bugs faster. This is a big win for software quality, which in turn is a big win for performance.

Hopes and Dreams

So far we have talked a lot about what developers gain with Opera using parts of Chromium, as well as the bug fixes they could contribute back. But what if Opera did more than that?

Remember that Opera announced they were going to be using parts of Chromium. This includes WebKit and V8, but also includes many other important subsystems. Opera also said that “Opera will contribute to the WebKit and Chromium projects.” Got me thinking about what Opera-only features exist today which improve web performance that could be pushed into Chromium? After all, this would allow those features to then incorporated into Google Chrome improving web performance for even more users and web developers. What would I hope and dream of for Opera to contribute into Chromium?

My first thought is HTTP pipelining. Opera is the only browser which does this by default, though it is a very conservative approach. While SPDY is certainly helpful for performance, it requires SSL which will slow its adoption and can even place an upper cap on total adoption. HTTP is not going anywhere and the majority of page load time is still the TTFB for content requests. Using HTTP pipeline to allows for primitive multiplexing of HTTP requests and responses and could be a big win for front-end performance if deployed more widely. I would love to see Opera provide its knowledge, code, and experience around HTTP pipelining back into the Chromium project.

My second thought is Opera Mini and its Opera Binary Markup Language. Opera Mini is a proxy based web browser for less powerful phones. The phone makes all its requests via the proxy servers. The proxy servers speak HTTP with the origin web servers, gathers the resources needed, and even does some partial page rendering and JavaScript execution. What gets sent to the client is OBML, which is a binary-based format over a non HTTP protocol. By controlling the link between the phone and the proxy servers, Opera ensures that this connect is used as efficiently as possible and is only transporting content the phone needs and can display. This approach is 2-3 times faster than having the phone handle the web traffic directly. SPDY is shifting us away from text-oriented request/response protocols to binary-based multiplexed protocols. Opera has a lot of experience in this space, and I’d love to see some of this technology make its way into other browsers. The end result is a faster mobile browsing experience, especially on lower end devices in emerging markets.


From adopting a faster JavaScript engine, to reducing CSS and HTML complexity, to enhancing its ability to find and resolve bugs, Opera’s shift to technologies inside of Chromium like WebKit and V8 are a clear win for front-end web performance. I’m very happy and excited about this shift, and encourage Opera to add its currently proprietary features and techology like its HTTP pipelining logic and OBML back into Chromium so everyone can benefit.

Want to see what performance problems your website has? Zoompf can analyzed your website for 400 issues which affect web performance and load time. You can get a free performance scan of you website now and take a look at our Zoompf WPO product at Zoompf.com today!


Have some thoughts, a comment, or some feedback? Talk to us on Twitter @zoompf or use our contact us form.