The first contribution to the browser API from Facebook

cover

Our position as the owners of a popular website — and our work in supporting the popular React platform — gives us unique capabilities and insights into working with the browser that we want to use to solve the “queuing” problem. As an active member of the Web Standards Community (W3C), we participated in the discussion of many innovations, including service workers and CSS-overscroll , but until recently we never created our own initiatives to improve the web browser. In order to achieve a significant increase in productivity, a new API was proposed, which, as a result of close cooperation with our colleagues from Google Chrome, was provided for a trial version . Chrome v74 will include the isInputPending API , and can be used to improve both the overall JavaScript runtime and the response time to events. This is just the first step to better scheduling javascript on the web. We hope to get feedback from developers and use them to create the final version of the API.

One of the most important performance indicators in the modern web is the time it takes to respond to a user event (pressing a button or entering a field), with its full visualization. On Facebook, we divide and measure events in four steps:

operating system receives data
actual start of processing
start displaying changes on screen in response to an event
processing is complete and the result is visualized

When we evaluated our most productive products, it was noticed that the waiting time in the queue gives the greatest delays. The queue refers to the time between when the user interacts with the page (for example, click or tap), and when the actual event handling begins. In some cases, this delay can be quite substantial. Imagine that you click on the notification icon, and then wait a minute for the button to respond. Probably no one will wait for an answer.

Fast download or fast response: select one

There is a difficult trade-off between fast page loading and interactivity. If a website requires javascript, one option is to run it all in one block. But it can create problems. JavaScript engines within web browsers are usually single-threaded, that is, they can perform only one operation on a page at a time. In the case of a page loading, this means that if a user clicks on something, the browser must put a click event in the queue until the entire block of JavaScript is launched.

Like many other sites, we solve this problem by breaking the javascript into small blocks. While the page loads, we run a little javascript and then return control to the browser. The browser can then check its queue for input events and see if there is anything to handle. The browser can then return to executing JavaScript blocks as they are added. It helps, but can cause other problems. Each time we return control to the browser, it takes some time to check its turn in input events, process the events, and select the next block of JavaScript. Thus, even though the browser responds to events faster, we still need to find a balance between the size of the code blocks and the frequency with which we are inferior to the browser. If we change control too often, the page loads too slowly, if on the contrary - less often, the browser takes more time to respond to user events, and people get frustrated.

loadfast

If we run large blocks of JavaScript, the browser can send custom events with a long delay (at the top); if we run smaller blocks, the page loads longer (bottom).

isInputPending solution

When we first discovered delays in the queue, we turned to our colleagues in Chrome. We wanted to see how everything will look if we come up with a new approach to downloading that will eliminate this dilemma of compromise. After talking with them, we suggested isInputPending. The isInputPending API is the first to use the interrupt concept for user events on the web.

Under the hood, isInputPending listens to the Chrome input queue on the compiler side to intercept events before they are added to the main thread. Since this listen is performed outside the main thread, isInputPending calls do not use a lot of computational resources and should be very fast. This allows developers to invoke APIs frequently and maximize responsiveness.

As soon as we prepared this proposal, we turned to the W3C working group on web productivity and got the consent of various browser vendors that our idea is worth exploring. Later, we collaborated with our colleagues in Chrome, independently implemented a new API and sent the appropriate code fixes to Chrome. Thanks to Chrome engineers, we received trial patches that allow you to test changes and get feedback from developers before a full release. This version will allow us to understand how important this API is for developers and will determine our future conversations about this API with web browser vendors. This is the first time we have gone through all the steps of developing a web API, from discussing a proposal on a forum to sending code to a web browser.

How isInputPending works

As the name suggests, isInputPending tells you if there are any events waiting to be entered. Developers can use this information while JavaScript is running to decide if they want to return control to the browser. When properly used, isInputPending can completely eliminate the dilemma of fast loading and interactivity.

To work with API, navigator.scheduling.isInputPending() . In fact, if the browser expects the event to be sent, this method returns true . When called without any arguments, all supported event types are checked. In addition, it is possible to manually specify a list of event types: mouse, wheel, touch, which should be checked for pending input.

Example: checking any types of events

 while (workQueue.length > 0) { if (navigator.scheduling.isInputPending()) { //       break; } let job = workQueue.shift(); job.execute(); }

Example: checking for specific input events

 while (workQueue.length > 0) { if (navigator.scheduling.isInputPending(['mousedown', 'mouseup', 'keydown', 'keyup'])) { //       'mousedown'  'mouseup'  'keydown'  'keyup' break; } let job = workQueue.shift(); job.execute(); }

What's next?

If the community review is positive, isInputPending can become fully available in Chrome. Then we can get rid of these noticeable delays in the queue and make work on the Internet faster and more flexible for people on our sites. For developers who also want to get rid of delays in queues and improve interaction and download performance, a trial version will be available soon. Sign up here and share your opinion on the trial version as soon as it is available.

The transfer process isInputPending to Chrome is a new method for developing web standards on Facebook. We hope to continue developing new APIs and increase our contribution to open source web browsers. In the future, we could potentially embed this API directly into React so that developers can take advantage of the API out of the box. In addition, isInputPending is now part of the great work of creating primitives for scheduling on the web. We look forward to continuing our collaboration with Chrome. In the end, we hope to see browser tools that allow developers to integrate more deeply into the browser’s task queue and even allow developers to understand browser priorities for various network requests and tasks.