{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/frame-timing/issues/47","labels_url":"https://api.github.com/repos/w3c/frame-timing/issues/47/labels{/name}","comments_url":"https://api.github.com/repos/w3c/frame-timing/issues/47/comments","events_url":"https://api.github.com/repos/w3c/frame-timing/issues/47/events","html_url":"https://github.com/w3c/frame-timing/issues/47","id":102445672,"number":47,"title":"Should Frame Timing report slow frames only?","user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-08-21T19:14:01Z","updated_at":"2015-08-26T21:01:46Z","closed_at":null,"body":"The goal of FT is to help developers identify jank (<60FPS), as experienced by real-world users running the application on their local hardware. \r\n\r\nAs of today, the proposed solution addresses this by surfacing paint + composite events for **every frame**, regardless of how long it took. In turn, as a developer, if I'm interested in detecting jank I'd end up having to subscribe to the full event stream and write a filter to identify slow frames. \r\n\r\nInstead, should we consider surfacing only the slow (>16ms) frames? This still addresses the key use case of Frame Timing and offers some nice advantages. In no particular order...\r\n\r\n* The developer does not have to roll their own filter to identify slow records (our primary use case).\r\n* We significantly reduce the amount of emitted records: less overhead for the UA, and less records for the application code to deal with.\r\n* We significantly reduce the potential security+privacy implications of interaction with :visited (https://github.com/w3c/frame-timing/issues/40)\r\n  * By exposing paints for each and every frame, regardless of how long each took, we provide an explicit signal on any \"href-triggered repaint\" that can be abused to traverse your navigation history. In https://github.com/w3c/frame-timing/issues/40 we discussed a number of plausible mitigations, but none of those were conclusive and would likely come with _high_ implementation complexity and implications.\r\n  * By exposing slow frames only (i.e. >16ms), we significantly reduce the attack surface: FT still emits a record on \"href-triggered repaint\" whose cost exceeds 16ms, but you can already detect that today  via a rAF timing attack.\r\n\r\nThat said, we do forfeit some functionality as well. A trivial example is an FPS meter, where you'd want to get records for each and every frame. With slow-only model, you'd end up assuming that lack of FT records means you're running at 60FPS, and then show dips in the meter when you get slow records. That said, perhaps that fine.. we [determined earlier that we won't expose detailed cpu/work timing data](https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0019.html) in FT, so knowing that you had a 'fast record' is not terribly useful on its own.\r\n\r\n---\r\n\r\nPersonally I think the slow-only model offers some nice wins. The :visited interaction alone could be sufficient motivation, and there are additional wins with less UA overhead + developer ergonomics.\r\n\r\nThoughts? Anything that's missing from above analysis? Use-cases, other gotchas?"},"comment":{"url":"https://api.github.com/repos/w3c/frame-timing/issues/comments/135169290","html_url":"https://github.com/w3c/frame-timing/issues/47#issuecomment-135169290","issue_url":"https://api.github.com/repos/w3c/frame-timing/issues/47","id":135169290,"user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"created_at":"2015-08-26T21:01:46Z","updated_at":"2015-08-26T21:01:46Z","body":"Talked with @mpb, he'll put together a pull to convert to 'slow only'."}}