holidayextras / barometer

Framework agnostic browser performance metrics
MIT License
5 stars 5 forks source link

Expose a higher level timer to wrap gauge #7

Open msaspence opened 7 years ago

msaspence commented 7 years ago

Something like:

// Synchronous 
barometer.timer('path', function() {
  thingToBeTimed();
});
// Asynchronous with callback
barometer.timer('path', function (done) {
  thingToBeTimed(function() {
    done();
  });
});
// Asynchronous with promise
barometer.timer('path', function (done) {
  return thingToBeTimed();
});
theninj4 commented 7 years ago

First up, I love the idea of removing the hassle around timing something. My immediate reaction to this was around promises requiring a polyfill. I wonder how small a Promises polyfill is... If it's not an order of "tiny", I wonder if it'd be best to add features like this asynchronously after the page has loaded. We need the core script to load first to ensure we get page events before everyone else, I guess that doesn't mean we have to actually do anything else at that point.

msaspence commented 7 years ago

Yeah I also think the idea of a "two stage load" is interesting. I wonder if there is anything currently in the core script that could be moved into a subsequent phase?

theninj4 commented 7 years ago

I'm actually really impressed at how far UglifyJS and JSCrush can compress code, we might get away with more than I expect. Promises aside, this is worth implementing as usual. How about we only support Promises if they're supported natively?

msaspence commented 7 years ago

Yes but rather than saying "are these supported natively" can we duck type the returned value. i.e. if it exposes a promise like interface, we will treat it as such, this allows the application to load its own polyfill for Promises before any calls to timer. If the calling code is returning a promise and either the browser doesn't Promises or they have loaded a polyfil we don't have to worry.