Open clarfonthey opened 5 years ago
Another suggestion from my side: The web client seems to be fetching the originally uploaded avatar image. Which usually means that they are much larger than they need to be at the size they are displayed at. Also if the original file was uploaded as a PNG, that file will be loaded unaltered. I don't know if Mastodon's API offers different resolutions for a file like this, but if not, that should be implemented. This would also improve the bandwidth requirement for other clients, if they choose to implement it.
About the icon, I noticed that the actor's icon provided in the ActivityPub API is also the original image. There is no way in ActivityPub to provide different sizes, however it is indicated about icons in the ActivityStream spec that: "The image should have an aspect ratio of one (horizontal) to one (vertical) and should be suitable for presentation at a small size". There is no need to keep the original image when the user sets their avatar. We could already resize the avatar to 128x128 (if larger) when the user sets the avatar and when the server fetches the avatar of non-local users. This may already improve bandwidth (and disk usage). On the public profile page, the size of the avatar is 128x128, and it is smaller in the other contexts.
In the Mastodon API, the avatar of an account is typed as "String (URL)". Providing several sizes means we need to change the API to provide an object listing the different URL by sizes or to add a mecanism in the url to indicate the wanted size and let the server resize the image. However, the Mastodon service does not usually serve itself the images, they are served directly by the proxy in front of it (when stored on the same server), or by a storage service (when stored on the cloud).
There is no way in ActivityPub to provide different sizes
I have to concede that I don't know much about ActivityPub, but within the ActivityStream spec there is this example for the icon
object:
{
"@context": "https://www.w3.org/ns/activitystreams",
"summary": "A simple note",
"type": "Note",
"content": "A simple note",
"icon": [
{
"type": "Image",
"summary": "Note (16x16)",
"url": "http://example.org/note1.png",
"width": 16,
"height": 16
},
{
"type": "Image",
"summary": "Note (32x32)",
"url": "http://example.org/note2.png",
"width": 32,
"height": 32
}
]
}
I guess the biggest challenge is keeping things compatible.
There are two different reduxes, neither is a replacement for react
Redux Framework linked above is for building wordpress plugins The Other Redux is for state management in javascript apps, and mastodon's frontend already uses it
Most lighter-weight solutions would imply moving more of the logic and rendering from the client to the server -- in general that means less separation between backend and frontend rather than more.
Performance improvements are either going to have to come from harder optimizations to the SPA, dramatically reducing the complexity of the frontend so that it can still be implemented client-side with something lighter than react, or moving logic & rendering to the server. It's a game of tradeoffs, so articulating the performance goals here will be important.
@jhaye I misread the spec... However, I haven't seen yet an instance where an array of images is provided for the avatar (only an image, without any indication of size). I should investigate with the other implementations. Though, I don't think we will be able to offer this feature while staying compatible with the current Mastodon API.
What about trying to migrate from React to something like Inferno or Preact?
Preact would be a nice first goal, but I personally found that Vue apps are really lightweight. If you go that route I can help a bit :)
@makmm I really love Vue, but Preact and Inferno apps are usually more lightweight and migration seems to be easier…
Right now, everything is a giant React app, which is very heavy. We might want to consider moving to something like Redux which is lighter weight, or potentially something entirely different. #48 (separating frontend and backend) might also allow for different web app versions, depending on user needs.
Basically, this is going to be a master tracking issue for ways to make the web app faster.