What happens on other browsers?

If it only reproduces on webpagetest.org I suspect their infrastructure somehow. How are we to debug this (it would take a trace to show what is really going on)?

Any guidance would be appreciated. I agree there would be an issue if we are blocking on things we shouldn't, but it's not clear how to get from here to there.

+Par

Here is a bad trace.
https://www.webpagetest.org/chrome/trace.php?test=180501_Y1_7aaa496db00accef75e2b8a93379874a&run=2

And here is a good trace (not showing the issue)
https://www.webpagetest.org/chrome/trace.php?test=180501_1V_f29929cd336a6a5677cd3192c851621a&run=4

It appears all the good traces look super single threaded, and the bad trace has long tasks on the compositor thread. But then again, I don't really know how to read these.

The bad trace manages to load an SVG image, then has to parse it and it takes a long time to raster. So what I suspect is a race condition on when the SVG image loads.

I'll look at it a bit more this afternoon to see what the SVG content is, but right now it seems there isn't much that can be done. First paint is taking longer, sure, but you're getting more content in that paint if I have diagnosed things correctly.

I'll see if I can make any sense of the traces but visually the slower case doesn't appear to be getting more content in the initial render:

https://www.webpagetest.org/video/compare.php?tests=180501_Y1_7aaa496db00accef75e2b8a93379874a-l:Faster-r%3A2-c%3A0%2C180501_Y1_7aaa496db00accef75e2b8a93379874a-l:Slower-r%3A4-c%3A0&thumbSize=200&ival=100&end=full

By default, WebPageTest will shard the test across all of the devices and run in parallel so it is also possible that there are device differences triggering timing differences though the resource fetching lines up pretty well.

You can disable sharding by going to the landing page and passing shard=0 as a query param: https://www.webpagetest.org/?shard=0

It's also possible to target a specific device by passing tester=MotoG4_22 for example.

That said, here is the test with sharding disabled running on MotoG4_17 and it shows similar variations so I don't think it is a result of device sharding: https://www.webpagetest.org/result/180501_FE_d48458f6b1df9c0d7c30110f9ec1d8e4/

Interestingly, I'm seeing onload sometimes fire before the font download and sometimes after.  Not sure it is related and may be linked to "optional" or "fallback" but seemed like another interesting difference.

I've been staring at the traces for a while and trying with other categories to see if anything jumps out at me but I don't know the compositor side of things well enough to know what is going on.

In the fast cases I have seen, there is a short (100ms) raster task that runs during ProxyMain::BeginMainFrame::commit that looks to raster the initial view followed by a short gap and then a 1.5 second raster task.

In the slow cases, the long raster looks like it hits during the ProxyMain::BeginMainFrame::commit and there is no short task ahead of it.

It kind of looks like there may be a scheduling race between the renderer and gpu process but that's a wild guess not knowing the flow in there.  I'll see if I can reproduce it manually and capture a systrace to see if there is a process scheduling issue at the OS level or something like that.

Malte, I seriously doubt it is related, but is there any way to either disable the service worker or only install it after onload?  It looks like the sw initialization is all after the initial render but I can't tell if there may be setup work going on before it actually starts (and it would help make sure there is no contention anyway unless you need it to kick in for that first page load).

Looking at that film strip my theory that it depends on the SVG background image load holds up (see comment #3). The vast majority of the sub 4s pages have no SVG background. The slow pages do have it. Parsing that SVG content and rasterizing it at large scale is expensive.

In particular, there are a lot of patterns with lots of paths in each pattern. It might be something in how we paint that that makes it very slow.

If you would like to try to verify this, try replacing https://2018.jsconf.eu/immutable/12430c8427bd0127d1d1aef1ad2654cee9ac424c/images/pattern.svg with something simpler, even just dropping the patterns.

Ahh, good catch, I didn't realize the svg in question was for the background which is mostly occluded.  Presumably this is actually "won't fix, WAI" and is largely just a race depending on if Chrome decides to rasterize the svg or not before paint.

Malte, looks like it's mostly explained and experimenting with different ways to pattern the background (or not) will get you a perf boost and better consistency.

Thanks all! Feel free to close or repurpose the issue as "Chromium is slow at rasterizing a particular SVG"

Switched to Blink->SVG.  Two opportunities jump out at me:

1 - Is there something pathological about the processing of this svg that takes 1.5 seconds to raster?

2 - Should svg rasterization be done off of the critical path and treated more like image decode?  It's not blocking the main thread but it was blocking paint during the rasterization.

also +paul in case there is something we can do to expose svg rasterization to dev tools (or if we were and we were just holding it wrong).  Feels like something we should inform web developers about without the need to dive into tracing.

Looking into option 1, "Why is this SVG so hard to raster" might reveal easy wins. I strongly suspect the patterns in this SVG because the main content is quite small.

In theory we could package up the SVG drawing commands and make them a non-blocking raster task. I have no idea how hard that might be.