FYI: UseCounter data

[Ojan Vafai]

We don't yet have it setup to make the UseCounter data publicly visible, but as a one off, I thought I'd share the data from the latest stable Windows release in case this helps in people's efforts removing unused features. This is from 32.0.1700.107 on Windows. The numbers are percent of pageviews.

LegacyNotifications	0.6086199685
PrefixedIndexedDB	0.6236848534
WorkerStart	0.2632824909
SharedWorkerStart	0.001809748484
LegacyWebAudioNoteOn	0.004003459452
WebAudioStart	0.003562141576
PrefixedContentSecurityPolicy	0.03688389821
UnprefixedIndexedDB	2.228044874
OpenWebDatabase	0.4753322117
LegacyTextNotifications	0.002952674155
UnprefixedRequestAnimationFrame	6.060231102
PrefixedRequestAnimationFrame	0.4128996729
ContentSecurityPolicy	19.499411
ContentSecurityPolicyReportOnly	0.009819455496
PrefixedContentSecurityPolicyReportOnly	0.003930769459
PrefixedTransitionEndEvent	0.4520534904
UnprefixedTransitionEndEvent	0.2037969836
PrefixedAndUnprefixedTransitionEndEvent	0.2842263034
AutoFocusAttribute	0.7927678181
DataListElement	1.772513018
FormAttribute	0.05811628007
IncrementalAttribute	0.005831529797
InputTypeColor	0.0007192658214
InputTypeDate	0.0095114358
InputTypeDateTimeFallback	0.0004612329421
InputTypeDateTimeLocal	0.000174190449
InputTypeEmail	0.7666448933
InputTypeMonth	0.00005071703623
InputTypeNumber	0.07283616961
InputTypeRange	0.1232676902
InputTypeSearch	1.109772263
InputTypeTel	0.08612170968
InputTypeTime	0.0007430311342
InputTypeURL	0.01329264311
InputTypeWeek	0.00002502660034
ListAttribute	0.01187694741
MaxAttribute	0.3605663963
MinAttribute	0.2137948781
PatternAttribute	0.3431861857
PlaceholderAttribute	15.04775773
PrecisionAttribute	0.000926515281
PrefixedDirectoryAttribute	0.002609471174
PrefixedSpeechAttribute	0.5641291123
RequiredAttribute	2.11655064
ResultsAttribute	0.08427505194
StepAttribute	0.2706361956
HTMLMarqueeElement	0.430249347
Reflection	0.09669873431
StorageInfo	0.1971222499
XFrameOptions	28.54020299
XFrameOptionsSameOrigin	3.246632022
XFrameOptionsSameOriginWithBadAncestorChain	0.1202702735
DeprecatedFlexboxWebContent	1.305963484
DeprecatedFlexboxChrome	0.01057410375
DeprecatedFlexboxChromeExtension	0.05644706557
UnprefixedPerformanceTimeline	5.870099638
PrefixedPerformanceTimeline	0.0006360208431
UnprefixedUserTiming	0.004726110834
WindowEvent	7.641600241
ContentSecurityPolicyWithBaseElement	0.1843845069
WebAudioLooping	0.000005111533756
DocumentClear	0.007295619108
PrefixedTransitionMediaFeature	0.00001281202617
SVGFontElement	0.02701598272
XMLDocument	1.490081925
XSLProcessingInstruction	0.008820515757
XSLTProcessor	0.0149441332
SVGSwitchElement	0.02420304595
Document.all()	16.54910315
FormElement	47.02178706
DemotedFormElement	1.028285188
ShadowDOMPrefixedPseudo	0.5354469024
ShadowDOMPrefixedCreateShadowRoot	0.004781408336
ShadowDOMPrefixedShadowRoot	0.7448633867
SVGAnimationElement	5.404070019
KeyboardEventKeyLocation	0.54698848
CaptureEvents	0.4734073542
ReleaseEvents	0.01698409985
LineClamp	0.05267017319
SubFrameBeforeUnloadRegistered	6.557756266
SubFrameBeforeUnloadFired	19.98193314
CSSPseudoElementPrefixedDistributed	0.000003186410653
TextReplaceWholeText	0.000002323424435
ConsoleMarkTimeline	0.05641473678
CSSPseudoElementUserAgentCustomPseudo	0.00001015668396
DocumentTypeEntities	0.00001832186126
DocumentTypeInternalSubset	0.00003126665453
DocumentTypeNotations	0.00001832186126
ElementGetAttributeNode	7.163385257
ElementSetAttributeNode	0.1286837253
ElementRemoveAttributeNode	0.0005441460026
ElementGetAttributeNodeNS	0.0001162376053
DocumentCreateAttribute	0.1865156846
DocumentCreateAttributeNS	0.00008410796453
DocumentCreateCDATASection	0.004697433138
DocumentInputEncoding	0.7960931031
DocumentXMLEncoding	0.01673549344
DocumentXMLStandalone	0.01529470475
DocumentXMLVersion	0.7514210862
NodeIsSameNode	0.1191746793
NodeIsSupported	0.00000126128755
NodeNamespaceURI	0.1656014791
NodePrefix	0.01962324447
NodeLocalName	0.1615086674
NavigatorProductSub	2.98428627
NavigatorVendor	8.991713104
NavigatorVendorSub	2.550895454
FileError	0.001115708414
DocumentCharset	5.28771299
PrefixedAnimationEndEvent	0.3723837312
UnprefixedAnimationEndEvent	0.0000003319177764
PrefixedAndUnprefixedAnimationEndEvent	0.000002655342211
PrefixedAnimationStartEvent	0.05601636906
UnprefixedAnimationStartEvent	0.00000006638355528
PrefixedAndUnprefixedAnimationStartEvent	0.00001214819062
PrefixedAnimationIterationEvent	0.002160585574
PrefixedAndUnprefixedAnimationIterationEvent	0.0000001327671106
EventReturnValue	27.47536795
SVGSVGElement	10.6019334
SVGAnimateColorElement	0.00003199687364
InsertAdjacentText	0.0002458183052
InsertAdjacentElement	0.03309319806
HasAttributes	0.002769654693
DOMSubtreeModifiedEvent	1.466329491
DOMNodeInsertedEvent	2.253418993
DOMNodeRemovedEvent	0.1139530816
DOMNodeRemovedFromDocumentEvent	0.1248658743
DOMNodeInsertedIntoDocumentEvent	0.09918114736
DOMCharacterDataModifiedEvent	0.1973025476
DocumentAllTags	0.006758310612
DocumentAllLegacyCall	0.03024009924
HTMLAppletElementLegacyCall	0.000025225751
HTMLEmbedElementLegacyCall	0.00003996290028
HTMLObjectElementLegacyCall	0.07257734013
BeforeLoadEvent	0.714154686
GetMatchedCSSRules	0.7722247631
SVGFontInCSS	0.2483694916
ScrollTopBodyNotQuirksMode	20.40582321
ScrollLeftBodyNotQuirksMode	20.81758102
AttributeIsId	0.01169333049
AttributeOwnerElement	0.0107289102
AttributeSetPrefix	0.000001194903995
AttributeSpecified	8.388126071
BeforeLoadEventInIsolatedWorld	0.8519965538
PrefixedAudioDecodedByteCount	0.4331989011
PrefixedVideoDecodedByteCount	0.4331989011
PrefixedVideoSupportsFullscreen	0.009200893528
PrefixedVideoDisplayingFullscreen	0.001510093115
PrefixedVideoEnterFullscreen	0.0003490447336
PrefixedVideoExitFullscreen	0.0003053643543
PrefixedVideoEnterFullScreen	0.00002037975147
PrefixedVideoExitFullScreen	0.00001725972437
PrefixedVideoDecodedFrameCount	0.4653841049
PrefixedVideoDroppedFrameCount	0.4331664396
SourceElementCandidate	0.2843894742
SourceElementNonMatchingMedia	0.00001878654614
PrefixedElementRequestFullscreen	0.08616353132
PrefixedElementRequestFullScreen	0.007555643494
BarPropLocationbar	1.550558207
BarPropMenubar	0.8527614915
BarPropPersonalbar	0.4168445821
BarPropScrollbars	0.4229256476
BarPropStatusbar	0.451127639
BarPropToolbar	0.4198345638
input[type=email][multiple]	0.0001362190554
input[type=email][maxlength]	0.2168716231
input[type=email][multiple][maxlength]	0.000006372821306
TextTrackCueConstructor	0.001830792071
CSSStyleDeclarationPropertyName	3.323695297
CSSStyleDeclarationFloatPropertyName	0.7980903852
InputTypeText	36.8107985
InputTypeTextMaxLength	12.10201335
InputTypePassword	5.187048303
InputTypePasswordMaxLength	1.212224261
SVGInstanceRoot	0.0000001991506658
ShowModalDialog	0.006267935289
CSSStyleSheetInsertRuleOptionalArg	0.08319877536

[Adam Barth]

ShowModalDialog 0.006267935289

That's much lower than I would have expected.  Note that Firefox recently deprecated ShowModalDialog as well:

https://developer.mozilla.org/en-US/docs/Web/API/Window.showModalDialog

Adam

[kaust...@samsung.com]

This is one good detailed and most informative post for us. I guess there are lot more things to clean up !! :

[Philip Jägenstedt]

Thank you Ojan!

Sorting the counters by usage shows that there are 61 counters under 0.01%, so there are many red diffs waiting to happen here!

A dump like this a few weeks after each stable release would be very useful for non-Googlers like me who add a lot of counters.

Philip

[Paul Irish]

I threw this data into Google Spreadsheets and added a few charts:

https://docs.google.com/spreadsheets/d/1WfPZHzs22gguQ3mi0_56S19r8G8ugyrTWcMJ0Cs85Lo/edit#gid=693059823

Useful if you want to play around with it some. (File > Make a copy)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Erik Dahlström]

On Sat, 08 Feb 2014 00:43:15 +0100, Ojan Vafai <oj...@chromium.org> wrote:

> We don't yet have it setup to make the UseCounter data publicly visible,
> but as a one off, I thought I'd share the data from the latest stable
> Windows release in case this helps in people's efforts removing unused
> features. This is from 32.0.1700.107 on Windows. The numbers are percent
> of
> pageviews.

Thank you for publishing this data, this should all be out in the open.

Since the UseCounter data shouldn't be confidential, I'd like to ask for
it to be published on chromestatus.com (with regular updates as new data
arrives).

Additionally I'd like to request the following:

- UseCounter results per channel (if possible), dev, beta, stable
- relative scores for features depending on some other feature, say of
feature X how large a percentage also uses sub-feature Y (preferably with
client-side computation)
- results particular to a given geographic region
- (if available) what sites/urls where the top hits
- (if available) top matching js frameworks


--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

[Eric Seidel]

I agree this would be nice, but I don't believe we're likely to have
an automated system any time soon.

Opera also uses the Chromium Content layer. Do you know if Opera
implements the Histogram callbacks to record this data from Opera
browsers? If so, could they share such publicly as well?

[Jiang Jiang]

On Mon, Feb 10, 2014 at 10:01 AM, Eric Seidel <ese...@chromium.org> wrote:
> I agree this would be nice, but I don't believe we're likely to have
> an automated system any time soon.
>
> Opera also uses the Chromium Content layer. Do you know if Opera
> implements the Histogram callbacks to record this data from Opera
> browsers? If so, could they share such publicly as well?

It's not implemented but we are considering that possiblity. (Can't
comment on the sharing policy though.)

- Jiang

[Philip Jägenstedt]

On Mon, Feb 10, 2014 at 4:01 PM, Eric Seidel <ese...@chromium.org> wrote:
> I agree this would be nice, but I don't believe we're likely to have
> an automated system any time soon.
>
> Opera also uses the Chromium Content layer. Do you know if Opera
> implements the Histogram callbacks to record this data from Opera
> browsers? If so, could they share such publicly as well?

We don't collect UseCounter data. We've talked about it, but we assume
that Chrome stats will be required for feature removal anyway, so it
hasn't been prioritized. It would be interesting though, since the
market share ratio between Chrome and Opera is not constant across the
globe...

Philip

[Dirk Schulze]

Is there a policy to remove use counters again? For features that are used on less than 1% of all pages it is no big deal to keep them and track the usage over time. But what about features like the form element with a usage of 47%?

Greetings,
Dirk

[Daniel Bratell]

On Sat, 08 Feb 2014 00:43:15 +0100, Ojan Vafai <oj...@chromium.org> wrote:

> We don't yet have it setup to make the UseCounter data publicly visible,
> but as a one off, I thought >I'd share the data from the latest stable
> Windows release in case this helps in people's efforts >removing unused
> features. This is from 32.0.1700.107 on Windows. The numbers are percent
> of pageviews.

Big thanks for publishing these! I, as others, wish they were available
live but this is much better than nothing.

A question about what is counted though.

If I make a page (let us call it cnn.com) that reloads itself every minute
and I have that in a background tab, would that page be affecting the
numbers so that it looks like everything it uses is much more common,
while a static site would only count once?

The reason I ask is that my experience with web features is that very
rarely used features (say for instance the <keygen> tag) can at times
become a reason that a user can't use a specific browser. So I'm worried
that underestimating feature use will make us remove things that are
needed.

Do we expect to catch such things through bug reports during development
and beta phases?

It would be nice if a counter could list some example sites using that
feature (yes, I know that data isn't available through the counter itself
but maybe it could be fetched from some other source). If the sites are
just demo and test pages that would support removal. If it's
"bank.com/registerAccount" then it would discourage removal.

/Daniel

[PhistucK]

Getting such data kind of defeats the anonymity, I believe. I think we had this discussion a few months ago already.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

On Mon, 10 Feb 2014 12:19:02 +0100, PhistucK <phis...@gmail.com> wrote:

> Getting such data kind of defeats the anonymity, I believe. I think we
> had this discussion a few >months ago already.

Getting that data directly from a user would be bad, yes, but Google has
access to, and owns, a lot of other information sources which could be
used to locate usages of APIs. I'm not saying it would be easy, just that
it would be nice and make it even easier to make a confident decision
whether a feature can be removed or not.

/Daniel

[PhistucK]

How can you correlate visited sites (Google does not have this data, only possibly in Sync, which is private) with anonymous metrics?

Or do you mean general Google data regarding search result clicks? even so.

☆PhistucK

[Daniel Bratell]

On Mon, 10 Feb 2014 13:56:52 +0100, PhistucK <phis...@gmail.com> wrote:

> How can you correlate visited sites (Google does not have this data,
> only possibly in Sync, which is >private) with anonymous metrics?
>
>
> Or do you mean general Google data regarding search result clicks? even
> so.

Say you have an API navigator.makeFunnySoundEffectsWhenMouseMoves() that
you think could be removed. Use counter says it's used 0.00001% of the
page views (still not sure if a constantly reloading page counts as one
page view or a thousand) so it's a candidate for removal.

What I would find nice is if someone could publish some examples of sites
that are using makeFunnySoundEffectsWhenMouseMoves(). That data could be
fetched from text found by the Google Crawler for instance, and it could
be further filtered through the site rankings that Google also maintain.
If it turns out the only site that uses it is a demo page, then that would
further support the removal. If on the other hand it's used by the biggest
bank in Angola, dropping it might mean losing all users in Angola so it
should be investigated further.

I know this is not a trivial thing, which is why I say that it would be
nice to have such information rather than requesting it.

/Daniel

[PhistucK]

Right, so you referred to data unrelated to Chrome and so there is no correlation, which sounds great.

:)

☆PhistucK

[Ojan Vafai]

On Mon, Feb 10, 2014 at 12:43 AM, Erik Dahlström <e...@opera.com> wrote:

- UseCounter results per channel (if possible), dev, beta, stable

The way the data is stored, it's hard to get exactly this data. We get data per version/OS combination. That's why I just posted the Win stable channel numbers.

On Mon, Feb 10, 2014 at 2:55 AM, Daniel Bratell <bra...@opera.com> wrote:

On Sat, 08 Feb 2014 00:43:15 +0100, Ojan Vafai <oj...@chromium.org> wrote:

We don't yet have it setup to make the UseCounter data publicly visible, but as a one off, I thought >I'd share the data from the latest stable Windows release in case this helps in people's efforts >removing unused features. This is from 32.0.1700.107 on Windows. The numbers are percent of pageviews.

Big thanks for publishing these! I, as others, wish they were available live but this is much better than nothing.

Yeah. I hear you. Hopefully we can make that happen, but I don't think it's at the top of anyone's TODO list at the moment.

 

A question about what is counted though.

If I make a page (let us call it cnn.com) that reloads itself every minute and I have that in a background tab, would that page be affecting the numbers so that it looks like everything it uses is much more common, while a static site would only count once?

Correct. Open to suggestions of what a better metric might be. This was the best we could come up with.

 

The reason I ask is that my experience with web features is that very rarely used features (say for instance the <keygen> tag) can at times become a reason that a user can't use a specific browser. So I'm worried that underestimating feature use will make us remove things that are needed.

Do we expect to catch such things through bug reports during development and beta phases?

Yes. Although, that's a poor answer. We don't do as good of a job as we should of catching these sorts of bugs in a timely manner and dealing with them. Also, we're relying on the bugs to be filed in the first place. Often, bugs don't get filed/noticed until the release hits the stable channel or they don't get filed at all.

In short, we don't have a great answer here. Again, open to suggestions.

 

It would be nice if a counter could list some example sites using that feature (yes, I know that data isn't available through the counter itself but maybe it could be fetched from some other source). If the sites are just demo and test pages that would support removal. If it's "bank.com/registerAccount" then it would discourage removal.

We don't have a good way to do this at the moment. We've certainly talked about it, but getting it setup would be a significant effort, so not terribly likely to happen.

So far, it's been extremely rare that removing an API has resulted in bugs getting filed and fixed. It has happened a couple times. It's also happened that we've pushed on websites to change their code in at least one case (WebkitBlobBuilder). Hard to say whether we're not breaking sites or if we're breaking sites and just not noticing. That said, we've been very conservative up to now in terms of what APIs we remove. The vast majority of what we've removed has been <0.001% usage IIRC. So, it's hard to say what would happen if we were more aggressive.

[Max Heinritz]

On Mon, Feb 10, 2014 at 12:57 PM, Ojan Vafai <oj...@chromium.org> wrote:

On Mon, Feb 10, 2014 at 12:43 AM, Erik Dahlström <e...@opera.com> wrote:

- UseCounter results per channel (if possible), dev, beta, stable

The way the data is stored, it's hard to get exactly this data. We get data per version/OS combination. That's why I just posted the Win stable channel numbers.

On Mon, Feb 10, 2014 at 2:55 AM, Daniel Bratell <bra...@opera.com> wrote:

On Sat, 08 Feb 2014 00:43:15 +0100, Ojan Vafai <oj...@chromium.org> wrote:

We don't yet have it setup to make the UseCounter data publicly visible, but as a one off, I thought >I'd share the data from the latest stable Windows release in case this helps in people's efforts >removing unused features. This is from 32.0.1700.107 on Windows. The numbers are percent of pageviews.

Big thanks for publishing these! I, as others, wish they were available live but this is much better than nothing.

Yeah. I hear you. Hopefully we can make that happen, but I don't think it's at the top of anyone's TODO list at the moment.

Yes, it's something we'd like to do for chromestatus.com; it just hasn't been high priority for anyone to implement.  Here's the tracking issue: https://github.com/GoogleChrome/chromium-dashboard/issues/93