Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team picked up a spike to investigate what data, if any, we were logging around site speed [0], given the existence of the mobile graphs over at WMF stats [1].
After a little poking around I found that all of the NavigationTiming data that's collected by the eponymous extension is already separated out into desktop and mobile series in Graphite [2]. Any or all of these series can be graphed in gdash by defining our own graphs [3].
With this in mind I've closed the tasks to design and implement our own event logging for site speed as invalid – don't you just love it when work's already done for you?
Furthermore, if we find, some time in the future, that we want do refine the data that's being collected, then we have a clearly defined workflow: design the schema with the help of analytics, instrument the schema, and then define a graph. You'll note that only the first step requires collaboration (i.e. synchronisation) with another team. Woo!
–Sam
[0] https://phabricator.wikimedia.org/T95296 [1] https://gdash.wikimedia.org/dashboards/frontend/ [2] https://graphite.wikimedia.org – have a good look around frontend - navtiming [3] https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/d...
It would be good to get desktop and mobile in the same graph so we can compare the two. If I'm reading correctly this is all rather depressing - we are pretty much the same as desktop despite being an environment which should explicitly do better?
On Wed, Apr 15, 2015 at 7:02 AM, Sam Smith samsmith@wikimedia.org wrote:
Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team picked up a spike to investigate what data, if any, we were logging around site speed [0], given the existence of the mobile graphs over at WMF stats [1].
After a little poking around I found that all of the NavigationTiming data that's collected by the eponymous extension is already separated out into desktop and mobile series in Graphite [2]. Any or all of these series can be graphed in gdash by defining our own graphs [3].
With this in mind I've closed the tasks to design and implement our own event logging for site speed as invalid – don't you just love it when work's already done for you?
Furthermore, if we find, some time in the future, that we want do refine the data that's being collected, then we have a clearly defined workflow: design the schema with the help of analytics, instrument the schema, and then define a graph. You'll note that only the first step requires collaboration (i.e. synchronisation) with another team. Woo!
–Sam
[0] https://phabricator.wikimedia.org/T95296 [1] https://gdash.wikimedia.org/dashboards/frontend/ [2] https://graphite.wikimedia.org – have a good look around frontend - navtiming [3] https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/d...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I find that site super slow to load (the graphs and images) and a bit hard to interpret. Can somebody give a little explanation about what we are seeing and what the different variables measured mean?
On Wed, Apr 15, 2015 at 7:27 PM, Jon Robson jdlrobson@gmail.com wrote:
It would be good to get desktop and mobile in the same graph so we can compare the two. If I'm reading correctly this is all rather depressing - we are pretty much the same as desktop despite being an environment which should explicitly do better?
On Wed, Apr 15, 2015 at 7:02 AM, Sam Smith samsmith@wikimedia.org wrote:
Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team picked up a spike to investigate what data, if any, we were logging
around
site speed [0], given the existence of the mobile graphs over at WMF
stats
[1].
After a little poking around I found that all of the NavigationTiming
data
that's collected by the eponymous extension is already separated out into desktop and mobile series in Graphite [2]. Any or all of these series
can be
graphed in gdash by defining our own graphs [3].
With this in mind I've closed the tasks to design and implement our own event logging for site speed as invalid – don't you just love it when
work's
already done for you?
Furthermore, if we find, some time in the future, that we want do refine
the
data that's being collected, then we have a clearly defined workflow:
design
the schema with the help of analytics, instrument the schema, and then define a graph. You'll note that only the first step requires
collaboration
(i.e. synchronisation) with another team. Woo!
–Sam
[0] https://phabricator.wikimedia.org/T95296 [1] https://gdash.wikimedia.org/dashboards/frontend/ [2] https://graphite.wikimedia.org – have a good look around frontend - navtiming [3]
https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/d...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Sorry Joaquin, I should've also included a link to the NavigationTiming schema, which provides good documentation for all of the things that the extension captures: https://meta.wikimedia.org/wiki/Schema:NavigationTiming.
It might also be prudent to include this documentation alongside the graphs…
–Sam
On Wed, Apr 15, 2015 at 7:30 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I find that site super slow to load (the graphs and images) and a bit hard to interpret. Can somebody give a little explanation about what we are seeing and what the different variables measured mean?
On Wed, Apr 15, 2015 at 7:27 PM, Jon Robson jdlrobson@gmail.com wrote:
It would be good to get desktop and mobile in the same graph so we can compare the two. If I'm reading correctly this is all rather depressing - we are pretty much the same as desktop despite being an environment which should explicitly do better?
On Wed, Apr 15, 2015 at 7:02 AM, Sam Smith samsmith@wikimedia.org wrote:
Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team picked up a spike to investigate what data, if any, we were logging
around
site speed [0], given the existence of the mobile graphs over at WMF
stats
[1].
After a little poking around I found that all of the NavigationTiming
data
that's collected by the eponymous extension is already separated out
into
desktop and mobile series in Graphite [2]. Any or all of these series
can be
graphed in gdash by defining our own graphs [3].
With this in mind I've closed the tasks to design and implement our own event logging for site speed as invalid – don't you just love it when
work's
already done for you?
Furthermore, if we find, some time in the future, that we want do
refine the
data that's being collected, then we have a clearly defined workflow:
design
the schema with the help of analytics, instrument the schema, and then define a graph. You'll note that only the first step requires
collaboration
(i.e. synchronisation) with another team. Woo!
–Sam
[0] https://phabricator.wikimedia.org/T95296 [1] https://gdash.wikimedia.org/dashboards/frontend/ [2] https://graphite.wikimedia.org – have a good look around frontend - navtiming [3]
https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/d...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l