Responsible JavaScript

While TTI is great, it describes whether a page is interactive, not whether that page will respond to the first input quickly. First Input Delay (FID) is a field metric that fills in this information gap by measuring the delay between the first interaction with a page and when the browser responds to that interaction. FID isn’t strictly a JavaScript metric. Interactions that don’t rely on JavaScript (links, form controls, and so forth) still factor into the metric’s calculation. If you rely significantly on JavaScript to drive interactivity, however, FID may well reflect that. FID seems simplistic at first glance, but identifying the cause behind a high FID score gets tough. The first interaction with a page will vary from person to person. Someone on a fast device may present with a high FID score because of excessive JavaScript activity, while someone on the same page with a slow device may show a low FID score because they interacted with the page while the main thread was quiet. One way to troubleshoot high FID values is to contextualize them so that you know what’s happening at the time of the input delay. You can record long tasks from the Long Task API ( http://bkaprt.com/rjs39/03-08) occurring around the time of the FID itself. This is what I’ve done in a small metrics collection script I built ( http://bkaprt.com/rjs39/03-09). Being a field metric, FID yields a wide range of values, so it’s sensible to focus on the 95th percentile of those values (http://bkaprt.com/rjs39/03-10). This strategy prioritizes those experiencing extreme input latency.