Renderer process models

Because web content is so varied and so unpredictable, the rendering engine—the browser component that interprets and formats web pages—will inevitably crash or hang, no matter how well it’s designed. For the same reason, the rendering engine can never be perfectly secure.

Nevertheless, a browser must behave reliably. It should, for example, recover gracefully from issues caused by unpredictable content, without corrupting other content and without having to perform a complete restart.

To address these requirements, the QNX Web Browser supports the following renderer process models. Each model affects how the browser allocates pages into renderer processes, and each strikes a different balance of reliability, security, size, and performance:

Model	Description
Process-per-site	Create a single renderer process for all instances of a site.
Process-per-site-instance	Create a separate renderer process for each instance of a site.
Process-per-tab	Create a separate renderer process for each group of script-connected tabs, where each group consists of a tab and any other tabs that the tab opens using JavaScript code. This model allows JavaScript calls to be made between tabs.
Single-process	Create a single process to run both the browser and the rendering engine.

The following table summarizes the benefits and tradeoffs of each renderer process model:

Model	Benefits	Tradeoffs
Process-per-site	Isolates content from different sites: If one site causes failures or consumes resources heavily, other sites remain unaffected. This model can also help reduce memory consumption, as it typically creates fewer concurrent renderer processes than the process-per-site-instance and process-per-tab models.	Can result in large renderer processes. If a site hosts a variety of applications, a single (and consequently larger) renderer process will handle all of them. Failures or resource contention in these applications could affect many tabs, making the browser seem less responsive.
Process-per- site-instance	Isolates content from different sites: If one site causes failures or consumes resources heavily, other sites remain unaffected. Also isolates visits to the same site: If a visit to a site causes failures or consumes resources heavily, other visits to the site (i.e. visits in other tabs) remain unaffected.	Can create more concurrent renderer processes than the process-per-site model, leading to greater memory overhead. On the other hand, the larger number of processes can increase stability and enable greater parallelism.
Process-per-tab	Isolates content running in different tabs: If a site in one tab causes failures or consumes resources, other tabs remain unaffected.	Leads to undesirable fate sharing between pages. If, within a tab, the user navigates to another site, the new page will share fate with any other pages in that tab.
Single-process	Useful for testing and debugging; also provides a baseline for measuring overhead imposed by other process models.	Fragile and insecure: A failure caused by any web page can bring down the entire browser.

Using a mix of renderer process models

You can run multiple instances of the QNX Web Browser at the same time, using a mix of renderer process models (i.e. one instance can use process-per-site, another instance can use process-per-tab, etc.). By default, the QNX Web Browser uses the process-per-site-instance model, which you can invoke explicitly with the --process-per-site-instance command-line option.