Hacker News Reader

Comment by jjcm | Hacker News Reader

This 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?

View on HN

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/...

> This was for https://non.io

Maybe hugged but feels really sluggish to me for it is.

These are the stats I'm seeing: https://image.non.io/7a8adcb1-2a17-4e2c-b213-d0c3e173a1d5.we...

Should note the server is on USW and I don't have edge servers for it at the moment.

https://pagespeed.web.dev/analysis/https-non-io/6mtvojtvvy?f... Quite slow imho

Never visited before and the site was HN load speed. Very fast.

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.

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

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.

Reply on news.ycombinator.com