Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizing for faster load times #48

Open
solonovamax opened this issue Feb 4, 2021 · 3 comments
Open

Optimizing for faster load times #48

solonovamax opened this issue Feb 4, 2021 · 3 comments

Comments

@solonovamax
Copy link

solonovamax commented Feb 4, 2021

Optimizing for faster load times

Here are some issues I noticed with load times on your site:

  • sortable.js is not minified.

    • actually, it loads both sortable.min.js and sortable.js. Not sure why.
  • owasp-password-strength-test.js is not minified.

    • also, not sure why it loads this when you're not on the change password/create account page. Should probably restrict it to that.
  • moment.js is not minified

  • When on the root page, it seems to load every. single. pronoun... This takes around 400ms and should probably be avoided. I'm assuming this is for the feature to load 3 random example pronouns for new users, but you should probably:

    1. make it so it queries an api to get 3 random pronouns rather than loading them all
    2. doesn't load the random pronouns if you're logged in. That's just a waste of bandwidth.
    3. It also seems that if you leave the page and return to it (eg. click on one of the pronouns, then use the back button. The page has not reloaded.) Is there maybe a way to cache it across page movements, so you can avoid that? (Idk if that's possible with js)
    4. Also, if you're not already doing this, then you should cache the pronouns list, as it seems to take around 400ms so idk if you're caching it.
      (Looking at the code, it seems like you're caching them, but I don't believe you're cacheing the raw string data. If there's a way to do that (again, idk js), then perhaps you might be able to speed it up. I believe you should just be able to do something like let cachedString = JSON.stringify(obj), and then you can send it with res.send(cachedString). I believe this should be faster, and won't introduce any weird bugs.)
  • loooooool what's pink.jpg??? It seems to load a 1MB image every single time it loads the main page, which can take around 300ms-400ms to load. (with my internet speeds. Which are pretty good, though not the best. But still, gives you an idea of how it's a tad too big.)

    Edit: okay I figured out that it's on the home page for non logged in users. But there are a few very obvious optimizations you can (and should) make:

    1. It shouldn't be 5184x3456 pixels in size. Nobody has a monitor that large, and it's blurred so you wouldn't even notice it if it wasn't high enough resolution for your monitor (like if you were on a massive 4k tv.... for some reason...)
    2. It should really be an svg with colour gradients. I'd be willing to make an svg that looks similar enough to that image, but that utilizes colour gradients instead of actual pixels. This would be much more efficient and would be able to scale to any resolution you wanted.
    3. It shouldn't even be loaded for users who are logged in, since it's not shown to them at all. No need to load it if you aren't seeing it. (Either that or make it so it shows it to users who are logged in.)
    • The same thing also applies to a few of the other images you have on the site, like facebook.png, twitter.png, etc. They're very simple images that could probably be optimized into an svg. But, they're much smaller than pink.jpg, so they don't hurt the load times as much. (There's also favicon.ico, but I'm assuming that needs to be a .ico because browsers, and it doesn't take up that much space at only 64x64. Though, it doesn't seem to have any compression at 6.0kb.
  • Other than that, the next slowest things are all the js scripts the browser needs to download, and the main html file itself, which seems to take around 200ms of waiting and 100ms of download. (You don't happen to be dynamically generating custom html content per user by any chance, do you? Because if so, that should reaaally be avoided...) But I'm assuming there aren't many optimizations that can be done there, as you probably need most, if not all, of those js scripts for fancy js stuff.

    (Okay actually, I just checked and it seems all the pages take like 300ms-500ms to load... And looking at the source, you don't seem to be doing any dynamic bullshitery, though I could be wrong, so the long wait time might just be because nodejs is slow, and bad, and sucks, and nobody should ever use it lol. It might be worthwhile to eventually switch to java with sprint boot, but I'm not going to, in all seriousness, suggest that you completely throw out all the code and rewrite it from scratch for some slight performance boosts. Realistically, nobody's gonna do that, but you might want to switch one day. idk.)

Also, I just want to let you know that none of this stuff is "you must do it or else your app will die", these are just some perf optimizations that I thought of which shouldn't be too hard to implement. I just like applications with minimal amounts of bloat, and thought I'd point these out.

@falkirks
Copy link
Member

falkirks commented Feb 4, 2021

Thanks so much for this! I am not super active wth this project anymore so I can't promise that this will all get addressed. As you can probably tell, this was hacked together to fit some idea in my head with the sincere hope that I would have the time and energy and support to rewrite it in a better language one day. And this hasn't happened. I started a rewrite in django and didn't get anywhere.

As to the specific concerns

  • I have just turned on JS minimisation on Cloudflare so soon these should all get a bit smaller. I'm not sure why that was off. Maybe I was debugging in production or something terrible like that.
  • owasp-password-strength-test.js shouldn't load on every page but I don't know if I can fix this easily
  • pink.jpg is silly, this should be a gradient.
  • The reason things take 200ms of waiting is a bit scary. The app handles like 5-6 requests/second and runs on a heroku free dyno. It barely has any capacity to sustain itself. Whenever I need to reboot it, it often takes several tries because the initial load and buffered requests on the dyno crashes it. Under peak load I upgrade it to a paid dyno, but this is not sustainable cost wise to do all the time. Due to my old free provider shutting down, I had to move the database to another server which is likely >100ms away from the application dyno. So the app is working with the poor resources it has, and honestly I have been surprised at how well it performs given this :(

@solonovamax
Copy link
Author

solonovamax commented Feb 5, 2021

  • The reason things take 200ms of waiting is a bit scary. The app handles like 5-6 requests/second and runs on a heroku free dyno. It barely has any capacity to sustain itself. Whenever I need to reboot it, it often takes several tries because the initial load and buffered requests on the dyno crashes it. Under peak load I upgrade it to a paid dyno, but this is not sustainable cost wise to do all the time. Due to my old free provider shutting down, I had to move the database to another server which is likely >100ms away from the application dyno. So the app is working with the poor resources it has, and honestly I have been surprised at how well it performs given this :(

holy shit LMAO
I will say, that is particularly cursed.

But yeah, I completely understand both the feeling of not having enough time for one specific project (because you just randomly started 4 other big projects last week for no reason what so ever), and the feeling when you just decide to rewrite an entire app for shits and giggles but then spend 100 hours refactoring random arbitrary bits of code before you give up lol

Want me to make a gradient in inkscape real quick that looks similar enough to pink.jpg, but is significantly smaller? It wouldn't take too long.

@solonovamax
Copy link
Author

Okay, so I spent like 30 minutes making an svg that looks pretty similar, and then I loaded it in chrome and it turns out it uses svg 2.0 features that have actually been removed from the svg spec, and takes like 30 seconds to load in chrome and firefox
So... uhh.. this is a gg moment.

I'm gonna figure out how else I can do it without that feature...
(Also yes, I immediately forgot about this after I posted it and only just remembered lol)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants