One of our web pages has a rendering performance issue, when the page is open, the spinner is freeze or loading very laggy, and after 6-12 seconds the page completes loading. So i'm using the Network's waterfall in chrome dev tool to diagnose the issue. But I got a few scenarios which i don't understand what happened.
In the following screenshots, all the resources for the corresponding page are loaded in a very short time, but the spinner is freeze for 6 seconds or 9 seconds, i'm not sure what is happening after the resources are loaded and before the page completes loading, maybe the spinner is in a wrong thread or gets blocked somehow? What is the means that i should use to find out the cause?
Scenario 1
Scenario 2
UPDATE
Network Screenshot
Timeline Screenshot
UPDATE
After checking the Event Log, i think the issue happens at Angular digest cycle, that endpoint response time should still be 780ms.
Thanks for the detailed info. It'd be more helpful if you can link to the page, but I understand that's often not possible. I'll just provide some general data for people in the same boat. I don't know if I'll be able to completely answer this specific question, though.
In the Scenario 1 and Scenario 2 screenshots you can see that your resources are loading in 1 or 2 seconds. That's your cue that the issue isn't related to the Network.
So while this is a page load issue, it has nothing to do with the network.
In Timeline Screenshot you can see that your CPU usage is completely maxed out from about 1900ms to beyond 16000ms. So your page is forcing the browser to do a tremendous amount of work. This is probably in the JavaScript.
To diagnose this, I'd investigate the flame chart (under Main) which you can see in Timeline Screenshot. The longer the bar, the longer that function is taking to complete. Or, if you see a small function getting called thousands of times, that could be the cause. If you can optimize those calls, then you can get your page visually loaded faster. You can click Self Time header in the UPDATE screenshot to rank the function calls according to which took the most time.
Again, I don't know how helpful this answer is for this particular question, but I thought I'd try to rephrase the problem in a different, more general way.
Related
I'm using Lighthouse to measure the performance of a web page. The problem is that the results I get are not consistent between the runs.
In ~80% of cases the Lighthouse comes to the conclusion that the page has finished to load seconds before it has (and I can see the whole page rendered). The results are about 90! The resulting screenshots indeed show the loading animation I have on the page
In ~20% of cases Lighthouse is patient enough and waits for the page to load fully. The results of course are around 40. But I can see in the screenshots that the loading animation is replaced with the real content of the page.
I want to understand how to consistently reproduce the proper (2nd case) behaviour of the Lighthouse - can't understand what does it use as a trigger to stop the measurement.
Any ideas?
I've been doing some refactoring on a slow running web application, and managed to reduce the number of requests and the size of the downloads to help improve the situation. Now the loading time is consistently shorter. However, consistently before there was hardly any time elapsed before the last 2 requests. Now consistently there is a gap.
Q1: What do these 'gaps' indicate in Chrome Network view?
Q2: Looking at the screenshots, the DOMContentLoaded time vs. the overall Finish time, are there any conclusions I can draw that could help me optimise further?
Record the page load in the Performance panel. See Get Started With Analyzing Runtime Performance to get the gist of how to use the panel. Understanding the network bottleneck can also help get you oriented.
However, you'll want to press the Reload page button (like Sam does in the "understanding the network bottleneck" video) instead of the Record button to record the page load performance, as the "get started with analyzing runtime performance" instructs you to do.
Once you've got a recording, the Main section shows you all of the main thread activity that occurs while the page is loading. The Network section shows you all of the Network requests. You'll probably be able to visually verify that there's a bunch of JavaScript work going on during the gap that you're seeing in your screenshots.
If it's still not clear to you, post a screenshot of your Performance panel recording and I'll help you decode the results.
My page load times have been wildly fluctuating, and sometimes it takes so long to serve a page that I get a server timed out error, even during relatively quiet times of day for my site.
I have been using pingdom to check page load times and to try and find where the problem lies.
It seems when a page loads normally (in approx 6 seconds), there is a 1.63 second 'Wait' Time for the main html file, before it starts receiving the file.
You can see this here:
http://tools.pingdom.com/fpt/#!/GEoqJlVdZ/http://www.bluedogposters.com.au/shopdisplayproducts.asp?id=11&cat=Movies
But 2 minutes later, when the same page is taking 17 seconds to load, there is an 11.7 second Wait Time before starting to receive this same html file.
You can see an example here:
http://tools.pingdom.com/fpt/#!/he2L5Jhgz/http://www.bluedogposters.com.au/shopdisplayproducts.asp?id=11&cat=Movies
Do you know what can cause this difference in the Wait times because it seems this is the reason my site has been so slow recently.
Accoring to the Waterfall chart, there is nothing else happening, so why the Wait?
Is it more likely to be a code or server issue?
I found some useful info here How to reduce server "Wait" time?
Any advice is much appreciated.
You need a tool that can dig into the backend performance, something like New Relic might help - they do a free month trial.
There's obviously some variation in performance going on but whether it's related to load or other factors is really hard to discern without digging deeply.
You should try new relic anyway, it will still give you a good answer even on an ASP classic site. I have used it on windows servers before to figure out why an app was running slow.
I got this website: All things I like and up until recently it was working perfectly. But suddenly it needs 20 seconds to load - I haven't touched the code in that time.
What could be the cause of this? 20 seconds is really long time.
I am using FBML implementation and not IFrame.
Have you checked it on firebug
Well i checked and your total load time was 28.9 seconds. And most noticeable amount of time was spend on waiting for resources (for Fans and likes boxes) from static.ak.fbcdn.net and then getting them.
So there seem to be no problem from your site its the Facebook Server thats taking time in fetching the data and sending it back to your page.
You can still optimize your own resources like backgrounds ets.. i notice a big 100x200 image for header
Super slow with facebook is annoying!
I stumbled across this page looking for a solution - the only one i cant think of (and hence, the one i'm going to enact) is to pre-size the div that the fb stuff will appear in. Page will still load slow, but won't readjust itself after 10 seconds!
To be clear, this is for a normal iPhone application, and not a game.
I've read around the web a few times some developers mentioning that they were working hard to improve/reduce the startup time of their applications, but never with any good background information on how to do so.
So the question is simple: how can you reduce the startup of iPhone applications?
Same as any other performance issue: Use Shark and/or Instruments to identify bottlenecks in your code, and then focus on how you can speed things up there. Each tool will give you a picture of how much time was spent in what parts of your code, so the general scheme would be to run the tool while you start the app and then pore over the data to see where the performance hits occur.
At app startup time, the most likely candidates for improvement will be deferring data loading until later on when it's actually needed, variously described as "on demand" or "lazy" loading. Essentially, don't load any data at app startup unless it's actually needed right away when the app loads. In practice, lots of stuff that may be needed at some point doesn't have to be immediately available when the app starts. For example, if you have a database of N records but only one is visible at a time, don't load all N into memory at app startup time. Load whatever the current record is and then load the others when you actually need them.
James Thomson did a nice blog post documenting his efforts to make PCalc launch faster.
Of particular interest is his use of image with screenshot from last app run, to pull the same trick Default.png does, while loading rest of the app.