Maybe we can work our way out of this by telling Google that they can't display our URL for content that comes from their servers without our approval? There might be legal grounds for this, even.
@Peter can probably provide a screenshot of the settings where this is enabled, where it’s indeed not mentioned anywhere that enabling it means Google gets to intercept full URLs of everything you visit. In fact Google misleads the user into thinking that we served the request, since our domain is displayed in the URL bar, not Google’s.
This has been done a while ago.
Tue, Mar 19
Mon, Mar 18
Filed a github issue about the spec: https://github.com/WICG/element-timing/issues/1
Stats to consider, as of May 2017 (last time we ran this analysis):
I'm glad that the issue has been acknowledged by Mozilla. Thanks for your thorough reporting work both on our end and theirs, @Jc86035
Fri, Mar 15
As far as I can tell, all it would take is uncommenting one line of yaml in hieradata/role/common/cache/upload.yaml
Thu, Mar 14
Wed, Mar 13
Yes, that user timing is present when a banner is really displayed to the user, great idea!
There's an example in puppet/modules/acme-chief/manifests/server.pp using the check_file_age plugin.
Tue, Mar 12
Mon, Mar 11
No ICC profile in any of these, because SVGs don't have color profiles.
Certainly. You should provide the identical webp and png after having verified that they contain the same color information in GIMP, Photoshop or any tool of that nature, and a screenshot showing that they render differently side-by-side in Firefox.
We should expect browsers to render identical color information identically, irrespective of the image format it's expressed in... What we get from GIMP by looking at the files directly is the reference and we're getting identical color values between the 3 formats we're serving. If there are color rendering discrepancies when displayed, it's a browser bug.
Using one of the files you've mentioned https://commons.wikimedia.org/wiki/File:BSicon_exSTR.svg
Fri, Mar 8
All changes have been deployed. The next phase will be moving current firstPaint recordings from the NavigationTiming schema to the PaintTiming one. And it should all magically go to the right place with dashboard unchanged.
Yes, that's where I plan on sending these to. Specifically to /srv/published-datasets/performance/autonomoussystems/
Thu, Mar 7
I can live with the cron being under my user. The script is indeed writing to the datasets mount with the --publish option. Then the performance site pulls the tsv from there with a bit and publishes it in a more human-friendly form at https://performance.wikimedia.org/asreport/
Tried it with sync-xhr, couldn't get it to work. Left a comment on the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=867471&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=
Looks like @ReleaseTaggerBot is wrong, the typo fix patch did make it to the 1.33.0-wmf.20 branch.
@Nuria what do you recommend to deploy this on stat machines? scap?
Wed, Mar 6
In order to maintain our existing dashboards, particularly the breakdown ones, we could have the navtiming collector still write the metrics coming from the new schema to frontend.navtiming2. However, in order for oversampling to be accounted for and not have an oversampling campaign mess with the overall firstPaint metrics, we need to make the PaintTiming schema oversampling-aware.
Tue, Mar 5
@Milimetric is the data for "duration" in Hive currently stored as integer?
Mon, Mar 4
The reporting script is getting very close to being finalised and ready for review. However, generating the numbers for February, I notice that the only 2 countries where there's enough data for the average transferSize to be stable across ISPs are France and Russia. Which have been getting more CPU benchmark runs thanks to the performance survey. Since we haven't had complaints in those countries, I think it's time to run the CPU benchmark more often across the board.
Currently we're only using Server-Timing to pass Varnish caching information, which doesn't use the duration field.
It's a classic "let's rename this variable at the last minute" typo on the core patch...
Not working right:
Yes, exactly, comparing 72 and 73 on a popular ruwiki article should do it.
Fri, Mar 1
I'll launch this on Monday. We won't get much data until Chrome 73 graduates to stable on March 12, though.
Data is coming in:
You can't check things server side on a pageview coming from Varnish, that's the issue here. A realistic pageview from a reader is one that only hits our edge cache layer. It needs to be a signal that the CentralNotice client side code can see and act upon.
Thu, Feb 28
The explanation is that we lost most of Safari in navtiming during that deployment because of T217210: Nav timing throws exception on Safari "TypeError: entryTypes contained only unsupported types"
Yes, you can go ahead and switch Thumbor to Mcrouter. Thumbor uses memcached for non-critical request throttling. Memcached can be down for a bit and Thumbor will continue working normally, albeit without some types of throttling working.
Wed, Feb 27
@jijiki I don't believe this is blocked by the Buster upgrade, is it? Would be nice if you can make some room for it in your Q4 goals.
Did something happen on 2019-02-21? I was looking at the ulsfo RUM perf metrics for the change in that DC. No change is apparent after the 2019-02-19 config change, except that particular day (the 21st) that stands out as having noticeably bad performance for ulsfo. Pretty much the same TTFB as esqin users on that day.
It's definitely real. The paint entryType is part of the Paint Timing spec, and not the PerformanceObserver spec itself. It's perfectly valid for a browser to implement the latter and not the former.
Tue, Feb 26
We do use rsvg-convert, Stretch is on libsrvg 2.40.16-1. This is very likely to be something that would be fixed by a librsvg upgrade.