I haven’t done lots of testing by any means, but I also didn’t have any problems loading lots of thumbnails in my testing.
I think it might perhaps have to do with the fact you’re using pcall, which is usually a good idea but the getthumbnail function actually does wonders by checking if isReady is true instead of success from pcall. So I’d recommend testing if it works by doing it the same way as the docs have done it since they don’t use pcall there
Given the amount of duplicates in your UI, your game can benefit by caching the API call results and looking them up in the cache before making an actual API request. Also the if ready then statement in your code is a bit useless, if the image fails to load you should still have the attribute of the player and their failed image instead of a default “Roblox” one.
Another culprit that comes to mind is your retry logic. In your code you have many image labels that all, if they happen to fail, spam the API call with under a second intervals, until they succeed. If an image happens to actually be problematic and unable to load, it will keep making requests forever, causing throttling effects to the rest of the unrelated API calls. To fix this I suggest only retrying a fixed amount of times with increasing delays. For example try once after 0.2 seconds, then after 1 second, then after 5 and then just load a default image.
Lastly since this is related to API calls I suggest making the requests one after another instead of parallel, to avoid any rate limits that might be in place. Currently if I’m not mistaken you tell all your images to make requests at the same time, by having different scripts(however if you switch to non-parallel images may appear slow to load, so you might want to finetune how many images you load at once, if that happens).