I'm trying to find the source of some "idle" time within a certain page I'm accessing on our system. The problem is weird though to me, as I cant tell the reason for the delay. I'm running this in a single instance of chrome, no other tabs or anything.
The initial load time looks like this:
So it takes a while. But if I refresh this page within 7-8 seconds it will come back really quickly.
I initially though it was a system process on our end and ran Yii's profiler which came back with:
So, it seemed to be a non "system" issue, so went to Chrome's dev tools and the profile comes back with this:
I've read the other question What causes Chrome Timeline Frame to have so much empty white space also.
I'm trying to understanding if it's possible to identify the problem at all and why the page is rendered quickly if the page is refreshed after a few seconds of loading and why it takes so long if the refesh is called after 7-8 seconds of the initial load?
nb Some of the times might not match up as I've run the various profilers a few times. So they might apply to different page refreshes. But you can see the general trend :)
Related
NB: since the answer to this could involve JavaScript or PHP programming, or general networking, or IT systems, I put it here, but if some mod thinks it's better suited for SuperUser or ServerFault, I won't object to it being moved.
I have a landing page to which I'm driving traffic through PPC. I've set up AWS CloudWatch to get RUM data, and the page is performing terribly — an average load time of 9.9s and max of 21.5!
I've done all of the "standard" optimization I can think of or research. The site is built with WordPress, running on Apache on an EC2 server. I've
Upgraded the EC2 instance to ensure I have enough memory
Written a custom plugin to filter out any other plugins that aren't explicitly used on the landing page in question
Customised my theme code so that it sets proper srcset and creates the correct image sizes on upload
Minified all the JS and CSS that I include through plugins or themes I've written
Put the site itself as a distribution to CloudFront
Installed the WP Super Cache plugin, and created a separate CDN distribution on CloudFront for it
Set appropriate cache control headers on CloudFront and told it to gzip everything
Put a facade in place of any videos
The site is blazing fast for me — "load" is less than 1 second. But my RUM says that's not the case for my users. So, I dug a little deeper. 70.2% of my visitors use Chrome, and 27.7% use other, of which almost 1/3rd are Android Browser — which as I understand it is just some sort of "Chrome Lite" — so nearly 80% of my visitors are using some Chrome variant.
Sure enough — if I load the page on Safari (to ensure nothing has expired on CloudFront), clear my browser cache, and reload the page, the first request shows a waiting time of 21.2ms, TTFB of 22.6ms, and download time of 4.8ms. The whole page shows that it's finished loading in 973ms.
Firefox is slightly slower, with the first request taking 100ms total, and the whole load about 1.75s — not blazing fast, but still within the understood "2 second" limit for good user experience.
On the other hand, for Chrome that same first request takes almost 570ms waiting and 208ms download. So, just the first request (which is 36k in size) takes almost as long to load in Chrome as the whole site takes in Safari. And that repeats for every single request, where both the waiting time and the download time are an order of magnitude slower on Chrome than on Safari (on the same device on the same network):
Whereas on Safari:
I would think "waiting" and "download" times would be primarily network driven, but I can repeat this all day long and the results are the same.
I might just assume that Chrome is not optimized for the Mac on which I'm running it, but, as I said, this all started with RUM data, so it's clearly not that. As much as I might like to, I obviously can't force all of my visitors to swap their Android devices for iPhones. Equally obviously, I can't have an average load time of 10 seconds.
So, why is my site so slow on Chrome? What else can I do to optimize this?
The landing page in question is here: https://www.chrisrichardson.info/lp/prague-b/
Note, a lot of the optimization I've done is for that page in particular, so other pages on the site might perform even worse, but I don't care about that, at least at the moment.
Hahahaha.
OK, just leaving this here for posterity's sake. The 10x latency was because Chrome had preserved in devtools from a previous session throttling to 3G. So, if you stumble upon this problem, check your throttling.
That still doesn't address my RUM issue, however, but I'll open that up as a different question.
I cope with a problem on a vuejs SPA application. Basically I have a page with a lot of components, and when I click a link that changes the route (either with or this.$router.push), there's a very slow destroy time, before it reloads the components.
Here is the app structure (it's a grid with rows and cells) :
<MainComponent>
<RowComponent v-for="n">
<CellComponent v-for="p"></CellComponent>
</RowComponent>
</MainComponent>
The time is not that huge when I have a low number of row, but when I have more than 100 rows, it take ~3 seconds to destroy (I took the measure with the beforeDestroy and destroy), which is the sum of all CellComponent (each component take few milliseconds to destroy).
For example, it take 3 seconds when I have 111 rows and 5 columns (so 555 cells in total).
The thing is that on Brave, Firefox and Safari, it works perfectly and does not take time.
Sometimes, with Chrome and Edge Chromium the problem disappear after few tests but if we restart the browser, the problem comes back.
At first, we thought it was Segment Analytics, but disabling it does not help. I also tried to disable all external services request (with blocking request feature in Chrome). Also the problem.
Then, we try the UBlock extension, and the problem disappeared when the extension was active. We tried a lot of test to identify which setting in UBlock can help, and we found out that it's the "Peter Lowe’s Ad and tracking server list" (https://pgl.yoyo.org/adservers/) setting that solve my problem.
So i can't understand what this setting does more than just blocking request to ads' servers. I tried to block all the requests from "Peter Lowe’s Ad and tracking server list" directly in my /etc/hosts, but I still have the problem on Chrome.
Does someone already dealt with such a problem ?
Okay, I'm trying to detect a reason for a slow loading of a website page using network tab in chrome devtools. In my past experience there always were some large files or slow links to 3rd party sources, but now I'm in total confusion because for a large amount of time there is no downloads at all:
screenshot of network tab
What is also strange is than for a last second there is a file with a size less than 1 kilobyte and it's loading for half of a second, although it's not a main issue here.
Try using the Performance panel instead. My guess is that your page is running a lot of JavaScript during the "large chunk of no activity".
Open the Performance panel and click Reload.
If you see a wall of yellow activity in the CPU chart, it means that your CPU was completely busy running JavaScript.
(source: google.com)
The Audits panel is the best tool in DevTools for learning how to improve your page load speed. It runs a bunch of tests on whatever page you've got open and gives you tips on how to speed up the page. Check out Optimize Website Speed.
I've been using Google Chrome to visit a website that I manage. The website loads every day without problem as expected. I refresh, it loads fine again, and over and over. But then occasionally, with absolutely no other external input or changes, I will refresh the webpage and randomly Chrome will not load the website under any circumstances. The tab sits with the spinning wheel forever, and the bottom simply says "Waiting on www.mywebsite.com..." ...forever. The site can work for a couple days without incident, but then seconds after it works, it stops.
Let's say I have two tabs open, and one of them is MyWebsite and that tab freezes in this manner. If I'm on google.com in the second tab tab, and I type in mywebsite.com, it will remain on the Google.com page, but show the "waiting for MyWebsite.com..." status update on the bottom endlessly. We've left it for hours before. It's like it gets stuck just requesting the website.
THEN if I wait an arbitrary period of time, usually less than an hour but always longer than about 20 minutes with no other changes, and I refresh or try in a new tab, the website will rapidly load as though nothing has happened.
I'm using the latest version of Chrome, 46.0.2490.86 (64-bit), and on the latest Mac OSX El Capitan 10.11.1
Here's what I've tried:
1) I've been able to verify that it is NOT the website. The website WILL load without incident on Firefox, Safari, mobile browsers, et al while it will not load in Chrome. Additionally, while Chrome is stuck in "waiting for website", pinging, tracert, and website availability tests all show it functional. And I should point out again that the website will work on Chrome all the time, all day, and even for 24 hours, but then the exact same page (it's indiscriminate about WHICH page it freezes on) that loaded sometimes literally 5 seconds ago, will freeze indefinitely.
2) I have no extensions running on Chrome of any kind.
3) I went to google://net-internals -> Socket and flushed all sockets and it makes no difference.
4) A hard refresh makes no difference.
5) This happens at random intervals. The website will load and refresh fine for hours. Then one time, it simply freezes. When it does this, closing the tab and opening a new one makes no difference. Flushing the cache makes no difference. No matter what, if you type in mywebsite.com, it will not load a single element of the site and instead simply do nothing but say waiting for website. We've been absolutely unable to see any pattern as to when it simply stops.
6) I am unable to verify if this happens with other websites, because I do not use other website nearly as frequently, and since the problem is random, it's hard to replicate for another site.
7) Shutting down Chrome entirely and turning it back on makes no difference.
8) This does seem to happen when I'm refreshing the site a lot. Let's say I made a minor css change, or it's a busy day and I've refreshed several times in the last 30 minutes to retrieve the latest ecommerce orders, it tends to happen with more frequency. So my suspicion is something having to do with the cache (though again, clearing the cache doesn't make a difference).
When this happens, usually no code has been changed on the back end, nothing has to have changed about the website itself whatsoever. It's been doing this for weeks and weeks.
Can anyone shine some light on this situation? It's incredibly frustrating.
I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.