Thanks for the filing issue...

Tried to reproduce the issue on reported chrome using windows 10.Attaching screenshot for reference.
Steps:
-----
1. Launched chrome 
2. Navigated to www.bingo.com >> opened Dev tools >> Console 
3. Entered performance.timing >> observed the Loadeventstart and loadeventend as per attached screenshot
As we have observed different values for M-69 (difference between Loadeventstart and loadeventend = 3), M-70(difference between Loadeventstart and loadeventend = 1) and M-71 (difference between Loadeventstart and loadeventend = 4)

@Reporter: Could you please check the attached screenshots and let us know if anything missed from our end. If possible provide screencast for better triaging it. 

Thanks..!

Deleted: 908322-M69.PNG 1.7 MB

	908322-M69.PNG 1.7 MB View Download

Deleted: 908322-M70.PNG 1.6 MB

	908322-M70.PNG 1.6 MB View Download

Deleted: 908322-M71.PNG 2.4 MB

	908322-M71.PNG 2.4 MB View Download

Loading triage:

aditya.vaish: could you provide more detailed information to confirm the issue? are you a people in the Bing team, and have some aggregated metrics?

Since this is a performance notice, manual tests like #3 won't make much sense.

Also, .... well ... not sure but only the screenshot for M70 showed a bar saying 'Bing is better with Microsoft Edge. Try it today' on the top. So, it may be possible that the site provide different contents depending on browser versions. Apparently this affects loading performance a lot, e.g. showing this message bar itself will cost.

Let me set the NextAction date. If we couldn't concrete step to measure this regression, we would close this as wontfix.

Thanks for the followup. Trying to get a repro on client but no consistent numbers across runs. We saw a huge regression on 10/16 in Chrome70. This is the day when Chrome70 went into stable stage and the same day we also increase in traffic. Chrome70.jpg shows the regression on Chrome 70 on 10/16. On the other hand, we did not see any significant movement on other versions of Chrome (other two pics). All the timing are W3C loadEventEnd. 

For the top bar ("Bing is better with Microsoft Edge"), it is post loaded and thus is not counted towards W3C loadEventEnd. Please let me know if you need anything else.

Deleted: chrome70.PNG 65.4 KB

	chrome70.PNG 65.4 KB View Download

Deleted: Chrome69+70.PNG 80.7 KB

	Chrome69+70.PNG 80.7 KB View Download

Deleted: Chrome69+70+71.PNG 103 KB

	Chrome69+70+71.PNG 103 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

As per comment #4 looks like it would be difficult to reproduce and bisect this manually. Hence, adding 'TE-NeedsTriageHelp' label and requesting the appropriate team to look into the issue and help in further triaging.

Thanks..!

aditya.vaish: thank you for more information.

I assume X-axis is timeline, and Y-axis is performance (lower is better), right?

If so, Chrome 70 was good in the beta channel, and showed regression when it moved to the stable. Chrome 71 is still showing a better result, but may show similar regression when it goes to stable? Maybe we can see answer soon, since 71 is now coming.

Possible reason is we are running experimental features on beta, and it can contribute to performance. E.g., redesigned service worker and network stack is under the field trial.

Or another reason would be statistical population difference. Generally speaking, end users are likely to use the stable channel on low-end devices.

The NextAction date has arrived: 2018-12-05

toyoshim: thanks for the update.

Yes, x is timeline and y is performance (lower is better).

It does seem to have caused exactly when Chrome 70 went to stable. But the other thing to note is that there was no (overall) regression when 69 was stable. Do you have the date when 69 went to stable?

I do not believe that it may be statistical population difference as for overall (cumulative for all versions) Chrome PLT was stable for several months and suddenly it regressed starting around second half of October (same time as Chrome 70 increased in numbers).

(metrics are measured from navigationStart as 0)

On related note, in the same timeframe when W3CLoadEventEnd regressed, W3CFetchStart improved by more than 300ms. To start with, it was higher than Edge and then end of October it dropped below edge (attached graph, cumulative on versions, Chrome and Edge).

From spec it looks like fetchStart should be very minimal (difference b/w fetchStart and navigationStart) but it is indeed high for a page like this which does not have appCache lookup time.

Deleted: fetchstart.PNG 185 KB

	fetchstart.PNG 185 KB View Download

toyoshim: Another update:

Checked on some other pages in Bing and looks like the regression is way more prominent on homepage itself. There are structural differences between homepage https://www.bing.com/ and, say https://www.bing.com/search?q=hello

One thing we found out was that doctype looks to be set in old way. Do you know if such structural differences can cause Chrome to behave differently? Will be great if you can check on some other structural difference that you see are evident.

You can check Chrome release date at https://chromiumdash.appspot.com/schedule
According to this, m69 stable happened at Sep 4.

Let me set more components label to get more eyes from possibly related teams.

Also, CC: kenji for PM eyes.

It would be nice to check the data for 69, 68, 67, etc.
We know that the beta and stable populations have different performance characteristics.

Removing PerformanceAPIs label, as this looks to be a regression in performance, not web perf APIs.

toyoshim@, is there any followup to do here?

My comment at #c8, and Kenji's comment at #c14 suspect this is a false alert by seeing populations' characteristic differences among release channels.

So, we'd know what happens on recent other stable promotions.

Let me set Needs-Feedback label.

NetAction is also set to 02/01/2019. If there is no new input, I will close this.