Hacker News Reader

Comment by newnewpdro | Hacker News Reader

High dpi screens have made this so much worse.

Try browsing the web on a 128kbps ISDN-like connection, many sites are too slow to be usable or outright broken due to their own timeouts.

What I've noticed is many new sites are using huge high-res images as some kind of maximum-common-denominator to ensure things look great on high dpi screens, while everyone else has to transfer all this junk only to downscale it anyways at render time.

I'm often on a slow link and it's made me stop using the web almost entirely, outside of HN and reddit. Slack for instance is completely broken, it can't even manage to finish logging in without giving up.

It used to be that slow internet users just had to wait longer, but things largely worked correctly. Nowadays, with lots more javascript and async stuff having web developers programming timeouts and probably never once testing on a slow link, a lot of things are flat out broken.

View on HN

> What I've noticed is many new sites are using huge high-res images as some kind of maximum-common-denominator to ensure things look great on high dpi screens

Obviously this is far from good but what's the practical solution for this?

As far as I know, doing this with HTML + CSS alone by yourself is tedious and error-prone e.g. figure out manually the maximum size of each image, generate all variations of the image sizes yourself, then use HTML/CSS to load the right ones.

There's CDN, web server and CMS specific solutions that dynamically resize + cache images on demand but they're far from common place so I'm not surprised most website owners don't do this well.

Isn't the <srcset> element supposed to solve this problem?

How do you generate the image files srcset is meant to load? How many different width and DPI variations do you make? How do you generate the srcset markup to load the right image file? What's your workflow when you want to update an image and change its width?

I presume you're expected to work in the highest dpi, then have a post process stage for publishing the site which then generates the variants for you.

The solution was arrived at a long time ago.

It looks like this:

https://text.npr.org

Or:

https://lite.cnn.io

With better formatting. You make a text only or otherwise very reduced version of your site available to visitors. Ideally in that version you drop the images entirely. You can optionally attempt to measure the capabilities of a visitor, how they're experiencing your site, and actively present them with the reduced option (the far easier thing to do, is to just make a reduced version available and let visitors know it exists somewhere prominent enough). Visitors want the content, not the ridiculous SEO image.

If you build for this from the beginning of a site, it's extremely easy to deliver and maintain.

Try this link for info about reducing bandwidth and energy usage.. https://solar.lowtechmagazine.com/2018/09/how-to-build-a-low...

We were doing some latency testing/troubleshooting at the browser level one day when we found out the background image for our website was an unoptimized 13MB png... that information was quickly forwarded to the front end team.

Reply on news.ycombinator.com