Tried testing the issue on chrome reported version# 70.0.3538.102 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://jsfiddle.net/julienv3/nb4sLeyk/
2) It shows prompt message that "injecting frame in 5 seconds", Clicked on 'OK', page got loaded with iframe(Youtube video), didn't observed any difference in loading of iframe on comparing reported chrome version with older chrome version and firefox.

Observations:
Also tested the issue by loading the '.html' file in New Tab Page, it shows prompt message that "injecting frame in 5 seconds", then if we switch between the tabs and opened the same tab where '.html' file is loaded, then after few seconds prompt will disappear and then iframe got loaded in that page.

@Reporter: Please find the attached screencast for your reference and provide your feedback on it, if possible could you please provide screencast of the issue which help in better understanding and further triaging it in better way.

Thanks!

Deleted: 905825.mp4 2.1 MB

	905825.mp4 2.1 MB View Download

See attached screencast. The problem isn't that the iframe won't load, the problem is that between the iframe being appended to the DOM and the iframe's HTML being fetched there's a delay (around 250ms in the attached repro) that's unaccounted for.
Same behavior does indeed happen in Firefox (and appears to be even worse), I'm just wondering from a performance perspective why there's this idle time between iframe being appended and the actual iframe fetching, parsing, etc.

Deleted: 905825 - iframe element injection and iframe src download are separated by a significant delay - chromium - Monorail - Google Chrome 11_16_2018 4_56_05AM.mp4 2.8 MB

	905825 - iframe element injection and iframe src download are separated by a significant delay - chromium - Monorail - Google Chrome 11_16_2018 4_56_05AM.mp4 2.8 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on chrome reported version# 70.0.3538.102 using Windows-10 as per screencast provided in comment# 4. Compared the behavior of chrome reported version with chrome earlier builds(M-60). After iframe got loaded, observed "1.26 ms(self 1.20 ms) appendChild" in Devtools > Performance tab in chrome version# 70.0.3538.102 and where as in chrome version# 60.0.3112.0 observed "1.00 ms(self 0.87 ms) appendChild".

@Reporter: Please find the attached screencast of both chrome versions and provide your feedback on it which help in further triaging it in better way.

Thanks!

Deleted: 905825 - 70.0.3538.102.mp4 2.6 MB

	905825 - 70.0.3538.102.mp4 2.6 MB View Download

Deleted: 905825 - 60.0.3112.0.mp4 3.0 MB

	905825 - 60.0.3112.0.mp4 3.0 MB View Download

The delay I mentioned isn't for appendChild itself, it's between appendChild and the iframe's html network call.
The two screencasts you provided in comment 6 actually help a lot, as Chrome 70 has the delay while Chrome 60 does not.
See attached PNG for the delay I'm talking about, the screenshots in there were taken from aforementioned screencasts.
Note: the total time between appendChild and iframe code evaluation seems similar in both versions of Chrome.  Is the profiler simply not reporting whatever is happening during this 300ms?

Deleted: chrome 70 vs chrome 60 iframe.png 667 KB

	chrome 70 vs chrome 60 iframe.png 667 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported version 70.0.3538.102 and latest chrome 72.0.3615.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, hence providing Bisect Info

Bisect Info:
================
Good build: 63.0.3216.0
Bad build: 63.0.3217.0

You are probably looking for a change made after 502250 (known good), but no later than 502251 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/282ea833bef8dbf11acfa618d06568a910242c4d..0dbded05ad0ba1c3d8388fd649130509ab97f07a
Change-Id: I4fe9a56cc98617b9b470800d63c56f330bb3b87a
Reviewed-on: https://chromium-review.googlesource.com/581488

@clamy: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

+nasko, alexmos

The bisect CL corresponds to turning on PlzNavigate. I'm not sure how srcdoc navigations behave, but I would imagine this delay is due to going to the browser process, navigating the iframe and coming back to the renderer process for commit.

#c10: The frame just sets a regular src and not srcdoc in this example, no?  

The 250ms delay does seem a bit large, if it's between appendChild and the network stack even starting the request, but I'm not sure if that's what DevTools is actually showing.  chrome://tracing with the navigation category would probably be more reliable to analyze this delay.   FWIW a simple trace doesn't show any big delay between the youtube FrameTreeNode being created and the navigation starting.  Further, I see a navigation:timeToResponseStarted of 294.835ms for the youtube iframe, and I also see under NetLog that URL_REQUEST_START_JOB for the youtube src took 281ms, so seems most of the delay is just connecting to youtube and waiting for it to respond, and DevTools isn't properly showing when the network request actually goes out?