Google Chrome developer tools works very slow

Question

Sinсe Google Chrome was updated to 50.x version, it become impossible to work with DevTools. This issue reproduced mostly in "Network" tab. Every time when you click on "request" it takes about 30-40 sec. after that chrome can crash. Tried to delete all extensions, clear cache, and reinstall, but didn't help. Does anybody know how to fix this issue?

I'm running Chrome 50.0.2661.87 m

UPD: The problem may be occurs because of long headers. Try to close response and request headers.

Bombsight

When you say click on "request", do you mean click on any request or a specific part of the UI labelled "request"? Can you link to an example website where you have the problem? I tried to reproduce on the StackOverflow site, but didn't run into issues. – Incontrovertible

@MattZeunert Probobly you can find it on any site, but try this en.wikipedia.org/wiki/Main_Page or on site with a lot of scripts and XMLHttpRequests. Open devtools -> Network -> click on some request or script in the list -> go to headers/preview. Navigation takes too muck time ( at least for me) - 30 sec – Bombsight

This issue began occurring to me yesterday as well. Have tried many of the same steps in addition to renaming the "Default" profile in case the profile was corrupt. Will attempt on another machine tonight at home. – Chloras

I'm on 50.0.2661.102 OSX and I have the same kind of issue when I try to edit CSS properties. It takes so much time to actually update the value, and most of the time it even removes the latest characters I've typed. Really annoying. – Siobhan

Working on a large Angular app it is really cumbersome to switch between console and elements viewer. When doing any action in console the GUI gets really slow. There is usually 2 second delay when selecting element on screen. – Stellular

I also see the issue in Chrome 50.0.2661.102 (64-bit). It started a few weeks ago (probably at introduction of 50.x). – Baudoin

If Chrome dev team are watching this just thought I'd throw in my vote for this too. Seeing exact same behavior on 54.0.2824.0 dev (64-bit) on Mac. – Distributee

The problem occurs because of long headers. Try to close response and request headers. Of course if you don't need to debug them. – Bombsight

Answer 1

I've been having similar issues for debugging in Chrome versions 50+ on Mac OS X 10.11.3. The only solution I've found so far is to keep the dev tools docked to the right and it seems to be as performant as before. Not the optimal solution, but it works in my case.

Prize

Totally bizarre, but a definite lifesaver. I like to think this workaround won't be necessary for too long, but it's made dev tools usable again for me. Thanks! – Scoville

Even undocked tools of screen width have the same issue as reported. When narrowed it acts normally. This is definitely strange :) is that reported somewhere? Edit: It is based on the width of source window! The narrower, the faster it reacts. Thanks @Chris! – Malatya

+1 for this. Looks like it was fixed in v53. Latest stable version at time of writing is still 52.x. Canary shouldn't have this issue. – Niobe

Seems to be back again in 60.0.3112.113. This fix once again works. – Phallus

Just ran into this issue with Chrome 61.0.3163.100. Again, the skinnier window totally fixed it! – Lapsus

Yep! Got this in Chrome 62.0.3202.94 - fixed by docking. – Harod

Was a bit sceptical when I read this but it significantly boosts the speed of the dev console if you normally have it undocked – Lateritious

@Rebar In case you didn't fix it yet, there's another fix which was found a few weeks ago link – Piebald

Still seems like a valid solution in 2021: Chrome version 91.0.4472.114 on Ubuntu 18.04 (beware: NOT CHromium!) – Harlandharle

By the way: same problem using Firefox 89.02 on Ubuntu 18.04 – Harlandharle

Answer 2

Finally, a solution has been found which helped me after such a long time and after so many failed attempts to fix it: Solution on Google Chrome Forums

Go to chrome://flags/#force-color-profile

Change it to sRGB

Since Google does not allow direct links to chrome:// you'll have to insert the colon by yourself, or enter the whole link manually into your toolbar.

Piebald

I did not believe you because this seemed entirely unrelated. But it did help!! Thank you so much! 🙇‍♂️ – Cantatrice

Since KB5001330 on Windows 10, this was a serious issue on my machine. Whoever has applied this update and not received an appropriate patch, this helps in terms of continue working until the patch-patch arrives. – Sidra

This is the fix but the link chrome://flags/#force-color-profile may not work if you click it. It is a real link.. You have to copy and paste that link into the address bar, if it's giving you trouble like it did me. – Turnspit

And I thought I was lacking of RAM! Thank you so much – Zindman

Also helped me on Edge. Obviously the link in will be edge://flags/#force-color-profile instead – Mastersinger

This solution is still valid for Chrome 96. – Daze

🤯 i can't believe it. made an immediate difference on chrome 105 macos 12.5 – Recovery

Seems it improved the performance of chrome a lot. – Rete

Answer 3

My situation was similar, after struggling a while with extreme slow developer tools response I found out the problem was caused by a Chrome extension I had installed for knockoutJs. So for people experiencing these issues, as part of the initial troubleshooting, try disabling chrome extensions.

Sequestered

Nice one. For me it was Knockoutjs context debugger extension. Cheers! – Asterism

For me it was the React Developer Tools! Only happens on Mac, does not happen on Windows. – Macrospore

Disabling Augury extension helped for me. Thanks! – Funest

Can confirm that React Developer Tools affects windows as well – Trailer

Can Confirm: Brave Shields, Privacy Badger, uBlock Origin – Kermit

Answer 4

I'm using the Version 61.0.3163.79 and I have the same issue that this post talks about.

With some searches I found out that the problem was in the user that I was using. What I tried was to enter int google chrome as guest and the devtools became faster again.

So what I did was:

1. Check out if debugging using the guest user is faster as it should be.
2. Logout from the account.
3. Clean all cache associated to google chrome.
4. Restart the PC (but i think closing the browser is enough)
5. Login again in your account.

I hope this could help other people with same problem.

[EDIT:]

I found out that after some time (weeks) the google chrome dev tools will get slower again. So I tried the following solution and it worked:

1. Open the dev tools
2. Go to the Sources tab.
3. Cleaned all watched variables, breakpoints, DOM breakpoint and Event Listeners breakpoint.

[SECOND EDIT:]

After some weeks, the issue came again. What I did was installing the google canary Version 64.0.3249.2 canary (64-bit) and my problems vanished.

For who's that doesn't know what is canary, please check this link.

Adolescence

Removing unnecessary breakpoints solved my problem instantly. – Hoenir

Answer 5

Google is aware of the problem - https://bugs.chromium.org/p/chromium/issues/detail?id=624097

The problem seems to have vanished in v.53 - they are currently trying to figure out what fixed it. If possible, the fix will be merged back to v.52. But at least they are working on it.

Roslynrosmarin

I'm now working on v53.0.2785.101, still have the issue. It's so unusable that I installed firefox, and I wasn't using it since years... – Creel

Pretty much the same here - wanted to edit some text in a div to show the client, took 30s after I clicked to change to editable text. – Facultative

I was using v53 when I found this thread. So that seems incorrect? 53.0.2785.143 m seems better, however. Though not sure if it was just the reboot that sorted it out. – Eyeleteer

Same problem in Chrome 54.0.2840.71 m (64-bit) – Amundson

Any workaround ? I tried canary and it is the same for me. I have to switch to firefox for now... – Thom

Answer 6

Chrome version: 112.0

MacOs: Ventura 13.1

Disabling async stack trace really improve performance for my team and I while we have dev tools open.

You can find this option in the settings :

Monatomic

Answer 7

In case others arrive here facing the same issue I had, try changing the Dev tools tab you're looking at to Elements.

I had the "Sources" tab open and Chrome was trying to load enormous assets for that tab, which created a multisecond delay between the console.log() events I created and the display of those logged messages.

Lusterware

Answer 8

Make devtools snappy again by deactivating all breakpoints:

Go to the Sources tab, show the debugger (may be hidden) and hit Deactivate breakpoints.

(Chrome v62.0 on Windows 10)

Pierce

that's it! Tried everything in this thread but this finally worked. I guess for big js projects it somehow seems to cause problems. – Gilemette

Answer 9

I sped up Chrome again by doing the following:

• Open DevTools -> select Elements tab ->
  • select nested Computed tab -> under Filter, make sure that Show all is unselected.
  • select nested Event Listeners tab -> make sure that Ancestors and Framework listeners are unselected.

Robbierobbin

Thanks! This solved it for me. Almost same performance as if Dev Tools were closed. Great find! (Chrome 114) – Palsgrave

Answer 10

I've had the same time issue on 54.0.2840.99 m version of Google Chrome.

But switching to Chrome Canary worked !

Aran

Google Canary worked for me until the last update, and the 59.0.3054.1 version is also very slow :( – Tsimshian

Answer 11

Reduce size of resource being overridden

Only overriding files with less lines of code worked well for me. I landed here because I was overriding a file which had 35,000 + lines of Javascript.

Further, if your resource is a new one - i.e. it is not included in a script tag or link tag, you can override main html document and add the tag : <script src="/my-new-script.js"></script>. Add the file to your domain-root within the Overrides folder on Chrome:

overriding HTML

then overriding CUSTOM SCRIPT:

Good Luck...

Gardening

Answer 12

I also face same issue.

I tried unchecked toggle screencast. Now it is working fine.

Vidda

In case someone else is also struggling to find "toggle screencast": It's an icon on top left corner of DevTools – Funest

Answer 13

In my case, I had Local Overrides setup (https://developers.google.com/web/updates/2018/01/devtools#overrides) in Downloads folder which had a lot of files in it and that slowed down devtools.

Setting up overrides in its own seprate directory fixed the slowness.

Annmarieannnora

Answer 14

For me, running Chrome Version 81.0.4044.138 (Official Build) (64-bit) on Ubuntu 18, the problem seems to be the mobile view. When I disable mobile view inspecting becomes really fast again. I think it is caused by touch emulation and other mobile stuff.

To have something similar to a mobile view I move the DevTools dock to the side and resize it until I get the width I need. It is not perfect, but it is useful most of the time.

Besides Chrome, Firefox is much faster when inspecting sites overall, though I didn't use FF because I'm used to specific things on Chrome. Moreover, most of the sites I work with do not trigger these issues on Chrome, in fact, it happens with only one site.

PD: the site that triggers the issue on Chrome Dev Tools has lots of CSS variables. Not sure if that is related.

UPDATE 1 WEEK ago I was able to use Chrome without issues even in the mobile view by disabling the option "Show media queries"

Ruin

Answer 15

Go to the network tool and change it without any restrictions. Sometimes this happens if you change mobile settings. Google chrome changes this setting to test mobile device on low internet connection and leaves it that way.

Sandal