*Browser bias: *I was under the impression that Nav
timing was only
available for modern browsers, so that might affect a bit of a bias into
the
situation.
It is well supported for IE >8 . The notable exception are iOS devices.
http://caniuse.com/#search=navigation
For details:
http://www.html5rocks.com/en/tutorials/webperformance/basics/
*Browser cache: *Browser cache is going to reduce any
gains we might see
due to reduced
latency or increased bandwidth. It would be nice if we
could compare the
speed changes of cached/non-cached page/asset loading.
Actually this is not an issue if you can assume cache hits/misses are the
same before and after deploying ulsfo. What you care about in this case are
the network times more than anything, as Faidon's changes do not affect the
rendering of the page once all assets are downloaded. Now, if his changes
also have the effect to clear cache, then we need to compare a data before
his changes to data after his changes once caches have warmed up.
If there is an impact for network times should be "measurable" via
transport times (they should be lower). If these smaller transport times
have an effect on user experience (which is an entirely different matter)
should be measurable via DOMContentReady (should be faster). Whether there
is a real impact might get muddled as time passes and new features are
deployed that affect number of assets on the page and rendering times.
I would analyze desktop and mobile data separately.
Nuria
On Mon, Feb 10, 2014 at 5:50 PM, Aaron Halfaker <ahalfaker(a)wikimedia.org>wrote;wrote:
I've created a card in trello to help us track
this request.
https://trello.com/c/dNODZnr0/108-measuring-ulsfo-s-impact-on-site-performa…
On Mon, Feb 10, 2014 at 10:02 AM, Aaron Halfaker <ahalfaker(a)wikimedia.org>wrote;wrote:
The schema contains "originCountry"
that should enable us to filter in
this way.
I have two points:
*Browser bias: *I was under the impression that Nav timing was only
available for modern browsers, so that might affect a bit of a bias into
the situation.
*Browser cache: *Browser cache is going to reduce any gains we might see
due to reduced latency or increased bandwidth. It would be nice if we
could compare the speed changes of cached/non-cached page/asset loading. I
don't think that the current schema will allow us to do this. Despite
this, we should still be able to get a good sense for how cached/non-cached
page loads were affected in general.
-Aaron
On Mon, Feb 10, 2014 at 9:43 AM, Dan Andreescu <dandreescu(a)wikimedia.org>wrote;wrote:
I was wondering if you have an easy way to
measure and plot the impact
> in page load time, perhaps using Navigation
Timing data?
>
+10^9. I was rather excited to see ulsfo back up and I tried to quickly
figure some correlation out of
https://gdash.wikimedia.org/
dashboards/frontend/ , but I failed.
I think what's needed here is mostly some brilliant idea on how to
visualise / graph the data available there by region (and maybe also by
project / kind of editor e.g. unregistered vs. registered vs. sysop)
without making thousands graphs for each of the combinations. Or just one
graph for the region moved to ulsfo to start with of course. :)
Does the NavigationTiming data have the hostname of the varnish that
served the request, and do we have data on which hostname served which
geographic area at a particular time?
If so, we can generate a before and after average performance map by
region served, to see if there are any differences.
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics