[HOLD #12603][Image][Performance] Avatars appear grey as they're loaded from server for common mobile flows - reported by @sobitneupane

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open the mobile app
2. Click Request Money from Global Create (green + button)
3. Enter any amount
4. On the next screen, notice how the color of the avatar for recent contacts starts grey, and as we re-render, the actual avatars/list appears.

Note: If you check the linked conversation, then it's also easy to see that this happens in the IOU preview component. You can also reproduce this on most mobile flows. I was able to do the same with Send Money as well as New Chat.

Expected Result:

Avatars are saved locally and don't re-render for our most common mobile flows, let alone your most frequently used contact.

Actual Result:

Recent avatars start out as grey since that's all we have locally, and after being downloaded from the server, the actual default avatar appears

Workaround:

None

Platform:

Where is this issue occurring?

• iOS
• mWeb
• Web

Version Number: 1.2.9-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

RPReplay_Final1664482772.mov

Expensify/Expensify Issue URL:
Issue reported by: @sobitneupane
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1663403937756359

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[JmillsExpensify]

Hmm, these reproduction steps are pretty hard to follow. I'm not seeing any greyness in the video. In fact the original report was a different flow. It was appearing in the IOU preview component.

[JmillsExpensify]

That said, I would imagine that the reason the greyness is happening in the Request Money flow as well as the IOU preview component because we save no cached version locally, so all the avatars are constantly being re-rendered from the server. And specifically the reason that it's grey is that this is the skeleton UI color we fall back on.

[JmillsExpensify]

I'm going to update the video with one of my own so that the greyness is visible and more clear. I'm including a screenshot here for clarity.

[JmillsExpensify]

Likely related: #6527

[melvin-bot]

@JmillsExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[JmillsExpensify]

Ok, I also discovered another way to reproduce this issue on Web (as well as mWeb). Reproduction steps for web

1. Open up a chat that has quite a bit of history
2. Start scrolling up quickly
3. At a certain point, you'll see the same issue. Avatars appear a dark gray, at which point they are eventually loaded.

I think this is a backend/performance issue, so I'm going to add the engineering label for more thoughts.

[melvin-bot]

Triggered auto assignment to @PauloGasparSv (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[PauloGasparSv]

Hey @JmillsExpensify I took a quick look but I'll reassign the engineering label so someone else can take it because I have a full plate right now : /

Adding what I found so far here:

---

While investigating this I compared the network tab between NewDot and Whatsapp.
Here is how our chat loads thumbnail images against how Whatsapp loads some images:

NewDot

Whatsapp

As you can see in the Size tab of the screenshots , if an image was already requested in Whatsapp the browser caches it.
I think our App should be doing that and it would probably fix the problem everywhere. But right now we ask the browser not to cache:

I found this slack thread that mentions @thienlnam so maybe he has some info on this!

[aldo-expensify]

@PauloGasparSv I think the cache-control: no-cache header is added when you have the checkbox Disable cache checked in the network tab of chrome dev tools. If I uncheck it, I don't see that header anymore. Having said that, I also think there is something preventing the avatar images from being cached

Headers without the Disable cache:

[PauloGasparSv]

🤦‍♂️ thanks @aldo-expensify! 100% forgot about that!

[JmillsExpensify]

Going to float this one in open-source because it's nice polish.

[Beamanator]

Added this to our Image-related features & improvements tracking issue: #10894

[trjExpensify]

No change, Melv.

[Beamanator]

same

[trjExpensify]

Same as above. What's left here for the image improvements project is held on caching > which is blocked on the server migration project in progress.

[Beamanator]

stilllll held

[trjExpensify]

CORS issue complete, web image caching in review. Getting closer!

[trjExpensify]

Image caching PR was deployed and reverted. Awaiting this now before re-implementing: #32703

[blimpich]

#32703 is fixed, good to move forward with this.

[trjExpensify]

In light of #32703 being fixed, the new image caching PR is in review.

[trjExpensify]

Caching PR was reverted again, new PR is in the works.

[trjExpensify]

Alrighty, that PR has been deployed and doesn't look like it'll get reverted. We need to work on the new cache API next, but I believe that's in a line of incremental improvements in vip-vsb. That said, I think we somewhat solved this "grey avatar" problem in the OP by using the skeleton UI on the participant selector when it's loading. So while I think improved caching could maybe be of help here for the avatars, I don't think we need to pursue this issue standalone. With that, I'm inclined to keep it off VIP/Wave and close it now. @Beamanator, what do you think?

[Beamanator]

That definitely makes sense to me @trjExpensify , let's close this bad boi!

[trjExpensify]

Nice!