Blog

This page has updates on Web Replay's development and related technical or philosophical topics.

Web Replay Protocol
May 2, 2020

We're going to push back the beta for a little while so that we can do some restructuring. Right now, Web Replay is a monolithic product: a browser which can make recordings, and builtin devtools for replaying and debugging those recordings. This makes it much harder than it should be for people to build on top of Web Replay. We want Web Replay to be easy to use for anyone wanting to build new devtools or integrate into their existing devtools. We were originally planning on adding functionality for this down the road, but after some strong interest lately from people wanting to build on Web Replay, we're pushing those plans up.

Soon, Web Replay will have three components. First, the browser will be basically the same as it is now, except that it will use the browser's normal devtools and won't replay recordings. Second, the Web Replay devtools will be converted to a web app which can be viewed in any browser. These devtools will be fully open source, and built on top of the third component: the Web Replay Protocol, a well defined and documented protocol which any tool can use to connect to our servers and inspect recordings.

The Web Replay Protocol will be modeled after the Chrome DevTools Protocol: sending similar JSON-RPC like messages over a websocket, operating at a similar level of abstraction, and using the same methods and structures when appropriate.

Documentation for the Web Replay Protocol will be expanding rapidly over the next couple of weeks.

Stress Test Videos
April 21, 2020

Performance work for the beta is mostly done now, and stability is getting better every day. The videos below show performance for stepping and logpoint stress tests on Facebook, which is a very complex website.

In this video, Facebook is loaded and the test jumps to five random places on the page, before stepping in 10 random directions at each of them. Pausing 55 times like this and loading the frames and scopes data in the debugger takes about 40 seconds.

In this video, Facebook is loaded and 1000 logpoints are added at random places throughout the recording, to evaluate the arguments of whichever function is being called at that point. Doing these 1000 evaluations and adding the resulting console messages takes about 12 seconds.

Instant Updates
April 2, 2020

We've been busy the last month making a bunch of stability and performance improvements to Web Replay. We want Web Replay to be a joy to use, and for it to work great on complex, real websites before we start beta testing. This process won't take forever; we're hoping to start beta testing later this April.

Our development strategy is based on an end-to-end testing framework we've developed that simulates user sessions — for example, recording and interacting with a website, then rewinding to random places in the tab's execution and stepping around in random directions (this is similar to tools like Selenium, though more tightly integrated with the browser's UI). This framework lets us make sure that Web Replay works reliably (no crashes or other errors) on these sites, and lets us study the tool's performance in detail to make sure it is also reliably snappy.

Performance is an especially interesting topic for a time traveling debugger. Thanks to Web Replay's architecture, recording a tab requires only a little overhead, but rewinding through a recording and viewing the state at different places needs to be fast too. There is a lot of machinery involved in jumping around between points in a recording, and it's natural to expect this to be slow compared to a traditional debugger. This doesn't have to be the case; it's quite the opposite, actually. When, say, stepping around in a traditional debugger, the program being debugged needs to unpause, run forward to the next place where it will pause, and then its state needs to be inspected and the UI updated to reflect that new state. This typically requires hundreds of milliseconds of unavoidable CPU time and IPC delays.

When using a time traveling debugger, this overhead is avoidable. Before the step button has even been clicked, the debugger knows exactly where the program will pause after the step, and exactly what the program state will be at that point. The information the UI needs can be precomputed, so that if the stepping button is clicked the UI will update instantly. Doing this well requires care; we need to do as much computation in the cloud (with its massive parallel resources) as possible, and minimize the size of the precomputed data downloaded to the user's machine. Still, this is within reach, and we'll be using our testing framework to make sure that instant updates like this are the norm when stepping or doing similar navigations with Web Replay.