Profile pictures are rendered by all Nostr apps in large quantities, so it is very important to optimize them to get good performances and respect users' bandwidth.
With modern phones and camera is not unusual to capture images larger than 2MB, and these images are often immediately uploaded (of course) without any optimization.
These are the statistics for profile image sizes based on a random selection of my following and following of following, with a sample size of 1,000 profiles:
| Size Range | Count |
----------------------------
| < 100KB | 421 |
| < 500KB | 315 |
| < 1MB | 76 |
| < 2MB | 63 |
| < 3MB | 40 |
| < 4MB | 30 |
| < 5MB | 10 |
| < 10MB | 10 |
| > 10MB | 9 |
----------------------------
| Timeouts | 2 |
| Broken Links | 24 |
| Total | 1000 |
55,3% (> 100KB) of the profile pictures can optimized!
I suggest that all developers resize the images client-side before uploading, inscribing them in a 1000x1000px square (or 800x800, which is more than enough even for a full-screen preview) and save them with 70% jpeg quality.
This setting should bring images below 100KB and make users happy.
Replies (20)
nostr.build has a pfp upload option
PS: If you programmatically optimize images, the removal of metadata, particularly geolocation data, is obviously mandatory!
What settings does it use?
I'm 170 KB animated... But my bots are about 4 MB each just because I like them to move smoothly. Maybe I should explore different ways how to animate them without using so much bandwidth. BTW shouldn't profile images be cached for at least a day?
I don't think users of your bot are happy to download every day 4MB for a profile picture :) It's just wasting resources.
Btw, animated images can be quite disturbing for some people with specific conditions (epilepsy, ADHD, autism), therefore, as a general rule, they are not recommended for good accessibility.
The bots are animated smoothly (for example,
@Fiat News 💵📰), so they're much less disturbing compared to my profile picture. I'm more concerned about the size. But you definitely have a good point about accessibility. I will see if I can find a different image for my profile without changing my Nostr identity too much.
Or just do the primal move and scrap peoples photos and re-upload and present a whole new photo to the interface 🤷♂️ seems healthy and not controversial.
1000kb gang
These large profile pictures are the reason I will never again code a client that renders them
What
Primal optimizations are them blindly (to the user) using a different photo than the user uploads. To present in the interface as a thumbnail.
I agree with you in that the clients could help by optimizing the size of the photos prior to uploading. It would help everyone no matter what client is being used.
I think when it comes to accessibility it's better to disable animations on the client, rather than to avoid animated images altogether.
> by all Nostr apps
Except textual ones.
An image file for a PFP is under 100K if you export it as .webp As you said, 800x800px is more than enough size for that.
I still prefer jpg over webp: the former is not controlled by Google, offer legacy support and sometime has better compression.
Finally, I'm not interested in the animation capabilitiesfor a PFP.
As a general rule, I agree.
But animation in a PFP is an incidental feature, actually a bug. Rendering a still image for gif/webp is not simple, often requires extracting the first frame or leverage some rendering exceptions to halt the animation. Better manage it at the source.
A cache layer is always a critical and fragile structural element. It also breaks the direct and verifiable link between user and content, and add a delay between the update of the original file and its availability.
In this context cache is a band-aid, I would avoid it, focusing instead the energies on solving the issue at the source.
yes, the root is that blossom still doesn't have a protocol for transcoded down-scaled versions
Nah, JPEG XL is the best solution for images. Since it has progressive compression, we just need clients to halt the file download once the image reaches the desired resolution (and resume the download if the user decides to zoom the image).
Works for feed images too and you don’t get generation loss if the original image is jpeg.
Getting the first frame, unless there is a way, in the format, to prescribe a different one (or even an alternative static image) seems pretty reasonable.
I don't like animated profile pictures, but I don't see accessibility as a reason to avoid them.
