I would like to know if "scroll" event can be added to the Google analytics universal code? i have the below
setTimeout("ga('send','event','engaged users','page visit 30 seconds or more')",30000);
I wanted to track visits over 30secs that the scrolls
You can use window.scroll which is available in the jQuery API.
$(window).scroll(function() {
ga('send','event', 'engaged users');
});
See https://api.jquery.com/scroll/
There are several plugins/libraries out there that add scroll tracking, but if you want to do it yourself make sure you don't send too many events.
You shouldn't send an event to GA directly on the window.onscroll event - this is fired dozens of times a second. It will chew through your hit allowance and it won't provide any useful data.
Even a sampled scroll event isn't much better (where you set a timeout every few hundred milliseconds to check if the user has scrolled) - it still sends potentially hundreds of events user page view.
You should either set it to fire on certain scroll "thresholds" (e.g. 20%, 50%), or, the better way in my opinion is to store a variable with the maximum scroll depth and then use the document.onbeforeunload event to fire just one event at the end of the user's page view. This gives way more accurate data and doesn't send too many events.
onbeforeunload has some browser inconsistencies though (especially on mobile), so you'll want a fallback for that. There's a full tutorial here on creating a cross-browser scroll tracking plugin with tons of code examples here: building a better scroll tracking plugin
Related
I'm trying to keep track of how much time a user spends on a given view in a react native iOS app, and then send it to Parse as a custom analytics item. What's the best way to do this?
My initial thought was to track the start time and exit time in the code used to generate a each individual page, but I was hoping there would be a more elegant way. Basically what I'm after is the amount of time that each view spends on top of the navigator stack.
The Navigator will emit events for when the different routes will receive and lose focus which should be enough for you to determine how long they spend on each view. You might use it together with the componentWillUnmount lifecycle function.
navigator.navigationContext.addListener('didfocus', event => {
console.log('Currently focused route is', event.data.route);
});
I have a web page which can be janky to scroll if certain styles are applied. My question is how can I systematically test the effect of individual styles. I don't want to just manually scroll down the page each time, I want to perform some replicable action so I can easily compare the effect of two different stylesheets. Is it possible to record and replay a sequence?
In Chrome you can try using:
console.timeline('description');
// your code
console.timelineEnd('description');
You'll get a deprecation warning, but it works to record a timeline.
OR
You could use The Intern http://theintern.io/ to automate the repeated task you want to do, for instance scrolling down the page.
In that case, you would write a test case for each style change, scroll the page while measuring with the Frame Timing API
https://github.com/GoogleChrome/frame-timing-polyfill
Each test would expect the frame rate to be above a certain value.
what does Recalculate Layout Paint mean in chrome developer tool TimeLine records? and how to improve the page performance by reduce the page Recalculate,Layout and Paint's count? can give some suggestion?thanks
Basically, they're your browser figuring out how to draw the changes that you made to the page.
Don't worry about getting rid of them -- if you did that, your site would be static.
However... ...if you want to do something that IS useful for performance, which does have to do with reflows and repaints, then batch your changes together.
Lets say that you got a job at Twitter.
And your job is to write the next version of the window that adds each twitter post to the screen.
If a user gets 250 new tweets in their timeline, and you add each one in a loop, one after the other, the browser is going to slow way down, because every time you add one, it will have to reflow (move things around to make space for the thing you added) and repaint (style everything that was affected by the addition).
A better way of doing it would be to build the list of new tweets together off-DOM (ie: with elements that aren't actually on the page right now), and then add them all at once.
This cuts down on the number of times that a browser has to figure out where everything needs to go.
#Fabricio -- Micro-optimizing might not be great, but appending hundreds of browser elements in a loop, versus putting all of them in at the same time can make a big difference.
Just ask the Twitter guys, who weren't bothering to cache their jQuery objects.
Here's a very handy list of properties and methods that trigger the layout (reflow) of a page:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
You want to minimize these calls as much as possible -- especially in situations where performance is critical, such as during the scroll event, or when animating large blocks of content.
You can use the "Profiles" tab and "Audits" tab to detect the performance of your code. The will give you a report about your codes.
You can reduce the page Recalculate,Layout and Paint's count by many ways.
Append many child at one time.
Hide elements before change them.
Give images and other elements height and width.
I'm trying to determine some testing strategies for a Silverlight application of ours.
What I'd like to determine is the total time it takes for a grid to load and show data in the client. I've tried to put a timer round assigning the itemsource, but I need to know how long it takes the browser is finish loading the data into the grid.
Is this at all possible? If so, in what direction do I've to search?
This might help an article on MSDN "Loaded event timing in Silverlight"
http://blogs.msdn.com/b/silverlight_sdk/archive/2008/10/24/loaded-event-timing-in-silverlight.aspx
I think the main idea is to make use of the LayoutUpdated event. Since the event hangs off the FrameworkElement object I guess you could add a handler to all controls and effectively profiler all the framework elements of your Silverlight app. Something similar to the MVC Mini Profiler (SO uses/created this). http://code.google.com/p/mvc-mini-profiler/
I would certainly explore the LayoutUpdated event further.
Usually, when a View requires a lot of bindings, or some UI Elements like a Bing Map, it takes a "while" to load (like between half a second and a second).
I don't want a delay between a "tap" action (like tapping an element on a ListBox) and the navigation action (displaying a new page).
I don't mind displaying the page progressively. For example, for a Bing Map, I don't mind displaying a black page with only a title, and a second later, having the Map appear.
What are the best practices ? It could post a sample if i'm not clear enough
edit: I'll keep the question open for a while, so other can answer. Thanks Matt and Mick for awesome answers. I'm already working on some improvements. The major one being binding my controls after the page loaded.
It's expected on resource constrained devices that non trivial actions will take at least a little time to execute.
The most commonly recommended best practice for dealing with this is to use animations to give the user the impression of perceived performance. This has been a recurring recommendation throughout the CTP and Beta phases by the product team and in presentations at Mix 10 and Tech Ed 2010.
Page transitions are a common approach to this.
Discussed here by Kevin Marshall, prior to inclusion in the November toolkit.
WP7 – Page Transitions Sample
And here, referencing the control in the toolkit.
Transitions for Windows Phone 7
There are also a number of very basic optimisations you can do that will give you some bang for a little effort.
don't name controls that you don't reference in code
use background worker to load any data to avoid impact the UI thread (already busy loading your page) and fire this off after the page is loaded (disable any controls not usable in leui of this) (Phạm Tiểu Giao - Threads in WP7)
use httpwebrequest over webclient for the same reason (WebClient, HttpWebRequest and the UI Thread on Windows Phone 7)
I would also reiterate Matt's suggestion for not loading controls that aren't used initially.
If you decide to go the extra mile, there is more you can do to optimise page loading. These two posts are worth absorbing in that regard.
Creating High Performing Silverlight Applications for Windows Phone
WP7 Development Tips Part 1 - Kevin Marshall's Epic Work Blog for Awesome People
If using Listboxes, also familiarise with Oren Nachman and David Anson's
WP7 Silverlight Perf Demo 1: VirtualizingStackPanel vs. StackPanel as a ListBox ItemsPanel
Keep a low profile LowProfileImageLoader helps the Windows Phone 7 UI thread stay responsive by loading images in the background
Never do today what you can put off till tomorrow DeferredLoadListBox (and StackPanel) help Windows Phone 7 lists scroll smoothly and consistently
and be sure image sizes are optimised for their display size.
My suggestions/recommendations:
Create and navigate to the new page as quickly as possible.
Display the page with placeholder content while it loads (if appropriate).
Give an indication that something is happening while the page loads. An indeterminate progress bar (use this one) is the convention on the platform.
If it's not possible to use the page until all controls are loaded, then prevent access to the page. A semi-transparent object displayed over the entire page is a common technique to not only prevent touching of controls but also to indicate that they can't yet be touched.
If possible/practical set the size of the items in xaml/code to prevent relayout due to resizing once an item is loaded.
Try delay loading of items which aren't on the screen initially to get the perceived total load time down.
and finally:
Optimize everything to get the load time down and the application as responsive as possible.