Wed, Sep 11
@Jdlrobson This recently merged change is likely the cause of T231895: Media viewer on 3D files closes when releasing drag
Mon, Sep 9
The device emulation is a bit of a black box. It might be good to verify that there wasn't a system update on the host around that time or something like that. I imagine that updating some linux library on the system could have a side-effect like this for example. Or a hardware incident of some kind on the host.
Comparing a run today and one from September 2, I see the exact same requests before reaching the first render. The bandwidth graph up to that point is pretty much the same as well. The only different seems to be that the browser main thread just takes a lot longer to run before reaching the initial render:
Sure, why not. You can link to historic revisions of the Obama article, when it got the extra errors due to the template update, and when an editor fixed them.
Fri, Sep 6
The editors replied, this gets cleaned up by "bots and gnomes". These spikes happen regularly upon changes to those templates, this one was just bigger than usual. I'm closing this, as this is a very likely explanation, based on the rise and drops corresponding exactly for the Barack Obama article.
So yes, the bulk of the errors on the Sweden article are cs1-hidden-error, which are not shown to readers. There's still 300+ of them.
Left a note on the responsible editor's page https://en.wikipedia.org/wiki/User_talk:Trappist_the_monk#Significant_HTML_size_increase_due_to_September_3_Cite_template_change
Yes, I noticed that error coming up a lot when inspecting the current HTML manually. It seems to be coming from a template: https://en.wikipedia.org/wiki/Help:CS1_errors#missing_periodical
Thu, Sep 5
I'm out of ideas on how to get the HTML diff. My only hope is that Peter's private set up saved that data...
Looking at the webpagereplay host, we don't see to keep any data there besides the most recent run.
Wed, Sep 4
Besides the fact that some code was updated (version module version changes), I notice that the slower recent runs have an extra request that older ones don't have:
This should probably be its own task, though, it's not specific to piwik.js
Or I guess, to be conservative, add Wikimedia wiki login cookies to the filter only if you're in the context of a non-wiki site.
I think the issue is that misc_recv_pass is applied to every site. You want it to apply to wikis (where people can log in), but not on non-wiki websites we serve.
While the caching header is correctly served, when the request is in the context of the foundation website, Varnish is doing a pass:
Tue, Sep 3
My twitter post about it was quite popular: https://twitter.com/fullstackjerk/status/1168506925425860610?s=20
This is now slide-ified and ready to go.
Done at the last meeting
Mon, Sep 2
Wed, Aug 28
Mon, Aug 26
Let's look at the same data for ruwiki, out of curiosity, which gets less mobile traffic than eswiki, but still quite a bit:
|eswiki satisfaction ratio||median loadEvendEnd||median transferSize||median responseStart||median cpuscore|
Digging further into specific loadEvendEnd and cpu score slices for those weeks, the results are quite suspicious, with users in August consistently being happier by 2%, even for the same cpu score and loadEventEnd ranges. I think we can't rely just on those 2 weeks at random, and we need to look at the trend over time, by week or by month, before drawing any conclusions.
Follow-up idea: look at specific cpuscore/loadEventEnd range in April and now and see if the satisfication ratio is the same. I.e. did users' expectations evolve during that period?
Before setting up a real world study, I've decided to implement the feature locally to check that it would do what it's supposed to, if the likelihood of click after mousedown is indeed high.
This is precisely to figure out if there is a meaningful difference in practice. I don't think there would be, I expect that the first paragraph is almost always included in the first paint for us.
Fri, Aug 23
This is the actual HTML spec change proposal, I believe: https://github.com/whatwg/html/pull/3752
It's an HTML standard, so now handled by WHATWG, not the W3C.
Let's dig up some more recent numbers on mobile. At the time of the study we didn't have eswiki data, which now dwarfs anything from before in terms of mobile site data. This is looking exclusively at mobile site traffic (mobileMode == 'stable' in navtiming).
I will enable this for a short period on eswiki and ruwiki to measure the impact. But the unresolved issues around printing, especially considering how prominently we advertise printing in the sidebar, makes this new browser feature somewhat impractical for now.
If the devroom gets approved, we're supposed to run a CfP ourselves. I think we should weigh our own talk ideas against what everyone else out there will propose. Preference should go towards what's the most on topic in the context of FOSDEM. A lot of general Web Performance talks don't have any FLOSS/open standards angle.
Wed, Aug 21
Verified that it works on Chrome 78. We will need to change the observer syntax that was used for the origin trial. Aside from that, with simulated slow 3G unsurprisingly time-to-first-paragraph == FCP:
Ah, the author just emailed me a link to a new declarative version: https://github.com/WICG/display-locking/blob/master/explainer-new.md which seems like it would do what we need for the main article content.
Conceivably we could break down the page into 2 parts. The critical content, which can be left as-is. And the non-critical content (eg. article content past the first paragraph) in a separate element. That element, as soon as it's created, is locked (and disappears). Then whenever we want - for instance, once the browser has download all of it and reached another chunk of inline JS - we can ask the browser to render it cooperatively. Which should be less aggressive than the default processing/painting of DOM, which is blocking.
This seems like it might be helpful for the section expansion/collapsing of MobileFrontend: T230941: [Spike, 8hrs] Investigate using display locking when expanding/collapsing sections
The print feature in the sidebar seems to rely on a different version of the page, though (with different HTML), for which we could conceivably disable image lazy loading. The issue remains for users who invoke the browser's print feature directly themselves on an article.
Dimension information is exposed in attributes for thumbnails, for Media Viewer's sake. I don't think that Media Viewer relies on the load event to wait for anything, as users can click on thumbnails before the load event.
There isn't a lot of time left in the origin trial, but I will try to fix the entryType naming, so we can see what the data is liked now that the biggest bug has been fixed.
The name of the entry type changed in 76, which probably means we stopped collecting data. And it's going to change again in the final implementation...