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, 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.

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

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

@Jhernandez Smells like it to me.

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.

In T131314#2249996, @Jdlrobson wrote:

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 Page-Previews 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.

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.