Page MenuHomePhabricator

Capture network performance information from navigator.connection
Closed, DeclinedPublic


Do we need to spend more of our time on optimization work? should we make bandwidth saving technologies from zero and mobile available to desktop users? or can we use more bandwidth, have larger images, prefetch content and use webfonts. Do we need to explore local storage options and offline drafts to align with how our users are experiencing the site?


  • Ability to segment data based on geo region, and device class, and zero user status


  • Check connection speed again during session after predefined time
  • Check connection speed again after change of network connection type (limited support at this time)
  • Set flag/cookie per session for poor connection users in order to deliver optimized low bandwidth experience


Event Timeline

Old multimedia card for this (never got around to do it): #361

Boomerang (by Yahoo) seemed like an interesting library which can do bandwidth measurement amongst other things, if you want to spare the effort of developing this in-house.

Nice, if the license is compatible and it does what we need that could save some time.

We already have something for measuring the time different interactions take. Check out the NavigationTimings schema.

@Ironholds, that seems to tie more into the Time on Task measurements that we'll use for REFLEX right? This task is just general connection speed, not task completion speed. Based on looking at NavigationTimings It looks like that will be great to compare with the ToT information generated by Loop11 or UserZoom

Too many keywords. What's Loop11, what's UserZoom? And, check out the MaxMind Netspeed database, which is part of a suite we already use and have integrated and called on every page.

@Ironholds were you at yesterday's metrics meeting? Loop11 and UserZoom are two software packages that the UX Design Research team are evaluating for task testing with users. See T792: UX Testing Environment (Tracking) {panda}

We already have something for measuring the time different interactions take. Check out the NavigationTimings schema.

Also, there is MultimediaViewerNetworkPerformance and ImageMetricsLoadingTime. None of these directly measures network latency and bandwidth, though.

It seems like those tools and schemas might be relevant to @ori's work as they relate to perceived performance. But are not currently in scope for the FINCH work, as it doesn't deal with perceived load time.

So you care about the perception of speed, rather than actual speed? Would suggest specifying that in the description, then.

@Ironholds no, this task is about actual speed, not perceived speed. This would be used for automatically enabling things like image compression, more aggressive lazy loading of large content, etc.

Oh, gotcha; sorry, misread. I thought you meant NavigationTimings didn't deal with actual speed.

*goes to get reading glasses* ;p

NavigationTiming contains a lot of different things, none of which I would call "perceived" (although I guess first paint time is a passable metric for perceived performance). Some of it is low-level network stuff that measures network speed in some way, but unrelated to bandwidth (DNS lookup time, connection setup time etc). Some of it measures when the browser is done processing/displaying the document, and as such heavily influenced by type of content, head-loaded scripts and other aspects of document processing (domready, load event, first paint time etc). responseEnd measures how long it took to download the document, but the document size is not logged, and loading time is affected by parallel loading so also not useful for determining the bandwidth.

There is an old PR ( ) to add bandwidth information (as reported by the browser), I'll dust that down, but browser support for the Connection API is poor so that will be of limited use.

The other two schemas use the ResourceTiming API to measure loading times and ImageMetrics also logs file sizes, but they are misleading due to heavy parallel loading.

So while all of the above are useful, I think proper bandwidth measurement is still a missing piece of the puzzle.

Looks like that task needs a bit of clarification and consensus-building first. Maybe start with an page?

If you mean working on the metrics in general, I would like to add/improve the multimedia-related ones, yes.

Tgr added a subscriber: Gilles.

After discussion with Gilles, I'm promoting this to a hackathon project.

Change 132915 had a related patch set uploaded (by Gergő Tisza):
[WIP] Add network information from navigator.connection

We are trying to help all open tasks listed under "Work continues after Lyon" at the Wikimedia Hackathon 2015 workboard finding their best way forward. * If you are participating in Wikimania, consider adding the #Wikimania-Hackathon-2015 project to get this task in that loop, which is about to start. * If you think this project could welcome help from a dedicated Google Summer of Code or Outreachy intern, or from an Individual Engagement Grant, add the Possible-Tech-Projects project. * If you would like to receive some other type of support (organizing a Tech Talk, establishing contacts with existing developer teams in Wikimedia or elsewhere, travel sponsorship for a related activity... you name it), please create a subtask explaining your request and associate it with Developer-Advocacy (or you can start by commenting here if you prefer). * Keeping the description, priority and assigned fields up to date always helps. :) For some context about this message, see T101151: Evaluate which projects showcased at the Wikimedia Hackathon should be supported further. It is the last communication related to Wikimedia-Hackathon-2015 that we will post here.

ori renamed this task from Capture connection speed and latency of web users to Capture network performance information from navigator.connection.Jun 6 2016, 6:40 PM
ori moved this task from Inbox to Blocked (old) on the Performance-Team board.

Blocked on upstream (browsers and web platform specs). Given this is currently only for telemetry and no longer blocking user-facing features (those were all cancelled or changed to use server-side mechanisms instead). Closing this for now as inactionable.

Change 132915 abandoned by Krinkle:
[DNM] Add network information from navigator.connection

Superseded by I8f565e53eb680c26b7940d9348cfc9a61eb6835f