Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 49MB web page

thatshubham.com

Post reply on HN
Print view View original

321–330 of 389 posts

Re: The 49MB web page

#321

Post by vunderba »

szszrk wrote: post #244
vunderba wrote: post #80

Earlier quoted context omitted.

PSA for those who aren’t aware: Chromium/Firefox-based browsers have a Network tab in the developer tools where you can dial down your bandwidth to simulate a slower 3G or 4G connection. Combined with CPU throttling, it's a decent sanity check to see how well your site will perform on more modest setups.

This made me chuckle. I had a fairly large supplier that was so proud that they implemented a functionality that deliberately (in their JS) slows down reactions from http responses. So that they can showcase all the UI touches like progress bars and spinning circles. It was an option in system settings you could turn on globally. My mind was blown, are they not aware of F12 in any major browser? They were not, it see…

That's great. Well, just to let them know if they ever need something like that in the future, I'm available for hire as an overpriced consultant.

I guarantee with 100% satisfaction that my O(n^n) code will allow visitors sufficient time to fully appreciate the artistic glory of all the progress bars and spinners.

Re: The 49MB web page

#322

Post by divan »

DorkyPup wrote: post #232

Author here. Woke up in today to see this on the front page, thank you to the person who submitted it! Initially, my biggest fear was the HN "Hug of Death" taking it down. Happily, Cloudflare's edge caching absorbed 19.24 GB of bandwidth in a few hours with a 98.5% cache hit ratio, so the origin server barely noticed. The discussions here about DNS-level blocking and Pi-hole are spot on. It's interesting that the bur…

Just wanted to say that article is so much deeper than it seems from the title, and also beautifully written. It was a great read!

Re: The 49MB web page

#324

Post by AndreyK1984 »

I started writing in a Dioxus (rust framework) style. max 1KB of js code. Sending the diff via WebSocket from the rust server, and , what is more important, all code is now on a server, and because of websocket and rust it executes almost same speed as on the client. Back to normal pages sizes. And, of course, virtual scrolling everywhere.

Re: The 49MB web page

#325

Post by AtNightWeCode »

Another reason for this is that often the non-tech people can inject third party scripts via CMS, GTM and so on. I remember once we had a large drop in indexed pages on Google and it turned out that a script had moved our entire site into an iframe. The marketing people who injected it was like "it is just a script".

Re: The 49MB web page

#326

Post by tech_hutch »

reactordev wrote: post #207
KronisLV wrote: post #86

Earlier quoted context omitted.

I once spent around an hour optimizing a feature because it felt slow - turns out that the slower simulated connection had just stayed enabled after a restart (can’t remember if it was just the browser or the OS, but I previously needed it and then later just forgot to turn it off). Good times, useful feature though!

Imagine the speed of those optimizations once you turned it off. lol. Love it!

It's like removing weighted clothing

Re: The 49MB web page

#327

Post by swasheck »

sublinear wrote: post #151
swasheck wrote: post #122

Earlier quoted context omitted.

this isn't purely laundering blame. it is frustrating for the infrastructure/operations side is that the dev teams routinely kick the can down to them instead of documenting the performance/reliability weak points. in this case, when someone complains about the performance of the site, both dev and qa should have documented artifacts that explain this potential. as an infrastructure and reliability person, i am happy…

Yes, but can you blame someone for trying when all the gas stations are 1000 miles away? That's the exact situation the devs are put in all the time. Oh, and the rest of the business doesn't even know what a car or gasoline are!

this still undersells the developers' intelligence and presses the metaphor a bit too far. if the implication is that the developers are unaware of (or do not have access to) infrastructure capabilities, that's seems like a procedural failure (communication, education, information, etc). i wouldnt expect developers to know everything, but i'd expect them to be curious about how their work will interact with the goal, at large.

Re: The 49MB web page

#328

Post by [deleted] »

drcongo wrote: post #73
ceejayoz wrote: post #31

Earlier quoted context omitted.

Same for fancy computers. Dev on a fast one if you like, but test things out on a Chromebook.

Music producers often have some shitty speakers known as grot boxes that they use to make sure their mix will sound as good as it can on consumer audio, not just on their extremely expensive studio monitors. Chromebooks are perfectly analogous. As a side note, today I learned that Grotbox is now an actual brand: https://grotbox.com

[deleted]

Re: The 49MB web page

#329

Post by [deleted] »

sublinear wrote: post #61
xigoi wrote: post #59

Earlier quoted context omitted.

> Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone. If a bridge engineer is asked to build a bridge that would collapse under its own weight, they will refuse. Why should it be different for software engineers?

It's a website and not a bridge. Based on the description given, it's not a critical website either. If it was, the requirements would have specified it must be built differently. You're not even arguing with me BTW. You're arguing against the entire premise of running a business. Priorities are not going to necessarily be what you value most.

[deleted]

Re: The 49MB web page

#330

Post by jazzyjackson »

NegativeLatency wrote: post #187
FabHK wrote: post #172

Earlier quoted context omitted.

Datapoint: During the pandemic, I had to use an old 2004 Powerbook G4 12" (256 MB RAM, OS X Leopard). Everything sort of worked and was even reasonably snappy. But open one website, and the machine went down. Unusable. Even if, indeed, I just wanted to read or look up a few kB of text. So painful.

Didn’t want to upgrade the memory?

It’s the speed of the JavaScript compiler, on those old browsers they were expected to handle a few kilobytes max of event listeners. The chrome vs Firefox browser wars sped up JavaScript compilation by 10x at least
Post reply on HN