Once upon a time, browsers were much simpler than they are today. The browser is a single operating system process, and everything happens in one process. It’s also an easier and more efficient way for assistive technologies to use the Accessibility Tree to get information about user interfaces and web content.

But as usage and complexity increase, so does the risk of security breaches. To improve performance, stability, and security, browsers started moving different web pages into different processes. And to further improve security, today’s browsers also sandbox the web content process, further reducing access rights. This means that it is more difficult than ever for assistive technologies to access or inject code into a web content process that contains an accessibility tree, complicating the accessibility situation.

The Firefox browser’s Accessibility Engine is responsible for providing assistive technologies such as screen readers with the information they need to access web content. These tools need to interact with the browser and react to changes by the user or about the website. Using Firefox to access content on the web can actually be a drag if the browser is experiencing excessive lag due to slowness or other issues.

While the existing accessibility engine architecture has served Firefox well, under the current architecture, the Firefox team cannot further improve speed, and the existing accessibility engine is too complex, difficult to maintain, and has serious stability issues , and require different implementations on different operating systems. The Firefox team decided to refactor the accessibility engine, and thus the “Cache the World” project was born.

The goal of this project is to make Firefox faster when used with screen readers and other assistive technologies, especially on Windows. According to the official figures (the following table provides a time comparison before and after the refactoring), under the new architecture, Firefox has significantly improved its speed in multiple scenario tests.

For example, opening a Gmail message from the inbox now takes 100 milliseconds, compared to 200 milliseconds before. Likewise, closing a Gmail message and returning to the inbox takes 150ms on the new architecture, compared to 410ms on the old architecture.

The results achieved are even more impressive when loading large files, tables, and other content. For a test with a large file, this performance boost improved the time from 175 seconds to just 15 seconds. In another test with a table page with more than 12000 rows, the loading speed increased from 128 seconds to 6 seconds.

In the new architecture, Firefox asynchronously pushes the accessibility tree from each web content process to the main UI process. When assistive technologies query the accessibility tree, all queries are answered from the cache without requiring any calls between Firefox processes. When a page is updated, the content process asynchronously pushes cache updates to the main process. The speed improvements far exceeded the Firefox team’s expectations, and unlike the old architecture, they now have full control over how and when the buffer is updated, so there’s plenty of room to further improve Firefox’s performance. As for code maintenance, about 20,000 lines of code, most of which are OS-specific, will be able to be removed once fully released.

The new architecture is already enabled in Firefox Nightly. If all goes well, Mozilla plans to enable this feature for Windows and Linux users in the Firefox 110 beta in January 2023. After that, the feature will be officially rolled out to Windows and Linux users in stages in Firefox 111 or 112 releases. The Mac version still needs more development time, so it will be launched later.