We should consider removing the datetime stamp altogether, as well.

In T137775#2382700, @dr0ptp4kt wrote:

We should consider removing the datetime stamp altogether, as well.

Tagging Design for this inquiry.

@ovasileva @bmansurov - to be clear although this is tech debt, it's also something we should prioritise from a product perspective.

This should block rolling out Hovercards and be high priority. 50kb is a lot for every page view and this is easily fixed.

On a clear cache, after gzipping, Hovercards bloats the page JS from 192kb to 222kb. It's only 207kb without the moment libray.

Removing this code would improve the load time of a hovercard, making them much more responsive and would reduce the likelihood that the performance team rolls back our release due to performance regressions.

I'm not sure why this is in "needs analysis". We use a similar technique in MobileFrontend to achieve the same goal for a lot less bytes. We should leverage that.

(in other words half of the JavaScript code for the Popups extension renders a line that says "Edited 33 minutes ago")

^ I'm not sure what happened there…

@Jdlrobson: Could you update the description to include the value of this work, which might seem intuitive but is worth stating, and solutions that've been proposed (T137775#2382700 and T137775#2669404).

In T137775#2669404, @Jdlrobson wrote:

Removing this code would improve the load time of a hovercard, making them much more responsive…

To be clear, removing this code (or replacing it with a smaller chunk of code) would improve the load time of the first hovercard.

… and would reduce the likelihood that the performance team rolls back our release due to performance regressions.

It's true that there's a non-zero chance that Performance can roll back one of our changes but this risk is vague and hard to quantify – to me, it makes "performance" as much of a bogeyman as "technical debt". One way to quantify this risk is to ask Performance for a set of guidelines (better yet, rules) as to what they consider a critical regression.

I'm not sure why this is in "needs analysis". We use a similar technique in MobileFrontend to achieve the same goal for a lot less bytes. We should leverage that.

At least, the following questions – explicit and implicit – remain unanswered:

• Design: does the user need to know when the page was last edited?
  • If yes, then are there other ways we could signal to the user that the page was edited recently?
• Is the MobileFrontend-solution reusable in the Popups extension?
  • If no, then how can it be made to be reusable?
    • If there's more than one approach, then how complex/risky are they?

In T137775#2670774, @phuedx wrote:

^ I'm not sure what happened there…

---

@Jdlrobson: Could you update the description to include the value of this work, which might seem intuitive but is worth stating, and solutions that've been proposed (T137775#2382700 and T137775#2669404).

---

In T137775#2669404, @Jdlrobson wrote:

Removing this code would improve the load time of a hovercard, making them much more responsive…

To be clear, removing this code (or replacing it with a smaller chunk of code) would improve the load time of the first hovercard.

@phuedx: What do you mean by on the first?

… and would reduce the likelihood that the performance team rolls back our release due to performance regressions.

It's true that there's a non-zero chance that Performance can roll back one of our changes but this risk is vague and hard to quantify – to me, it makes "performance" as much of a bogeyman as "technical debt". One way to quantify this risk is to ask Performance for a set of guidelines (better yet, rules) as to what they consider a critical regression.

I'm not sure why this is in "needs analysis". We use a similar technique in MobileFrontend to achieve the same goal for a lot less bytes. We should leverage that.

At least, the following questions – explicit and implicit – remain unanswered:

• Design: does the user need to know when the page was last edited?

From a product standpoint, while I wouldn't consider this crucial, it is a nice to have, especially for logged-in users.

• • If yes, then are there other ways we could signal to the user that the page was edited recently?
• Is the MobileFrontend-solution reusable in the Popups extension?
  • If no, then how can it be made to be reusable?
    • If there's more than one approach, then how complex/risky are they?

In T137775#2684273, @ovasileva wrote:

In T137775#2670774, @phuedx wrote:

To be clear, removing this code (or replacing it with a smaller chunk of code) would improve the load time of the first hovercard.

@phuedx: What do you mean by on the first?

@ovasileva: What @phuedx means is that the relevant code is requested once the first link is hovered during a page session. Once that code is loaded it doesn't need to be loaded again, so every subsequent hovercard is loaded faster. Thus, smaller code payload means faster loading of the first hovercard.

Of course, if the overall loading time is less than the hovercard activate time, then it won't be noticed (so, slower connections see a bigger improvement).

Finally, got around evaluating this. from design's side the purpose of the tagline was to show how fresh the article content is. but considering the high cost, the value seems minor, since it's not proven to actually show how fresh the content is. it's an estimate.

We suggest to get rid of this line and move the cog in a consistent right position.

let's save some bytes

@ovasileva over to you!

@Nirzar - sounds good, I agree for now. However, I'd like to bring this back at some point, as it's one of the selling points for editors in terms of hovercards vs. navpopups. Editing task description and moving to triaged but future

Change 335482 had a related patch set uploaded (by Jdlrobson):
Remove last modified line

https://gerrit.wikimedia.org/r/335482

36 minutes after sprint planning!

Change 335482 merged by jenkins-bot:
Remove last modified line

https://gerrit.wikimedia.org/r/335482

Looks good. can we summarize the performance benefit in detail? it would be handy to justify removing a feature.