My angular app runs terribly slow in mobile so I carried a test and found out that the javascript execution time (after the bundle.js gets loaded) is the main bottle neck. There's a huge difference in them between desktop to that on a mobile.
What might be causing the problem and what might be the possible solutions?
Test for desktop
Test for mobile(Moto G)
You can see the JS Execution time is denoted by the purple bar.
Please have a look at the page speed suggestions by Google for your site.
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Faiesec.org&tab=mobile
Try to make the changes mentioned and test again to see if it makes it any better.
Move the render blocking js to the footer. That's the one thing I noticed when checked the source from my mobile.
Please have a look at the below question
How can I improve load performance of Angular2 apps?
I have seen the initial slow issue on many angular apps even though they have been optimized with production build. Please have a look at that it may help.
Related
We use PhantomJs 2.0 to take screenshots of web pages. We've found that one particular page takes several minutes to process. This page does not appear to have this issue (or at least not of any comparable magnitude) when loaded in Chrome.
I believe that this is because the javascript is hanging/running very slowly. During the hang, Phantom is using a lot of CPU (although only one core). It does not appear to be taking up an abnormal amount of memory. I am fairly confident that javascript is the culprit because I can see from logging that all requests complete quickly, but then after the page loads Phantom hangs for awhile and won't run anything (I think this is because Phantom is all single-threaded so if the page is still running javascript my Phantom script won't run anything).
I'd like to debug and try to understand what part of the JS is taking so long, but I can't figure out how to get at this in Phantom. For example, I can't seem to collect any output from console.profile/console.profileEnd. How can I profile the javascript running in Phantom to find the bottleneck?
I use Phantomas, via grunt-phantomas. It's a tool that integrates with PhantomJS to profile a wide variety of performance-related metrics. Definitely worth checking out. If it doesn't give you exactly what you need, you can look at the source and see how they integrate with PhantomJS and get data out.
I'm looking for help to automate performance test of my single page angular application. We are using protractor for E2E tests and would like to add performance tests. Our first target is to be able to measure simple timings between e.g. Button Click and finish of loading of a svg. (We have requirements that state that the load time must be less than 2 secs. So we need to assert those things.)
My first idea was to use browser-perf/ protractor-perf. Unfortunately, protractor-perf doesn't seem to work with the latest chrome version and in general browser-perf is just measuring page load times which wont change on a single page application.
My latest idea is to simply use performance.now() and measure the times 'manually'. This has the big disadvantage that it is not supported on iOS Safari. ( I need the tests to run on iPad, too.)
So my question is: Is there someone who has a good idea how I can include performance measurements into my protractor tests, measuring time intervals like the one I mentioned above?
The latest version of browser-perf now works with the latest version of Chrome. You should simply reinstall protractor-perf and it should start working. This was fixed recently - https://github.com/axemclion/browser-perf/issues/31.
Also note that browser-perf also measures things like framerates, area painted, etc, which may be useful for single page apps.
Is there a way to slow down browser DOM rendering and JS execution for development so we can see which parts of the website are too JS intensive and might be slow on slower machines? Maybe an extension for Chrome/Firefox for Linux/OSX?
Some clarification:
It's not about connection or testing the speed of the browser! It's just for our developers to see which parts of the page are rendered slowly or are "glitchy". For example when you use ajax and you are loading something you show a loader, but just after the loader is shown the loaded part is shown too. We want to see that in slow motion. Like when you press SHIFT in OSX when doing Expose.
PS. I did find some articles on delaying Internet connection, but that's not enough in this case.
PPS. Loading everything in VMs didn't work for us.
PPPS. Using slow down code like proposed in Javascript code for making my browser slow down is not the best option in my opinion.
Converting what #z0r said in the comments to an answer:
In Chrome, open devtools and select the Performance tab
Make sure Screenshots is checked
Press the record button (or hit Ctrl + E)
Do your activity
Stop recording
Hover over the timeline to see the screenshots of the screen as things change.
Use the timeline or profiler on your browser inspector. Here you can see, what functions take down the speed.
The accepted answer is good; I use and recommend Chrome Dev Tools as well.
As an alternative to Chrome Dev Tools:
Several 'website performance analysis' services offer timeline views. Run some internet searches and you'll find various free and paid options.
Try webpagetest.org
It's open source, highly regarded and has been running for years. It may offer different information, or is accessible in a different way, than Chrome Dev Tools.
In the test results, click "Filmstrip View".
The project I'm working on involves a "planning" screen, which is entirely made with backbone.js (the other pages of the app are not).
My issue is that from times to times, chrome freezes and the web view stop responding to any interaction. Sometimes, I can manage to quit chrome itself, but usually the controls does not answer either.
I'm pretty convinced this is related to the js code. It seems to me that when a script takes too much time, or loops indefinitely, Chrome can detect this and interrupt the script. However, since this is not the case, I'm thinking that too many js objects stay in memory.
Whatever the cause is, I would like to know which chrome dev tools can help me here. While I'm not a beginner in js, asides setting breakpoints and calling console.log, I have no idea how to debug JS apps. I'm not opposed to use another browser if the dev tools are more suited.
Thanks a lot for your time !
FTR : This is a rails 3.2.8 app, using mongodb, & Backbone.js 0.9.2. The js code is written in coffeescript. This issue happened on my macbook air 2012 running mountain lion, as well as on the client machine which runs on windows 7. The issue appeared at least on chrome 22 & 23.
Using the Javascript CPU profiler, I was able to find the group of functions that seems to be responsible for the freezing.
I'm still open to any advice/ressource on debugging javascript code.
Make a console.log in the loop and check if its the same point freezing on all chrome versions. There is a limit see Browser Javascript Stack size limit.
Maybe add some code? Because there could be some memory leaks especially with event handlers!
What I would do is the long and weary approach to getting your hands dirty with console.log. --- in this case.
In your case, and THX for the hint by the way (finding the offender with the CPU profiler, I'll try that next time round), I guess the offenders might be some functions "callbacking" themselves .. probably via some sort of event-handling/bubbling/callback-combination.
What happens then usually is that it just doesn't recognize the endless-loop, because the callback-stack is kinda "broken". Therefor it will never throw a browser-error.
If you have any luck, it doesn't kill the browser quick enough to kill the console. I did have that at times, the console killed (remaining silent), the coffeescript files not even loaded in the debugger (I use a JIT-coffee-to-js-translator as in JS-MVC) ... the page frozen or not doing anything ...
So, if indeed you are lucky and the debugger spits out your console.logs you can thereby guess where your unwanted loop is hiding. Just by looking at the repeated order of the output statements.
of course you know you can set breakpoints right? even conditional breakpoints
I'm currently struggling a bit untangling a similar sounding loop - i guess in case of emergency some alert() calls in your code would at least slow the loop down
or maybe some wait calls (bad idea)
my loop is running so fast I loose my console log!
After an hour or two of heavy use on the site I'm developing, Firebug develops the following problems:
Breakpoints get glitchy -- it becomes difficult to add/remove breakpoints. Sometimes I click on a line multiple times, see nothing, move to the console tab and back, and then see my breakpoints again.
Console stops logging xhr's, or stops logging debug statements.
Script files become non-viewable.
I'm working with a javascript file which is quite large (over 10k lines). I don't think this is a memory leak issue with my own code. I'm refreshing the page all the time. Looks like an issue on the Firebug side. Is my logic sound? Is there anything I can do to get firebug to behave better? Or do I just need to restart firefox every hour?
Keep in mind Firefox while wonderful has always had many issues with handling memory. You should take a look at your task manager to see Firefox's memory footprint. Additionally I'd break up that JS file if you could into smaller chunks (for many reasons aside of this as well) to be better readable and work with the segments. Finally turn off plugins your not using or that may conflict with Friebug if your not using them.
I spent hours using Firebug without restart Firefox and never crashed, try a clean profile, install on it only Firebug and check if all works fine.
I use a separated development profile with Firebug and other dev oriented extensions installed.
How to configure a profile is described in many sites, on my wiki you find a brief description
i have similar problems! i think it is partially to do with the massive JS files. I just re-start firefox every once and a while. no big deal.