+treib@

Looking through the code, I can't actually find where NTPUserDataLogger::LogEvent(NTP_ALL_TILES_LOADED, load_time) gets called.

The metric also has samples in the 0-1ms bucket on other platforms (though not as many), so I don't think this is completely Mac-specific.

The call originates from here:
https://cs.chromium.org/chromium/src/chrome/browser/resources/local_ntp/most_visited_single.js?rcl=b5bd67a6d1f77ba662eb7f9ed42de0a631fc5b54&l=167
(and takes quite a long path before it arrives at NTPUserDataLogger, including special JS bindings and Mojo IPC.)

Interestingly, there's a DCHECK verifying that the time isn't negative:
https://cs.chromium.org/chromium/src/chrome/renderer/searchbox/searchbox.cc?rcl=9e0190d23863adcf5851a7741e9b73fae4aced0c&l=238

I'll take a look. My first guess is that the "start" and "end" times come from different sources which can be out of sync.
The "start" time comes from render_frame()->GetWebFrame()->Performance().NavigationStart() (have to figure out how exactly that is populated), while the "end" time is base::TimeTicks::Now().
https://cs.chromium.org/chromium/src/chrome/renderer/searchbox/searchbox.cc?rcl=7d42428d0212aa3a337168c95e0f4d0a6cd2e974&l=234

Navigation timing is weird and complicated...

Potential problem: SearchBox::LogEvent essentially ends up computing a delta between a base::Time and a base::TimeTicks, both converted to "ms since epoch" format. It gets the current time from TimeTicks::Now(), but the navigation start time from WebPerformance::NavigationStart() which is a wall time (in a convoluted way). That's fishy as hell, but I *think* it's not really any worse than just computing a delta between base::Times. Anyway, let's fix that and see what happens.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/193879ecdb90ce7e6cc738482b850202abafedaf

commit 193879ecdb90ce7e6cc738482b850202abafedaf
Author: Marc Treib <treib@chromium.org>
Date: Mon Nov 20 18:34:40 2017

Clean up time computation in SearchBox::LogEvent

LogEvent computes the time between the current event and navigation
start. It gets the navigation start time from WebPerformance::
NavigationStart() which is a wall time (i.e. base::Time), but before
this CL, it got the current time from base::TimeTicks::Now(). This CL
fixes that by using base::Time::Now() instead and also cleans up the
code a bit.

I believe this is a pure cleanup, though I'm not entirely sure if the
old way always delivered well-defined results.

Bug:  777568 
Change-Id: I81ed3e1fae2650a6bbc053ae8a4917a8e6c91f5e
Reviewed-on: https://chromium-review.googlesource.com/776854
Commit-Queue: Marc Treib <treib@chromium.org>
Reviewed-by: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517866}
[modify] https://crrev.com/193879ecdb90ce7e6cc738482b850202abafedaf/chrome/renderer/searchbox/searchbox.cc

Huh, it looks like the above CL actually fixed this: 64.0.3274.0 is the first version that contains that CL, and in this version the 0 samples are gone:
https://uma.googleplex.com/p/chrome/histograms/?endDate=20171121&dayCount=1&histograms=NewTabPage.LoadTime&fixupData=true&showMax=true&filters=platform%2Ceq%2CM%2Csimple_version%2Ccnt%2C64.0.3274.%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

While in the previous version 3273 they're still there:
https://uma.googleplex.com/p/chrome/histograms/?endDate=20171121&dayCount=1&histograms=NewTabPage.LoadTime&fixupData=true&showMax=true&filters=platform%2Ceq%2CM%2Csimple_version%2Ccnt%2C64.0.3273.%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Let's watch it for a few more days, but I think this is fixed. It'll be interesting to see if median, 90th percentile etc are affected by this at all.

Sweet! Thanks for fixing.

The NextAction date has arrived: 2017-11-27

Looks good now:
https://uma.googleplex.com/p/chrome/histograms/?endDate=20171125&dayCount=5&histograms=NewTabPage.LoadTime&fixupData=true&showMax=true&filters=platform%2Cone_of%2CL%7CM%7CW%2Cversion_tags%2Ccnt%2CL%2Cchannel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial