https://bugzilla.wikimedia.org/show_bug.cgi?id=52287
Matthew Flaschen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from Matthew Flaschen <[email protected]> --- (In reply to nuria from comment #6) > I understand that this change is better than blocking or 'arbitrary' delays. > Let me rephrase: it introduces a delay as every page viewing is been delayed > "ad minimum" by the amount of time it takes for the event to be logged (1 > round trip). "Ad maximum", as you noted, the delay would be 500ms. Correct? Yes, at maximum, the delay would be 500 ms. > Even if bits is 5 times faster the event reporting time still would take > ~100ms (I know, totally wild guess here, but I am trying to make the point > that adding 100ms to page load time might not justify the data we are > gathering). Right, if we go this route, it's a cost-benefit analysis. I agree 500 ms (and even less) has an impact on some users, even if subconscious (http://googleresearch.blogspot.com/2009/06/speed-matters.html). > >I agree this is preferable, but browser support is an important issue. > >Also, if >they leave the site, it won't work, but so far we've been > >concerned with same->site links. > > If that is the case could we implement a localstorage/polling solution for > browsers that support it? Yes. Actually, it may be able to use jquery.jStorage, which is already in core and has broad browser support (IE6+, Firefox 2+, Safari 4+, Chrome 4+ and Opera 10.5+) by being able to use localStorage, globalStorage, and userData. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
