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.
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?
In the Chrome browser's developer tools, there are various ways to throttle your network connection to emulate different connection types.
Those menus for selecting a connection type used to show the speeds and latency that would be used to simulate each connection type.
Now, as of at least Chrome 64, the useful information about speed and latency has been removed.
I tried duplicating the numbers from the first image for Regular 3G and Good 3G in my own custom profiles to see if they matched the Slow 3G and Fast 3G presets from the first image but I got significantly different results for the DOMContentLoaded and Load event times between the presets and my custom profiles.
DevTools tech writer and developer advocate here. The history behind the change is that DevTools now tries to emulate the real conditions of what a fast 3G network really feels like. Previously, DevTools showed you upload / download / RTT values, as you have shown in your screenshot of the old UI. But those values were misleading. They may be technically correct, but when DevTools was benchmarked against other throttling tools, DevTools didn't throttle enough. E.g. if you loaded a page with tool A that throttles for 3G, and then loaded that same page with DevTools (also throttling for 3G), the page loaded faster with DevTools.
So DevTools doesn't show the exact values anymore, but if you measure the load performance of DevTools against other throttling tools, you can see that they all perform similarly now.
The reason that DevTools doesn't show values anymore is that they don't map to reality well. For example, maybe you look up that a certain connection speed is defined as X download rate, Y upload rate, and Z RTT rate. So you put those values into DevTools. Those values aren't going to approximate the real-world conditions well. DevTools is going to load faster than the real-world experience. It's better to benchmark how a certain page really loads on that connection, and then tweak the input values until DevTools loads your benchmark page at around the same amount of time as your real-world benchmark.
Of course, another approach would be to get a Chrome engineer to tweak Chrome's throttling engine so that the values you input actually do map to reality well. But for whatever reason, that's not happening.
Since it's possible to add custom throttles, I'm aware that we need to update the DevTools UI to explain this limitation. In other words, when you create custom throttles, you should benchmark a page and then tweak DevTools inputs until it matches the benchmark, rather than relying on the values.
Hope that makes sense.
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.
Can anybody help me understand what the following is telling me in Chrome Dev Tools on the Network tab Timeline? Specifically, what does the gap mean?
During this terribly slow page load the resources display some info on how they are loading up until ~7 seconds or so. This is followed by a large gap. And then near ~13 seconds there is info on the resources loading again.
I've truncated the full list of resources, but the only resource bar that spans the gap, is the first resource for the primary page. It it identifies what is happening in the gap as “Content Download” (the blue bar):
The total resources on the page appear to be around 2.5MB in size. In this example, the DOMContentLoaded and Load events are taking place at the same time near the ~13 second mark.
Chrome starts loading external resources like images or scripts before the page HTML download has finished.
For example, here I've got an image at the top of the page, and then further down in the middle of the HTML a script tag.
This also means that the Load event follows quickly after DOMContentLoaded, because Chrome has already fetched the additional resources.
In your case, there's some JavaScript code that waits for either one of those events and then triggers additional requests.
The reason for the initial 13s load time is that after the waiting time of ~4s it takes another 9s to actually download the whole document.
This could be because the browser's internet connection is poor, or because the server takes a long time to generate the response, or because the server doesn't have enough bandwidth.
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.