| Peter | |
| Jan 27 2018, 8:26 PM |
| F12904643: Screen Shot 2018-01-31 at 6.42.02 AM.png | |
| Jan 31 2018, 5:45 AM |
| F12904646: Grafana WebPageTest.png | |
| Jan 31 2018, 5:45 AM |
| F12833655: Screen Shot 2018-01-27 at 9.22.19 PM.png | |
| Jan 27 2018, 8:26 PM |
| F12833654: Screen Shot 2018-01-27 at 9.22.38 PM.png | |
| Jan 27 2018, 8:26 PM |
Multiple times the devtools.timeline metrics has been just too low, something must be wrong somewhere:
The problem can be:
To debug it, we need to store the trace log on the server, the easiest is just to store the latest version on the local server. Let me try that on Monday.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Peter | T182510 Measure time spent in scripting/painting/rendering for Chrome [proxy] | |||
| Resolved | Peter | T185810 Investigate too low values in devtools timeline |
We still have the problem with the new trace-parser, so it is either a problem with the trace log itself or how we pick the value. I look into it when we store the trace log.
When I think of it, I think we have the same for our WebPageTest runs:
Let me collect a trace log the next time it happens and create an upstream bug.
Found runs that produces the same bug with WebPageTest so I filed a upstream bug:
https://github.com/WPO-Foundation/webpagetest/issues/1100
Hmm this could actually be T186101 that is the cause (=not the same as in WebPageTest).