Can you attach a netlog showing the issue, using the instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details? Thanks!

I can't attach a netlog because the page chrome://net-export can't be opened either for about 1 minute after resume from sleep.
See the attached screenshot (in German).

Deleted: chrome.png 13.6 KB

	chrome.png 13.6 KB View Download

Unfortunately the screen shot doesn't have enough info to proceed with triage.

Could you start the netlog *BEFORE* putting Windows 10 into sleep mode, and stop the netlog *AFTER* it resumes and starts working? 

I have attached a netlog:
Windows was resumed from sleep and www.heise.de was opened in Chrome.
I took about 100 seconds until Chrome reacted and showed an error page.
After that www.heise.de was successfully loaded in a second.

Deleted: chrome-net-export-log.zip 475 KB

chrome-net-export-log.zip 475 KB Download

Notes from examining the net-internals dump in c#5: 
* There are three URL_REQUESTs to www.heise.de at event sources # 727, 835, and 931.  The one at 931 completes in under a second (that request actually completes in ~100ms, but the loading of the whole web page presumably was longer) and was started at absolute time 155719.  
* The other two requests both completed in error but overlapped in time.  727 was from 53354-59375 (~7s) and 875 from 55554-83381 (~28s).  I'm not clear why these requests were racing each other.
* Both of these requests started out as http: requests, which hit in cache as a redirect to the same URL with an https scheme.  
* The 727 URL_REQUEST hit in the host resolver cache (2 IPv6 addresses & 1 IPv4), but was canceled/aborted after a seven second delay in the SOCKET_POOL event (HTTP_JOB_CONTROLLER->HTTP_STREAM_JOB->SOCKET_POOL, the socket pool event was from 53382 to 59375.)
* The 875 URL_REQUEST went down the same path, but did show a successful binding to an SSL_CONNECT_JOB (at the same point in the timeline as the "Timed out" error).  Going from SSL_CONNECT_JOB to TRANSPORT_CONNECT_JOB to socket (event source id 731) shows a CERT_VERIFIER_JOB immediately after the SSL_CONNECT_JOB.  The CERT_VERIFIER_REQUEST shows as canceled, but the CERT_VERIFIER_JOB lasted from 53482-155601, which unless I miss my guess is the 100s delay the OP is calling out.

Anyone on the cert verification label able to guess or dig deeper into why this is taking so long?  Is there some known way windows gets wedged on cert verification coming back from sleep?

Thanks for the log!

csname1910: Was it about 20 seconds after waking up the computer that you navigated to www.heise.de, or sooner? Does disabling proxy auto-detect improve anything?

The 100 second certificate verifications are unexpected, as I don't think either AIA nor OCSP are involved here. It is worth noting that CERT_VERIFIER_JOB times not just the certificate verification time on the worker thread, but also the rountrip posting across threads, so would also be affected by a scheduling stall of IO thread or worker pool.

The description from reporter of no page (including chrome://net-export) loading while this is hung makes me suspect it is an external thread scheduling problem, like a hung IO thread.

csname1910: Could you start a chrome://tracing/ capture before going to sleep, then wake up and load www.heise.de, and once that finishes stop tracing? Thanks!

Disabling proxy auto-detect solved the problem!
Thank you.

But I wonder why Internet Explorer had no problem, because the proxy settings should apply to it, too.

Issue 806939 has been merged into this issue.