We Keep Coding

Chrome hangs for 15s+, no clues in DevTools — how can I debug this?

One page on a client's site causes Chrome to hang unresponsively for 15 seconds or so. On macOS, the browser locks up completely and the spinning wheel appears.
There are no issues whatsoever in Safari or Firefox. I have no idea why this is happening, and DevTools doesn't seem to give any clues as to what's causing it.
Here's a screenshot of the timeline — note the flurry of activity in the final second, when the browser becomes responsive after seemingly doing "nothing" in the latter half:
Some comments on the timeline above:
At ~12,500ms the page looks ready. In any other browser, it is ready for interaction at this point. You can see the final green chunk in the timeline finishes around here.
Chrome completely locks up between 12,500ms and 28,500ms.
I initially assumed the problem was with one of the 3rd-party/analytics scripts, as you can see the timeline shows activity from these right in the final second (> 28,000ms). I tried switching every one of these off, but exactly the same thing happens.
This is a particularly large page, as it lists several thousand records in a JS datatable. I appreciate performance can be improved, but I don't believe that's the root cause. The page/plugin has been working absolutely fine for several years.
What can I try next? Thanks! 🙏

This turned out to be a bug in Google Chrome v107. Updating to v108 fixed the issue immediately.

SpeechSynthesis.speak (in Web Speech API) always stops after a few seconds in Google Chrome

When using the speak function in the Web Speech API, in Chrome the speaking stops abruptly after a few seconds, in the middle of the text given to it, in a seemingly random place (without reaching the end).
This only happens in Chrome (works well on Firefox), tested on two different computers/systems.
Have a look at this jsfiddle to see/listen:
https://jsfiddle.net/fv9ochpq/
You can see that the SpeechSynthesis object .speaking flag stays on(true) after it stops speaking.
I haven't seen any documented limit to the text passed to the utterance.
Is this a Google Chrome bug?
BTW, I've known about this since 2014 - when I was trying to add a speech feature to a browser extension I made (back then it was the TTS API available to chrome extensions - same thing happened there as well), but eventually didn't do it because of this apparent bug.
Now I want to overcome this - if this is a bug, I will appreciate anyone directing me to the best place to report it.
EDIT: It seem to stop after about 15 seconds. Adding an interval every 14 seconds running .resume() seem to "fix" this. See: https://jsfiddle.net/fv9ochpq/1/
But this is a hack.
AUGUST 2019 UPDATE Since December 2018 - Chrome does not allow triggering speech without user interaction, this is an updated jsfiddle, with an added button, and the actual speak call moved to its onclick:
https://jsfiddle.net/vcmxkwd3/
THE BUG IS STILL HAPPENING! :

You asked where to report this problem. For programmers, I think this forum is the best place. In fact considerable discussion has occurred at Chrome Speech Synthesis with longer texts. But I believe much of it mistakenly focuses on the number of words allowed by SpeechSynthesis rather than on duration has you do here. In fact, your solution seems to me the most practical of all.
Google has a bug reporting facility, and the issue has been reported as speechSynthesis fails for long text without warning and blocks the API. It currently has a total of 3 reports, which give it 3 "stars." We may be able to bring attention to the issue by adding reports to this Chromium Bug (I have added one).
Current status of this Bug is "Untriaged;" also of interest are several other reported issues related to Chrome SpeechSynthesis.

Angular 2 Application reacting very slowly only while Chrome DevTools is open

My Angular 2 Application is slow to respond (1-5 seconds) to key input, button clicks, tabbing across inputs, etc. only when Chrome Developer Tools is open. Material 2 animations also become slow and choppy.
I've been developing this application for three months, and use Chrome DevTools every day. This issue cropped up seemingly overnight.
What I know:
I stashed all pending application changes to revert my application to a time when this was not a problem. The issue persisted.
Chrome DevTools doesn't seem to slow down any other application (ie. google inbox, google maps) in the same browser session.
Maddeningly, when I run the DevTools' Timeline "Record" to try to gain visibility into the issue, the issue disappears and the page reacts at normal speed again! I assume this is the best clue that I have, but I don't know the internal workings of DevTools well enough to know how "Timeline Record" changes things.
I've restarted Chrome and deleted all cached data.
Nothing of the sort happens in Firefox or IE when I open the Developer tools in those.
Any recommendations on where to look next would be greatly appreciated!

Final answer:
Remove all breakpoints
Even if they're not getting hit this fixed it for me and got performance back to normal.
May be a bigger issue if you have logging breakpoints - so try deleting those first if you're attached to your breakpoints.
Previous answers:
I came up with a workaround - although still not really figured out what is actually wrong.
I also discovered a bunch of tools I didn't even know existed that I'd skipped over before - they're under More tools.
Start by opening the Performance Monitor. This shows a nice CPU graph isolated for your Chrome tab - the Windows task manager is as useless as it ever was.
This is the behavior I got when choosing a date from mat-calendar. No other logic running - just selecting a date. I removed everything from app-component and just put a mat-calendar and it took ten seconds to change the date!
Other controls are generally fine. I could open dialogs, use combo boxes etc. and nice and fast. But selecting a date gave me this nonsense:
I tried emptying local storage, clearing cache, etc. and then I changed port number for my website. I simply changed dev.example.com:44300 to dev.example.com:44301 - in other words Chrome now thought it was a different website.
This is what it looked like after I switched port number.
I also got the same effect using a reverse proxy server - which put my local machine on the internet - so I could try to duplicate the issue from other machines. I could not.
So hope that helps someone - still no clue what's in the cache for this server that is having such a massive impact on performance. But for sure it's not just my code.
Here's a few other things to try:
Test with --aot flag
This didn't make a difference to me, but good to narrow things down.
Add some controls that don't do anything (as a control)
This way you can find if some specific action or control is causing the slow down. You should of course be able to toggle these instantly.
Just toggle them on and off, hide something.
<mat-radio-group>
<mat-radio-button [value]="false">
bloop
</mat-radio-button>
<mat-radio-button [value]="false">
bloop bloop
</mat-radio-button>
</mat-radio-group>
Enable Rendering debugging options
Make sure you aren't re-rendering the whole page constantly
The rendering option above will show this to some extent, but one thing I like to do is just add a random text box - type in it and if the text subsequently disappears you know that control has been rerendered.
<!-- yes, just a standard text box -->
<input type="text"/>
Just hide things with *ngIf="false"
Hide controls (yours and third party) and see if anything is causing problems.
For me I'm currently suspecting mat-calendar is causing issues - but I'm still thoroughly confused as to why enabling 'Record' makes the problem non existent.

I've fixed the issue, but I'll never know what was causing it. Likely a setting that I had accidentally changed.
I deleted the Chrome App and reinstalled, everything is back to normal. I'm going to leave this question open in case anyone else has this problem or wants to contribute.

It is normal for every web app to run slowly with Chrome dev tools opened.
Especially if you have inspect tab open, that it's like a new page opened in the same time + has animations on any block render.

We had this issue today at a colleagues workstation. Turned out that it was a chrome-extension (don't remember, something with "ghost" in its name). So maybe try out using guest-mode and check whether the issue still occurs. If it doesn't, successively reactivate the extensions to see which one is causing the problems. If it still occurs, follow the other proposed approaches.

Why would Chrome take 12 seconds to do an Update Layer Tree?

I have a relatively un-complex ASP.Net application, which occasionally displays an alert message in layer, with a shadow, with a pushbutton to dismiss the notification.
This code has been working fine for years.
Lately, I am getting complaints from users of really slow response. What they experience is that the page is completely unresponsive, and when they click on the [OK] pushbutton nothing happens for a really long time.
When I record a Timeline, I can see the original even which caused a round-trip to the webserver, and I can see the response from the webserver. I can also see all the Javascript code which runs as a result of the response.
As far as the application is concerned, the transaction is over, and, as far as the Javascript is concerned, the transaction is over as well. All we need to do is wait for the user to click the [OK] button and we will dismiss the notification popup.
This is where the "freeze" happens. The [OK] event is not delivered for like 20-30 seconds. What's going on in the meantime? That's why I'm writing:
We see some very short timers fire every once in a while, then we see a quick Recalculate Style call, followed by an Update Layer Tree event.
The Update Layer Tree event takes 10-12 seconds!
Here's the code for the dialog which is going unresponsive because of the Update Layer Tree events The gets displayed first as you see it here, then, if something goes wrong, it may get updated with code similar to showAlert:
Status/error dialog code

See #tiblu's comment for detail on why Chrome would perform Update Layer Tree.
As for taking 12 seconds: does the interaction behave normally in other browsers, for example Firefox or Safari? If your code has been working fine for years as you say and the browser response issues have been popping up recently (> mid-October, 2015) and only in Chrome the issue may not be your code.
There are a number of similar new issues and complaints recently, pointing to the release of Chrome 46. For example: this issue (code.google.com) and this issue (code.google.com).
CPU spikes are responsible for browser unresponsiveness, which you can monitor using Chrome's Task Manager. As for why CPU is spiking and further detail you'll need to follow the issues above and others as they develop.
Apologies for the pseudo-answer, don't currently have the rep to slip this into a comment.

Thanks to all who responded ... I was unable to figure out how to re-install an older version of Chrome, but I did manage to get my hands on a beta version of Chrome 48 (48.0.2564.8), and, to my most pleasant surprise, I am no longer able to reproduce the problem.
Just to be sure, I restored 46 from this morning's BACKUP, and it re-exhibited the issue. After re-installing beta-48, the problem is gone.
Hooray! Well done everyone!

How to analyze and diagnose javascript long run times

I have a fairly extensive javascript that I can load in my Chrome (latest stable) and in IE11.
The load icon spins but the script eventually loads on my machine in both browsers.
I have 2 other people trying to load the page that contains the javascript in IE11 and they both cannot get the page to load. The loader icon spins forever and when they mouse over the refresh icon a flyout states "long running script"
How can I analyze my javascript to identify how and where the script is taking forever to load?

Chrome's Developer Tools (F12) can profile your code. This will give you a lot of information -- possibly a lot of noise -- but it will identify two things for sure 1) functions where a lot of time is spent, and 2) functions that are called often.
This is the first place I'd start: turn on the profiler and reload the page.
If that doesn't give you a good place to start, look into the Chrome Timeline and console.timeStamp( 'Some Note' ). After you have started recording a timing session, every time the code encounters "console.timeStamp", it will annotate the timeline allowing you to estimate elapsed time between one or more points in your execution. See here: https://developers.google.com/chrome-developer-tools/docs/console#measuring_how_long_something_takes