Looking at the NTP page code, it appears there are two animations, one for the top half of the page/text field, and a second for the thumbnails. It seems like the intent of both is to fade in each piece, the first over 0.5s and the second over 0.75s. The total execution time is 1.25s, which is about the delay shown in the trace. My guess is that something is going wrong either in the coding of the CSS or the renderer, such that instead of seeing each frame of the animation we're only seeing the final frame.

Attaching the trace.

Deleted: trace_blink-delay.json.gz 2.8 MB

trace_blink-delay.json.gz 2.8 MB Download

Thanks for creating the report. Assigning to Marc for review as part of our Q2 maintenance efforts for the NTP.

shrike, you marked this as a regression. Do we have an indication that it is? AFAIK this has never worked better, no? (I'm mostly asking, because if it is a regression it may be easier to debug if we know when the regression was introduced).

Given that this is one of the most prominent pieces of our UI, seen by every user when they open a tab, can this be prioritized a little higher than "Q2 maintenance"? It makes Chrome feel slow and unresponsive. 

I put it down as a regression because I don't think it always was this slow. I just tried my steps going back to M47 and can reproduce the problem in those versions, so it does not seem to be a regression in that sense.

In the first NTP load in that trace, the animation actually takes "only" 500 ms. That "animation" just hides the page until the XHR (which fetches suggestions, doodle, and OneGoogle bar) has finished and we have injected its results into the page.
This matches my experience: around 700 ms total until we get something visible.

We could potentially remove this "animation" and show the initial page (basically just the fakebox) earlier, but that makes it look very janky - e.g. the fakebox is resized after the suggestions arrive.

In the second load, there's the same 500 ms "init-hide" pseudo-animation, but then there's a 1-second fade-in animation on the suggestion tiles. I've seen that sometimes; I'm not sure what triggers it. But since it's an actual animation, it shouldn't hurt the perceived latency too much, but I'd like to decrease the time from 1 s to maybe 500 ms or less - WDYT?

I was a little confused by the first NTP load trace so my comments about timing were about the second one. I should have gone back and tried to look at the first one after that.

From your description of the situation it does seem like you need to wait the 500ms until the other NTP page components have arrived to avoid jank. That said, it would be nice if some basic form of the page could be displayed immediately and have that morph into the end result once the doodle and other components have arrived. Maybe the doodle folks could come up with some general transition from the Google logo to the doodle-of-the-day that will work for all doodles. Re: the fakebox being resized, are the "suggestions" you're referring to the NTP thumbnails?

Re: trimming the length of the 1s fade-in animation, I don't think the animation itself is a problem. The problem is that no frames of the animation appear except for the very last one. And I also don't see the top portion appear, followed by the thumbnails - it all just shows up at once, after a 1s+ delay. To fix this problem you have to dig into why none of the intermediate frames are being displayed.

Well, the "basic form of the page" would only be the fakebox and maybe a default Google logo. So it wouldn't actually be all that useful. And the fakebox appearing, then changing its size after ~500 ms, even if animated, is also weird IMO. So, I don't think we can do a lot about those 500 ms.
(Yes, by "suggestions" I mean the thumbnails.)

The fade-in animation is weird. On most NTP loads (at least 9 out of 10), it doesn't trigger at all for me, and the thumbnails appear immediately with the rest of the page. But when it does trigger, the animation works. (Tested on Linux and Mac.)

Are you sure it's the fade-in animation that's broken? Note that this one only applies to the thumbnails. So if the whole page appears late, then that's probably caused by something else.

Actually, I am not sure what is broken - I am simply reporting to you what I am seeing, and taking a guess as to possible causes. Whether it's the fade-in animation itself or something else, the NTP is still broken - the cause needs to be determined and the issue needs to be fixed. I am happy to work with you, as best I can (not being a CSS or Blink person) to figure out the cause.

 Issue 599872  has been merged into this issue.

Marking as a candidate for our PE fixit.

Last I heard there is a plan to reimplement the NTP which should dramatically reduce the time it takes to appear.

There is indeed, but (unsurprisingly) it'll take longer than originally anticipated. There might be a way to port some of the ongoing work to the remote NTP, to make things at least a little better in the meantime.

treib - What's the latest on NTP?

Not much to report at this time. I believe the worst things have been fixed.  Issue 514752  will shave off a few milliseconds, but its launch was delayed to M60. The local NTP launch (mentioned in comment #12) is still a while out.