What is the major difference b/w Visual Progress (%) and Visual Progress - Dev Tools(%) metrics when you perform a visual test? Which is a better indicator of speed?
The “Visual Progress (%)” uses the screen shots/video and looks at the pixels of the end state to determine the progress. It works well a lot of the times and is the original method but it falls apart a bit for pages with large interstitials or slideshows that auto rotate.
The “Dev Tools” version is a newer version of the algorithm that tracks every paint event and deals with pages that update and change better: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index#TOC-Visual-Progress-from-Paint-Events
The Dev Tools version tends to be more consistent and works best for Chrome but I’m looking into making it more robust for the other browsers as well. Eventually the plan is to move to the Dev Tools version of the metric once I’m comfortable that it works better across all of the browsers.
Another benefit is that it can be captured without having to capture video.
it is very useful for me (http://www.computersoutlook.com)
Hi Patrick,
Is there a way to get the data (raw data) that is plotted on the Visual Progress - Dev Tools graphs?
Thank you!
Not currently but it shouldn’t be too hard to add to the JSON and XML interfaces. Would that work?
Patrick,
Thanks for reply quickly to the previous message.
I’d like to compare the best case with the worst case. For example:
Let’s say that one browser (“good browser”) loads the page visualy perfect and other browser (“bad browser”) not. I’d like to generate the visual progress graph for the “bad browser” based on the page fully loaded on the “good browser”.
It was possible to understand? Any ideas on how could I do this?
I’m sorry for my english.
Thanks again!
It sounds like you’re trying to use it for validating, in which case you don’t care about the individual progress steps, but really the end state. You will have to calculate it yourself from the screen shots though because calculating across tests isn’t something you can do with the summary data that is provided (you’ll need to operate on the images themselves).
Hey Pat,
It’s not clear at all to me how the dev tools speed index and Visual Progress % work for non WebKit browsers, specifically IE. If IE (say IE9 to be specific) doesn’t use WebKit, where does the data come from? The algorithm (defined here https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index#TOC-Visual-Progress-from-Paint-Events) talks about how it’s implemented using WebKit, but doesn’t say anything about how it works without for non-WebKit browsers.
Thanks,
Jeff
For the case of non-webkit browsers the agents record the paint rects from their API hooks in the graphics pipeline. It’s not as accurate as when the browser reports them but it works reasonably well. If you’ll notice, there is a “timeline” link for the IE and Firefox tests that is for the synthesized dev tools paint events (though the timeline viewer isn’t displaying the coordinates correctly - I might be writing them in an older format).
Thanks, Pat