alt Hacker NewsThis speaks to me. I've been running an autoresearch loop the past couple of days to improve the load time of my various projects' frontends.
I've been really, really impressed with how effective this is. I went from a 4s load on simulated slow 4g to ~750ms: https://image.non.io/speedup-graphs.webp
Side by side vid of the results: https://video.non.io/speedups.mp4
This was for https://non.io, which is something I had purposefully written to be as fast as possible (hand wrote all the comopnents, didnt even use react).
I've been considering creating a skill / utility to do this based on learnings from the speedups - would others find this kind of thing useful?
Replies
> This was for https://non.io
Maybe hugged but feels really sluggish to me for it is.
It loads in 4 seconds for me on a fast landline.
And there are plenty of things you did not opimize for. Like making sure certain dimensions are already known to the dom renderer so that the layout doesn't jump around.
Or progressive images so that it doesn't just popup suddenly.
It takes about 6 seconds to get the site fully rendered on MacBook Air 2017 in Chile. HN is slightly above 1 second in comparison.
>something I had purposefully written to be as fast as possible
and then you threw it all away by adding transition animation
Why is it so slow? Like clicking around this is a very simple site, it seems like the fade in and fade out, besides being jarring and annoying, is just adding load time.
An annoyance: clicking an image transitions the tiny image to a bigger size, then it gets replaced with a larger image file. The result is: the image slides bigger (but blurred), then immediately disappears, and reloads slowly from the top down. It's an annoying flash, and the slide to a bigger size was a waste of time.
That seriously needs some optimising. For example: on click, could the bigger image be inserted behind the small one so it's hidden; on load of the bigger image, hide the smaller image; then do the slide-bigger transition with both images together?
Autoresearch is crazy good! Closest thing to “Make this app fast!” we have now.
It still feels pretty slow, and I see some low-hanging fruit:
- in safari, every image is loaded twice, .heic and .webp
- default.png is re-downloaded 31 times, uncached
- images below the fold are request immediately, lazy loading would avoid that [1]
But most important, you have 229 requests for tiny files being served over HTTP 1.1. Without GZIP. From a pretty slow server - 700ms+ to download the main json data. Bundling your JS, or enabling HTTP2 or QUIC/HTTP3 alone would massively improve performance.
If this is the result of days of autoresearch, it's not really anything to celebrate.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...