[EPIC] Monitor complex pages rendering time on mobile web
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	pmiazga
	Apr 30 2019, 11:30 AM

Description

Both MobileFrontend and Minerva skin do complex DOM processing before the page is presented to the user. Includes but not limited to the following

MobileFrontend transformations
Sections parsing
Minerva PageIssues parsing

Some time ago we observed T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages which could be easily caught by automated systems. Systems can easily detect big changes in render time (like rendering time went double), and we should aim for that.

Open questions

We develop features gradually, adding bits one by one. It's possible that each commit will only slightly increase render time, but in one month window the render time will double. To avoid Boiling frog, tools should provide us a graph that can present the constant increase of render time, or a tool that compares today render time with the render time saved ~month ago.

How to monitor such things? Possible tools:

T133646: Run performance test on commits (Fresnel)
Use Grafana to monitor render time of complex pages? (same as we monitor Barack Obama)
something different?

How to define "a complex page"?

Acceptance criteria

There is a tool/graph that provides us information about changes in rendering time of complex pages

Related Objects
Search...

Status	Subtype	Assigned	Task
Resolved		Jdlrobson	T222163 [EPIC] Monitor complex pages rendering time on mobile web
Resolved	PRODUCTION ERROR	Jdlrobson	T204606 [Spike, 8hrs] Some requests time out after 60 seconds in MobileFrontend transforms. What to do?
Resolved		• nray	T220751 [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages

Event Timeline

pmiazga created this task.Apr 30 2019, 11:30 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 30 2019, 11:30 AM

pmiazga renamed this task from Monitor complex pages rendering time to Monitor complex pages rendering time on mobile web.Apr 30 2019, 11:51 AM

thanks for writing this up @pmiazga !

It's marked "scratch" (not sure what that means) but we have https://grafana.wikimedia.org/d/000000205/mobile-2g which measures back end response time (which includes MobileFormatter.)

Measuring page issues/section parsing sounds a little different and I'm not sure how to do that other than lool at extremes for measuring first interactive.

Defining complex pages seems like looking at the extremes of all these values to me?

See also T204606 which talks about the php transformations and a few propsals on how we can avoid these extremes.

ovasileva moved this task from Needs Prioritization to Incoming on the Web-Team-Backlog board.May 1 2019, 4:13 PM

Jdlrobson renamed this task from Monitor complex pages rendering time on mobile web to [EPIC] Monitor complex pages rendering time on mobile web.May 1 2019, 6:15 PM

Jdlrobson added subtasks: T204606: [Spike, 8hrs] Some requests time out after 60 seconds in MobileFrontend transforms. What to do?, T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages.

Jdlrobson moved this task from Incoming to Epics/Goals on the Web-Team-Backlog board.

Jdlrobson triaged this task as Low priority.May 2 2019, 8:59 PM

Peter subscribed.May 3 2019, 11:49 AM

• nray closed subtask T220751: [Bug] Extreme latency due to JavaScript parsing on DOM-heavy pages as Resolved.Jun 24 2019, 7:09 PM

Jdlrobson closed subtask T204606: [Spike, 8hrs] Some requests time out after 60 seconds in MobileFrontend transforms. What to do? as Resolved.Sep 12 2019, 3:31 PM

nothing to do with Minerva skin.

Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptJan 17 2020, 10:38 PM

We have some CPU time spent for the URLs we test today (like spent parsing HTML, style etc), checkout https://grafana.wikimedia.org/d/000000059/webpagereplay-drilldown?orgId=1&var-base=sitespeed_io&var-path=emulatedMobileReplay&var-group=en_m_wikipedia_org&var-page=_wiki_Barack_Obama&var-browser=chrome&var-connectivity=100&var-function=median and scroll down to the CPU section. That is collected on a AWS server, where we slowdown the CPU to try to look more like what it is on a mobile phone. It's not perfect but will work until we can use real phones.

One problem today I think is that we just test on a couple of pages for each wiki. For catching things like T220751 there's two ways: First we need to collect CPU long tasks from Chrome in our RUM data. We can do that when Chrome 81 is released, since then it will be easy for us to enable that. Then we can get long CPU tasks from the users. However that data is hard to understand, since we miss out on what is causing the long task.

The other is to add more synthetic testing where we crawl/walk around the Wikipedia and test different pages as in T235817. That way we can find pages with problems and that way also record much more data (like a devtools log) so its easier for us to understand what goes wrong so we can act on that.

Jdlrobson moved this task from Backlog to team:other on the MobileFrontend board.Jul 24 2020, 2:53 AM

Unless performance team want to evolve this into something else I think we should resolve based on https://phabricator.wikimedia.org/T222163#5816108

Seems out of scope for web...

per above

[EPIC] Monitor complex pages rendering time on mobile webClosed, ResolvedPublicActions