We are rebuilding an existing JSP web application using AngularJS. In our existing application we use the page load time metrics extensively.
With the SPA there are no real page load times. How can we track user experience of performance through GA in this scenario?
If you want to know how long something takes you can use User Timings - this somewhat resembles event tracking, only you pass a duration as value parameter (i.e. you need to start a timer when your thing starts, stop if when it's ready and the time measured is the value for the user timing):
ga('send', {
hitType: 'timing',
timingCategory: 'SPA Content change',
timingVar: 'load',
timingValue: 100
});
Related
I have a web application which uses angular 1.5 with Typescripts. Angular will call web api. The api uses Entity framework. Now I want to measure the performance of the page for various events like page load, button click etc.
Is there any tool available which can provide information for time taken to execute controller action, time taken by entity framework etc?
I want tool which can provide aggregated information when page is loaded or I click on any button.
I am fine even if there are tools which can provide above information separately.
Did you try Chrome DevTools? you should check these links: the timeline tool and analyze runtime performance.
In short: you should open the Developer tools, go to profiles and start a recording, then you perform the actions you want to measure (e.g. click a button) and stop the recording. You will see how long each of the method calls take. Here a how to on how to do recordings and a couple of tips.
There are also other options like Firebug.
There are few tools which allows to analysis your code, watcher and digest cycle. You can also use Timeline tool in Chrome.
https://chrome.google.com/webstore/detail/angular-performance/hejbpbhdhhchmmcgmccpnngfedalkmkm?utm_source=chrome-app-launcher-info-dialog
https://augury.angular.io/
There are a couple performance indicators in angular applications:
For example you can measure the digest cycle time:
$timeout(() => {
angular.element(document).injector().invoke(() => {
let start = performance.now();
$rootScope.$apply();
console.log(performance.now() - start);
});
});
I had the idea to make a SPA application using angularJS and then just sending AJAX updates to the server when I need.
My initial idea would be make the client application fly, but if I have to do an AJAX round trip to the server, I think the time would be approximately the same as to request a single web page.
Requesting a page just has more bytes of data, is not like I'm requesting 20 resources like in this article: https://community.compuwareapm.com/community/display/PUB/Best+Practices+on+Network+Requests+and+Roundtrips
I would be requesting a page or resource per request.
So in the end even if I create my client side application as a SPA using angularJS, these requests (would have to be synchronous and show a please wait message while they don't return, as I don't want to user to take more actions before I make sure his request passes validation and is processed correctly) would take some time and make user wait, just about the same time as requesting a full page.
I think SPA pages would be very useful if I have like a wizard on my app with multiple pages/steps and at the end, submit the results of wizard, to the server, which I don't.
Also found this article:
https://help.optimizely.com/hc/en-us/articles/203326524-AngularJS-Backbone-js-and-other-Single-Page-Applications
One of the biggest advantages of Single Page Apps is that they reduce
data transfer. As a result, pages after the initial loading usually
can be displayed faster and seem more interactive.
But I don't believe this last quote is really true.
Am I right, or is there a way that I'm not seeing to build an application that would look like it's executing locally?
I know how guys will start saying "depends on what you want", but lets focus on this scenario where there's no wizards.
What ever you said is right. But most of the frameworks(Angular,BackBone) you take they are going to cache the templates of html on the browser so the rendering would be pretty fast compared to the normal applications. Traditional apps will have to fetch the html from the server for each request which is a time consuming one.
Hope this helps you!!!
If you are wanting to go through that syncronous server side validation step for each page request, then there is probably no big advantage to using AngularJS.
If you are requesting a page and then manipulating that page's contents once it's loaded you might want to consider AngularJS. A good example would be requesting a page that displays a list of items. Now let's say we want to search that list or order it in different ways. Rather than using AJAX to call the server to filter the list and then re-render it, it could be much faster to user AngularJS to filter and re-render the list without making any further requests to the server.
I am relatively new to AngularJS.
A current usecase I am working on involves running a function every N seconds, as long as the user has the browser window open. This background service must not in itself interfere with the rest of the app.
What is the preferred way to do this in AngularJS?
Use $interval as mentioned by #dustyrockpyle.
Note that using a regular setInterval with AngularJS is usually not a good idea, as Angular won't automatically notice any changes made.
Well, as technology progresses, issues we solved long ago crop up again.
Back in the dark ages, when PHP and ASP were considered awesome, we always had a problem with view states. If you had a page with say a dozen select combo boxes on it, your user chooses some combination and hits next, then realizes they screwed up and hit the back button on the browser, the combo boxes would be back in the default state, usually with option[0] selected. In order to prevent this, we had to write boatloads of boilerplate code that would save the state of those combo boxes to a cookie, or session variable, or something so that when the user hits the back button, we can reload the combo boxes back to the state they were in when they left.
This problem was compounded even further if you had a datagrid on the screen. Because then you would have to come up with some slick way of saving that grid somewhere to prevent from having to hit the database again.
Then came the light. Browser developers realized that most web developers were on the verge of going back to writing terminal programs in Cobol due to this issue and added UI caching to the browsers. This allowed us webdevs to not have to worry about this anymore except in odd situations.
So, life was good. Then someone came up with the bright idea of trying to replicate GWT without all the hassle and the web explodes with all these javascript frameworks. The one im dealing with specifically at the moment is AngularJS 1.2.10 with Angular-UI. I have until Friday (most likely wednesday tho) to make an initial assessment on if this technology is a viable alternative to our current standard (thats pretty much universally hated) JSF.
So, i follow some guides, pound my head against the desk a few times, and I have an angular app with 3 actual HTML pages, each HTML page with 2 views.
Before you go there, understand we can't use it unless we can do multi-page JS apps. Some of the applications that this will be worked into have been in development for a decade or more and its simply not financially practical to scrap an the entire UI and start over again. We would instead be doing things like taking these 50 struts pages and converting them to angular/rest and linking them seamlessly back into the remaining 800 struts pages of the application.
So in my exercise of playing with this, I encounter my old nemesis. Back button view state issues.
I have been playing with the UI-route system. The fact that I can deep link using the route system solves part of my problems. But, if say I have a search page like this:
view-search
combo: search type [member,nonmember]
combo: result type [detail,summary]
combo: search state {all the states]
textbox: contract number
etc etc etc
And various combinations of combo box selections and text entries comes up with a list of 1000 people. Now the user selects one of those people on the data grid and it takes you to view-detail. Well the fact that you can use routing to do something like index.html#detail/bob is cool, but if the user realizes thats the wrong bob and hits the back button, they get a blank search screen again and they have to enter everything over and worse yet, send another search to the database to rebuild the datagrid. Some of these screens have 50 or more options to choose from when searching for data so trying to put all of them into the URL routing sounds completely impractical to me.
Now in my research I found this post:
Preserve state with Angular UI-Router
And that has promise mainly because I have a view state object that I can store into a Redis database or a session EJB for cases when the user actually jumps out of angular and into the legacy Struts application, then back buttons back into the angular application, but the fact still remains that on some of these pages, that is a huge amount of boilerplate code that we would have to write in order to make it work.
I don't really mind the idea of having to manually save off the view state object and read it back in from a Redis server or something anytime a user enters or leaves an HTML page in the system. What i'm really looking for is a way to automatically generate the object that is to be saved without having to write volumes of boiler code.
Is this possible? I keep reading the ui-route documentation but it doesn't look like this is addressed, at least not that i've translated yet.
If this is possible, what controls should I be looking at?
thanks
-------------- Edit
I just thought of something. There is one central scope to each of the single page applications. (Im basically going to be building a multiple single page apps and hooking them together) So if i use a naming convention, something like this
$scope.viewstate.view-search.searchType
$scope.viewstate.view-search.resultType
$scope.viewstate.view-search.searchState
Then the viewstate object should simply be a js array and when I create a function to move to struts.do, i can simply save that array off to the Redis server as a nested map object. Then when my user back buttons back into the angular app, i can capture that using the route system and retrieve that viewstate object from Redis and insert it back into my scope, thereby rebuilding the scope for the entire single page app in one shot.
Would that work?
I believe that you have a very complicated issue of trying to keep the view states between your varying pages with the amount of data in your pages. I think that the only real effective way to do this is to write an angular service that you can then pass to your various pages. as You already know the service is a singleton that you can use in various controllers and could be utilized to maintain the view state as you described. here take a look that this link and see if it will help: http://txt.fliglio.com/2013/05/angularjs-state-management-with-ui-router/
After some thought what you suggest in your edit might work, but I would still use a service to retrieve that array of data, as it would make it easier to reinsert in to angular scope
I am exploring something similar for an Angular app that I am writing. Keeping a user login during a page refresh is easy. Displaying the state on the page after a refresh is an entirely different problem.
How long must the state be persisted? I'm evaluating two possibilities.
First, saving the state (current form values or whatever) to the database. As the page changes, incrementally save the state to the database. On a browser refresh check the database for saved values.
Second is to use local browser storage. This is 5 megs of storage. 5 megs is a lot of text. Again this data would incrementally be saved into storage. When the browser refreshed, simply load data from localStorage.
How are single-page apps (SPAs) supposed to be faster when generally SPAs have to make multiple requests to get data for different parts on the page? As opposed to rendering server side, where the browser only has to make a single request to get the whole page?
I also remember reading somewhere that opening/closing a web request is the bottleneck sometimes in web requests.
So why does an approach that makes more requests per page is supposed to make web sites faster?
Because you only load what you need.
For example, on a "normal" web page, the menu, sidebar, etc. would have to be rerendered on each page, but with an SPA only the content gets changed.
In addition, think of this case: A website that displays 100,000 items on the front page (with pictures). In the traditional case, it will take a long time to load the page, but with an SPA you only load the "first screen" (i.e. what the user can see), and load the rest as he scrolls down.
In other words, SPAs aren't magic: it's just that they only need to update the bits of the page that change, which makes the response time lower for users (i.e. they can "use" the new contact faster).
If well done, they are faster because:
Part of the server workload is offset to the client.
Only the needed page fragments are loaded at any given time.
Redundant templating code is reduced. One template can style many items, as opposed to having to output a lot of HTML for a full page at once.
They also facilitate lazy loading and the download of new data during idle times, and parallelism: the concurrent downloads of elements.
Usually SPA are built with a lazy mode approach: get the info only when you need it and if you need it.
Also usually the data coming to and from the spa is in a format (json for example) which focuses on the data only. The presentation layer is a concern of the SPA and all the required assets should be already loaded.
So usually they are faster and more maintainable.
It is not always the case though.