Page MenuHomePhabricator

Spike: Audit HoverCards JavaScript real and perceived performance
Closed, ResolvedPublic

Description

Duration: 8hrs
Let's review the existing JavaScript code before pushing to stable.

Analyze:

  • How does it impact first render time / fully loaded load time T131314#2249996
  • How long does a hovercard take to load (especially as @Nuria points out on slow connections)
  • Which libraries does it use and which are loaded asynchronously T133947
  • Review Icon support to see if it will benefit from ResourceLoaderImageModule T133956
  • ext.popups.settings.js would benefit from template usage in settings.render T133942

Outcome:

  • Comment with results of the analysis
  • Ping by email to reading web team for attention and discussion

Event Timeline

greg removed a subscriber: greg.Mar 30 2016, 9:08 PM
Legoktm renamed this task from Audit JavaScript code to Audit hovercards JavaScript code.Mar 30 2016, 9:53 PM
Legoktm removed a subscriber: Legoktm.
Nuria added a comment.Mar 31 2016, 3:26 PM

Let's please also review how the hover works under a bad connection , i suspect that the fetch-on-hover strategy might not perform so well.

Will do! Between now and when Reading Web kicks into gear on delivery, @Prtksxna any hints on how to think about HoverCards when connections are poor?

dr0ptp4kt renamed this task from Audit hovercards JavaScript code to Audit HoverCards JavaScript real and perceived performance.Apr 4 2016, 3:39 PM

@dr0ptp4kt, I haven't thought about this problem until now. The worst I connection in which I have experienced Hovercards is while reading Wikipedia on desktop while tethering from my phone's EDGE connection (Goa doesn't have 3G everywhere yet ).

The Hovercards were slow to load but it was better than trying to load the entire article in a new tab. I was also happy that there wasn't any pre-fetching happening in the background that was secretly eating up my data plan.

I guess there would be a trade-off between better user experience and using bandwidth (usually more expensive on worse connections) without the user's knowledge. I am not aware of any smart pre-fetching strategy that could help here.

Jdlrobson updated the task description. (Show Details)Apr 5 2016, 6:01 AM
Nuria added a comment.Apr 5 2016, 3:36 PM

The Hovercards were slow to load but it was better than trying to load the entire article in a new tab. I

I think we should quantify these times with numbers.

. I am not aware of any smart pre-fetching strategy that could help here.

This requires more work that we might want to do on 1st instance but we could preload on server side, serving page with the content for the hovers of very first few links added onto the main page. You can consult on this regard with performance team

Glaisher removed a subscriber: Glaisher.Apr 18 2016, 4:25 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 5:11 PM
Jhernandez updated the task description. (Show Details)Apr 20 2016, 9:39 AM

@MBinder_WMF is this a spike? It certainly smells like one.

@Jhernandez Smells like it to me.

Jdlrobson renamed this task from Audit HoverCards JavaScript real and perceived performance to Spike: Audit HoverCards JavaScript real and perceived performance.Apr 20 2016, 3:21 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jhernandez updated the task description. (Show Details)Apr 20 2016, 5:27 PM

ext.popups.settings.js would benefit from template usage in settings.render

This seems like a statement and I'm not sure why I put it here but I agree so I've created T133942.

I'll have a look at the other points. Reach out to me if you want to help out.

> How does it impact first render time / fully loaded load time
Using the script P2972 on webpagetest.org I created two users - one with Hovercards enabled and one without. I ran tests on 2G and 3G connections (note be sure to tick the sensitive data box).

With Popups:
2G: http://www.webpagetest.org/result/160428_YN_1FSM/
3G: http://www.webpagetest.org/result/160428_D4_1FS7/
DSL: http://www.webpagetest.org/result/160428_8G_1FT4/

Without Popups:
2G: http://www.webpagetest.org/result/160428_F5_1FRP/
3G: http://www.webpagetest.org/result/160428_8W_1FSH/
DSL: http://www.webpagetest.org/result/160428_V9_1FTP/
Analysis to follow (someone else can do this if they want - will be unlikely to have time today)

> How long does a hovercard take to load (especially as @Nuria points out on slow connections)
I'm not sure how useful this is to test right now, given T133947 would result in lots of changes.
We may want to profile the API request

> Which libraries does it use and which are loaded asynchronously
See T133947 for recommendations

  • Review Icon support to see if it will benefit from ResourceLoaderImageModule

The extension uses only two icons - cog and horn.

The benefits over the current implementation are:

  • No need to keep the generated PNGs around, RL will generate them on the fly;
  • Standard mw-ui-icon, rather than the current custom styled icon.

Future potential benefits are:

  • Specify different images for RTL and LTR languages if we want to do so;
  • Multi-colored images based on the single SVG.

@bmansurov sounds like a good idea then - want to create a task to make sure we track that?

Bytes are all over the place. I'm not seeing a clear increase of 96.1KiB occurring after enabling Hovercards (I guess these results may be after gzip?) and the degradation on fully loaded and first paint are minor if any.

phuedx added a comment.EditedApr 29 2016, 9:54 AM

How long does a hovercard take to load (especially as @Nuria points out on slow connections)

I'm not sure how useful this is to test right now, given T133947 would result in lots of changes.
We may want to profile the API request

Remember that part of pushing #mediawiki-extensions-Popups to stable is using the page summary RESTBase endpoint on the Wikipedias (T123445). We should have a good understanding of the performance of both API requests.

phuedx updated the task description. (Show Details)Apr 29 2016, 9:56 AM
phuedx updated the task description. (Show Details)
phuedx updated the task description. (Show Details)
phuedx added a comment.EditedApr 29 2016, 10:36 AM

P2975 and P2976 are basic benchmarks for the api.php and RESTBase API requests respectively.

Edit

Note well that both benchmarks are for the worst-case behaviour, where the client doesn't have a cache.

Having just re-read the schema, it seems that we'll be measuring this during the test and capturing it in the perceivedWait property.

I'm removing the sprint 73 tag on this, in recognition of the more immediate work pertaining to resolving bugs identified on Hungarian Hovercards.

Jdlrobson closed this task as Resolved.Sep 1 2016, 8:21 PM
Jdlrobson claimed this task.

To avoid confusion the remaining unaddressed question has been split out into a separate task: https://phabricator.wikimedia.org/T144544