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

211–220 of 389 posts

Re: The 49MB web page

#211

Post by Beijinger »

"The Sticky Video Player Publishers love embedding auto-playing videos these days, which isn't really popular. You'll find mulitple forum, Reddit, HN, or Twitter threads about it.

To make it somehow worse...when you scroll down, you think it would leave you as it leaves the viewport. No. It detaches, shrinks and pins itself to the bottom right of your screen and continues playing. It keeps the distraction going and as if teasing you, features a microscopic 'X' button with a tiny hit area (violating Fitts's Law)."

Is there not way to stop this? The do not autoplay videos option often does not work.

Re: The 49MB web page

#212

Post by wpm »

vunderba wrote: post #80
PunchyHamster wrote: post #20

Our developers managed to run around 750MB per website open once. They have put in ticket with ops that the server is slow and could we look at it. So we looked. Every single video on a page with long video list pre-loaded a part of it. The single reason the site didn't ran like shit for them is coz office had direct fiber to out datacenter few blocks away. We really shouldn't allow web developers more than 128kbit o…

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.

For macOS users you can download the Network Link Conditioner preference pane (it still works in the System Settings app) to do this system wide. I think it's in the "Additional Tools for Xcode" download.

Re: The 49MB web page

#213

Post by boomlinde »

albedoa wrote: post #192
xp84 wrote: post #181

Earlier quoted context omitted.

Reserve a huge share of the blame for the “UX dEsIgNeRs”. Let’s demand to reimplement every single standard widget in a way that has 50% odds of being accessible, has bugs, doesn’t work correctly with autofill most of the time, and adds 600kB of code per widget. Our precious branding requires it.

> Let’s demand to reimplement every single standard widget in a way that has 50% odds of being accessible, has bugs, doesn’t work correctly with autofill most of the time, and adds 600kB of code per widget. You're describing the web developers again. (Or, if UX has the power to demand this from software engineering, then the problem is not the UX designers.)

That e.g. a form should work predictably according to some unambiguous set of principles is of course a UX concern. If it doesn't, then maybe someone responsible for UX should be more involved in the change review process so that they can actually execute on their responsibility and make sure that user experience concerns are being addressed.

But sure, the current state of brokenness is a result of a combination of overambitious designs and poor programming. When I worked as a web developer I was often tasked with making elements behave in some bespoke way that was contrary to the default browser behavior. This is not only surprising to the user, but makes the implementation error prone.

One example is making a form autosubmit or jump to a different field once a text field has reached a certain length, or dividing a pin/validation code entry fields into multiple text fields, one for each character. This is stupidity at the UX level which causes bugs downstream because the default operation implemented by the browser isn't designed to be idiotic. Then you have to go out of your way to make it stupid enough for the design spec, and some sizeable subset of webpages that do this will predictably end up with bugs related to copying and pasting or autofilling.

Re: The 49MB web page

#214

Post by sayamqazi »

albedoa wrote: post #192
xp84 wrote: post #181

Earlier quoted context omitted.

Reserve a huge share of the blame for the “UX dEsIgNeRs”. Let’s demand to reimplement every single standard widget in a way that has 50% odds of being accessible, has bugs, doesn’t work correctly with autofill most of the time, and adds 600kB of code per widget. Our precious branding requires it.

> Let’s demand to reimplement every single standard widget in a way that has 50% odds of being accessible, has bugs, doesn’t work correctly with autofill most of the time, and adds 600kB of code per widget. You're describing the web developers again. (Or, if UX has the power to demand this from software engineering, then the problem is not the UX designers.)

I as a developer cannot refuse to not build as-is what was signed off by product manager in figma.

Recently had to put so many huge blurs that there was screen tearing like effect whenver you srcolled a table. AND No i was not allowed to use prebake-blurs because they wouldnt resize "responsively"

Re: The 49MB web page

#215

Post by jonwinstanley »

chrismorgan wrote: post #198
PunchyHamster wrote: post #20

Our developers managed to run around 750MB per website open once. They have put in ticket with ops that the server is slow and could we look at it. So we looked. Every single video on a page with long video list pre-loaded a part of it. The single reason the site didn't ran like shit for them is coz office had direct fiber to out datacenter few blocks away. We really shouldn't allow web developers more than 128kbit o…

Peanuts! My wife’s workplace has an internal photo gallery page. If your device can cope with it and you wait long enough, it’ll load about 14GB of images (so far). In practice, it will crawl along badly and eventually just crash your browser (or more), especially if you’re on a phone. The single-line change of adding loading=lazy to the elements wouldn’t fix everything, but it would make the page at least basically…

Haha excellent. Presumably all the images are the full res haven’t been scaled down for the web at all?

Re: The 49MB web page

#216

Post by LandR »

sublinear wrote: post #44
arccy wrote: post #39

Earlier quoted context omitted.

Sounds just like a "helpless" dev that shifts blame to anyone but themselves.

Do you have a suggestion how else to handle the situation I described?

Man, I probably say no to like 40% of the requests I get as a dev. Often we will come up with a better way of doing things by just spending 15-30 mins talking to the business about the actual problem they are having.

Some are just flat out refused as they are just too stupid and will cripple the system in some way.

Re: The 49MB web page

#219

Post by LandenLove »

I recently had to switch to a Japanese LINE account to gain access to certain features. I had no idea how good I had it on my American LINE account. The Japanese account is covered with ads EVERYWHERE on the home screen and even in the chat area. I have no idea how this app is still popular in Japan. I would pay to remove the ads if I could.

They also have their own tiktok and AI slop that I never knew about.

Re: The 49MB web page

#220

Post by 4k93n2 »

decimalenough wrote: post #108
Cyphase wrote: post #10

Earlier quoted context omitted.

RSS and feed readers still exist! All hope is not lost.

Sure, I use Feedly myself, but RSS is increasingly marginalized. I use to follow blogs, but it's not usable for mainstream media, Reddit, HN, etc etc.

something like RSSHub can be used in conjunction with your RSS reader and will generate feeds for sites that dont have them. RSS-Bridge is another option
Post reply on HN