- From: Ilya Grigorik <igrigorik@google.com>
- Date: Thu, 28 Apr 2016 15:11:49 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CADXXVKrcaQ9XmqYchMN7DsKvGrdXg06ecYCgUwLX-hMu3=8zcQ@mail.gmail.com>
Hey all. I'm often approached with "DevTools / tracing / <insert favorite tool here> gives me this really useful performance metric and I'd love to (no, *need to*) have it available via RUM. Can we spec and ship a new API to expose it via Performance Timeline?" The above inevitably prompts a series of discussions on the differences between "local" vs "remote" profiling, privacy and security limitations of each, best practices for mitigating various concerns, and so on. After having this discussion a few too many times with different people, I've tried to put together a braindump that captures the highlights: https://docs.google.com/document/d/1V-p7DNpBx8j- fzXuN8poy8rs4xMYSDN5hgYPaFXMRMY/edit *"... just because something is possible to measure, and perhaps is even highly desirable and useful to many developers, does not mean that it can be exposed as a RUM API. The goal of this document is to explain why that is the case, and to provide guidance for what needs to be considered when making or evaluating a proposal for such API’s. "* I don't claim that it is complete and covers every corner case, but hopefully it lays out a basic framework for how to think about this space. Would love to hear any comments or feedback. Anything that's you disagree with, is missing, etc? ig p.s. big thanks to Todd Reifsteck, Yoav Weiss, and Nat Duca for feedback on early drafts.
Received on Thursday, 28 April 2016 22:12:57 UTC