Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In reality JavaScript size means very little when a single image might be 500k.


Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.


Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms


100ms is noticeable. It's already slow if you reach that.


It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.


Maybe, but in terms of understanding the code and having total control over it, it means a lot.

(And I don't buy the large teams can't adopt a self-grown code in the first place. If they're any good, they can. If they're not, then even their React and Angular skills will be bad).

Besides you know all your business logic code? That will be custom too, anyway,and they'll have to adopt it...


Did you not see that headline about how the average page now is the size of a Doom install?


Mainly because an average page has much higher resolution graphics than Doom.


Six years ago I was regularly mining merchant pages containing 1mb+ of HTML. Nowadays that seems to be par for course.


You shouldn't be serving 500k images to mobile users.


It's not so much the time over the wire to download, but the time to parse and run all that JS. If you open up your web dev tools, I think you'll see the impact from a 50k gzipped JS file is probably greater than a 500k image, for one thing the site can probably function without the image loaded, but your page will not be user responsive until that JS has finished executing.


My total image payload is 30k. Obviously getting there is more challenging for other sites, but at the end of the day if your page is >1mb I'm probably not going to wait for it to load


>but at the end of the day if your page is >1mb I'm probably not going to wait for it to load

Average size for the most popular sites has actually grown to ~ 2.5-3MB.

And since they're the most popular, it shows that people DO wait just fine for them to load.


Switch "most popular" to "your site" and it will probably change user's desire to wait for it.


Yeah, that's true.

Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.


What's more relevant at Facebook's scale is dollars saved per kilobyte shrinked. Because majority of its users will tolerate almost anything at this point, including apps that crash randomly to measure loyalty.


Then you are doing images wrong.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: