Event Timeline
Hey Adam, given the card is empty I obviously can't comment on what you have in mind but if this relates to lazy loading images, I'm not sure any more metrics will be useful at this point.
We should just make a change to improve this and measure the results on the cluster. It's a no brainer in my view and any tests we do will show much more enlightening results than any guess work using EventLogging.
(On a general note: I highly recommend not creating empty placeholder tasks - Jon K did this a lot and it caused lots of confusion and duplication of tasks). We'd close a task like this from a volunteer and should hold ourselves to the same standard.
This is the task we discussed during standup that I said I needed to fill in. I've removed the sprint 65 tag for the time being.
@Jdlrobson, @ori, supposing we do image lazy loading or the like, does the existing instrumentation allow us to understand the impact on bandwidth conservation?
After discussing with @ori, we think we should be able to sequence the instrumentation after we've figured out the image loading approach. We'll need to make sure the image loading approach can be staged in a manner such that we can compare performance both with and without the enhancements so that the instrumentation can catch both things adequately.
That's not exactly what I meant -- I think you'll need a good benchmark to do this right, but we can postpone instrumenting things for an impact statement.
I'm going to mark this task invalid, as it doesn't neatly fit anywhere and @Jdlrobson had delinked it. Less clutter!