Webkit2 High Level View

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it. Why is it named WebKit2? The somewhat pedestrian reason is that it’s an incompatible API change from the original WebKit, so it will probably be installed as something like /System/Library/WebKit2.framework on Mac/gtk/Qt/Efl.

webkit2 process model

Notice that there is now a process boundary, and it sits *below* the API boundary. Part of WebKit operates in the UI process, where the application logic also lives. The rest of WebKit, along with WebCore and the JS engine, lives in the web process. The web process is isolated from the UI process. This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multi-core CPUs. There is a straightforward API that takes care of all the process management details for you.

There are 2 process models in WebKit (more precisely, there are 3, but for now I don’t take with thread-based solutions into account): the default is the secondary process model, and we can easily switch to shared process model as well.

Shared Secondary process model is default process model in webkit2.


Use a single process to perform content rendering. The process is shared among all the WebKit2 WebView instances created by the application: if the process hangs or crashes all the web views in the application will be affected. This is the default process model, and it should suffice for most cases.

Another Process model: Secondary Process Model


This process  model use one process for each WebKit2 WebView, while still allowing for some of them to share a process in certain situations. The main advantage of this process model is that the rendering process for a web view can crash while the rest of the views keep working normally. This process model is indicated for applications which may use a number of web views and the content of in each must not interfere with the rest — for example a full-fledged web browser with support for multiple tabs.