Open connorjclark opened 2 years ago
(but doesn't)
(which seems true)
modern-image-formats-before.trace.json (which should "match" the actual trace): (but doesn't)
I think the Lantern debug trace generator is broken (check those duration details :)
The output from printGraph
seems more reasonable and appears to resemble the "real" waterfall pretty well.
(comment was before reading brendan's post)
Noticed that I'd get 3-4 concurrent requests max in simulator even though 10 was the max concurrent connections. It ignores all the extra connections because of how it simulates the connection pool.
Setting flexibleOrdering
gives a better graph (for modern-image-formats). Need time to figure out how connections work / what is intended by this option.
A big thing with the image audits (and almost all the ByteEfficiency audits) is that they're savings against end-of-trace, not LCP (or even TTI).
It's less obvious in https://next.webpagetest.org/themetrictimes/index.php
—in my report the image opportunities are still less than LCP—but in Phil's example report where they exceed LCP it's possible a slow loading image kept waitForLoad
going well past LCP and the savings are still accurate for the end of the trace.
I think the Lantern debug trace generator is broken (check those duration details :)
The output from printGraph seems more reasonable and appears to resemble the "real" waterfall pretty well.
I read this comment as you saying that the bug is just in the debugging trace generation, not an indicator of simulator doing something wrong. (maybe you didn't mean this?)
However, the debugging trace generation is made directly from the node timings in the simulator (while printGraph doesn't use simulator at all), and I can confirm the simulator is only doing a handful of requests at a time for this particular image audit. This does look like an actual error in the simulator.
A big thing with the image audits (and almost all the ByteEfficiency audits) is that they're savings against end-of-trace, not LCP (or even TTI).
Yeah there's that, I omitted those details. Just focusing on the wildly unexpected trace / number we're coming up with. No sensible reason these images would be requested in series.
Yeah, I was making a big assumption that trace emit was more broken than it was. I see the same serial image requests you did (and the trace shows), which does seem broken.
Setting
flexibleOrdering
gives a better graph (for modern-image-formats). Need time to figure out how connections work / what is intended by this option
it allows ignoring connectionReused
from the actual requests. That makes sense for the altered graph in some cases, but if ignoring it is required to approximate the original load graph, something is pretty wrong.
From @philipwalton:
A command to quickly generate the faulty traces:
Either an issue with the graph generation, or the simulator. I think the former.