Conversation

Notices

1. Embed this notice
   Royce Williams (tychotithonus@infosec.exchange)'s status on Thursday, 14-Aug-2025 13:02:52 JST Royce Williams

   • Thomas 🔭🕹️

   @thomasfuchs When hitting hachyderm.io itself, I'm not much of a website speed optimizer, but Chrome's Lighthouse suggestions are all on the order of one second or less, except for the Largest Contentful Paint (18 seconds) and First Contentful Paint" (14.8s) on my system, with 206(!) different separate .js resources. 118 of which are running over HTTP 1.1 instead of HTTP 2 (so there's no multiplexing). I wonder if developers are only testing against HTTP 2? (Also ... contatenating multiple JS on the fly into a single file is a thing!)

   https://gist.github.com/roycewilliams/42c1eb6fb19add01215fea3a73b25851

   • Embed this notice
     Royce Williams (tychotithonus@infosec.exchange)'s status on Thursday, 14-Aug-2025 13:02:52 JST Royce Williams

     in reply to

     • Thomas 🔭🕹️

     @thomasfuchs

     This also seems to be a problem somewhat local to hachyderm.io (or my proximity to it). I tried a few other random instances (including my own home server, infosec.exchange) and things were a third of the speed (but with the same massive array of individual .js files). A big difference appears to be whether HTTP 2 is in use (but to be clear, this is just treating the symptom - 200 js files seems dramatically unaware of even basic website speed optimization best practices). And without hints about priority of loading, IIRC external .js fetches are often render-blocking.

   • Embed this notice
     Ian Z (soviut@hachyderm.io)'s status on Thursday, 14-Aug-2025 14:33:12 JST Ian Z

     • Thomas 🔭🕹️

     @thomasfuchs "no reason" is a bit of an over statement. For example, I'm in Canada and my server is across the ocean, so even getting the initial assets can slow things for me.

     Next, these are running on community run instances that could be a laptop hard drive for all we know.

     Those instances do more than just serve content, they collate, manage accounts, etc.

     Those servers are running a rails app so there's some overhead built in.

     That rails app is getting older and maintained by a small team.

     The frontend code is starting to get archaic and has had pushback on switching to a framework like React. So fewer people can easily contribute to it.

     Things like privacy and moderation tools have been a high priority for a while; performance less so. The small team's time is limited.

     etc.

     All of these things are solvable, but it's a problem of time and/or money. Something that is is short supply when it comes to Mastodon.

   • Embed this notice
     Ian Z (soviut@hachyderm.io)'s status on Friday, 15-Aug-2025 02:14:35 JST Ian Z

     • Thomas 🔭🕹️

     @thomasfuchs Were any of those apps a social network? heh.

     I agree that it can be made fast, but social graphs can be notoriously difficult to optimize.

     I'm mostly just giving them the benefit of the doubt.