- provides a fallback service so we can deliver – in real-time – those functions that the browser needs which were removed but turn out in fact to be necessary.
How it works
- assign a unique identifier to each function (typically an integer that records where in the source the function occurs). This ID is used to uniquely identify each function in the source.
- add an extra statement at the beginning of each function that will record the timestamp of the function when it is first called.
On the next request for this same file, the service returns the instrumented code. A usage trace is beaconed back to the service as soon as this code is loaded, and the browser continues to send usage traces back after 2, 4, 8, 16 seconds and so on, until an upper limit of 10 minutes is reached. A randomly-generated unique ID is sent along with the trace data so the service can collate trace data from multiple browsers.
A single trace consists of an array of function identifiers and timestamps. The service looks for gaps in this trace by sorting the array by timestamps and then identifying gaps within the timestamp data. If there is a large-enough gap between one function and the next, the service decides to mark a partition boundary.
The service does not simply send the optimized code for every request it receives after this point – instead, for about 4% of requests it will send the instrumented code again. This ensures that the service can respond in a timely manner to changing user behavior.