See https://twitter.com/BruceDawson0xB/status/890755061436923904 for initial call for help from AMD, but it's probably not AMD.

Tried to roll back to AMD drivers ver 22.19.171.257 from (22.19.662.4) but hitches were still present

I'm on Wired Network

And it's most noticeable on websites with autoplaying videos/gifs a few moments after loading page (or switching to/closing tab)

another ETW
https://mega.nz/#!IhAQEIpK!Fj7GQo6I3myVx6Cvaz-YtGXcWwSbC6O4H3XiblwD8NA

Try opening up Device Manager to see if there are new drivers for your Ethernet controller. Our assumption is that this is a driver bug, but this is the first time I've seen the issue on a wired network.

Tried to unsuccessfully repro it on one of my systems here.
Was there any other change to the system recently? Is ending the ATIECLXX.exe process via Task Manager changing the behavior by any chance? 
Since rolling back to the previous driver didn't resolve it, seems to indicate the problem is likely not on the graphics driver files. 
MOde information needed. 

Looking at the ETW files, there doesn't seem to be an indication any AMD driver component has a substantial presence. And neither would impact network function 

Other possibly related bugs:

crbug.com/749758 - closesocket hang during shutdown
 crbug.com/739327  - browser hung and unkillable, blocked on closesocket
 crbug.com/667820  - five second hangs in closesocket, believed to be caused by old/unsupported Intel WiFi driver
crbug.com/165382 - Browser IO thread hangs for several seconds (closing UDP socket for async DNS request?)

crbug.com/708204 - Linux version of this? Presumably unrelated, but huh.

Also, when I bought a new laptop a few months ago I would initially have *atrocious* hangs in Chrome when resuming from standby. Updating the WiFi driver resolved those completely.

My assumption remains that this is an OS or, more likely, driver bugs rather than a Chrome bug but it could still be valuable to have instrumentation to assess the extent of the problem.

> My assumption remains that this is an OS or, more likely, driver bugs rather than a Chrome bug but it could still be valuable to have instrumentation to assess the extent of the problem.

I think we already have instrumentation. There is "Net.UDPSocketWinClose" histogram which measures the time closesocket() takes when we are closing a udp socket on Windows. There are about 0.05% of users on Stable who have closesocket() take more than 1s. 

Updating LAN drivers had no effect
Killing ATIECLXX.exe had no effect either.

Only change i did to my PC was that new AMD GPU driver installation. Problem arise right after restart required by installer (thats why my first suspect was AMD driver) .. but i dont know what Chrome version i had previously, i don't restart my PC often nor close Chrome so there is a chance there could have been update waiting.

Even Windows reinstall didn't helped.
Only installed things are Chrome, Avast and AMD Drivers 

I'd call this a dup of 667820. Marking it as such.

Actually, not sure if this is a dup... I'm trying to have all these hang conversations in the same place though. It may be too early to call this a dup. Un-duping.

Is there any way i can help to investigate this? I have to use different browser, chrome is unusable for me now :( Hangs are really common now.

Btw: don't know if it's related. But now when i have cursor in address bar i have to press Enter twice to get something to happen (doesn't have to press it twice on other PC's where that hangs arent appearing)

Opening and closing socket off thread seems like a nice thing for someone new to Chrome to investigate, though it's a bit more involved than most good first bugs.  Need to be careful to make sure there's no problem when there's a pending read/write, but otherwise...