191–200 of 392 posts
Earlier quoted context omitted.
Yeah I was surprised they included pictures in the limit at all -- I mean, sometimes, you need those pictures, and for them to load slower is less important so long as you don't need them to navigate the page.
You dont really need full size/resolution images on a web page.
I believe this is placing emphasis on entirely the wrong thing. Page size does not matter. Render time/time 'til functional does. Stripe.com is 1.2MB fully loaded but is pretty much all non blocking so it feels as fast as a very small site. By the time you've scrolled to the bottom of the homepage it's loaded >2MB. The convert pretty well, and my experience is that Stripe knows what they are doing better than most. S…
Earlier quoted context omitted.
Yeah I was surprised they included pictures in the limit at all -- I mean, sometimes, you need those pictures, and for them to load slower is less important so long as you don't need them to navigate the page.
You dont really need full size/resolution images on a web page.
Ahh let the bikeshedding continue. In these situations all I want to say is "Who cares". Optimization matters when it actually solves a problem, before that it's just wasted effort. I don't hear the general public yelling from the rooftops "The web is too slow! Developers are building too fast! I wish we could go backwards!"
Not everyone within earshot of your roof is "the general public". It matters to people on lower-bandwidth connections. It matters in terms of carbon footprints. And just as someone who grew up horrified if individual pages got over 100kb (or whatever the company rule was), the idea of not caring at all about "page" weight is how my old company wound up passing 20+ megs of JSON around just because it was a little easi…
The same thing is not true for the general public.
Here's a common example, from a FAANG company: 72mb and 367 requests to display around 2,000 characters of text. Maybe double that if you count the "hyperlinks." Single page applications are horrible, and oh-so-common. https://imgur.com/a/v2rud7T
With good code splitting, which is supported basically out of the box by Webpack and all the big front-end frameworks, I would argue a well-written SPA transmits less data in the long run than a fully server-rendered app. The initial payload is bigger by a few hundred KB sure, but after that:
- Like server rendered pages, you still only load pages on demand, thanks to code splitting
- Unlike server-rendered pages, you can cache everything except the data that changes, because it’s JavaScript not HTML.
Yes you’re still making a request for fresh data on every page load, but while the code is cached you need only download the raw data itself. You’d have to be really clumsy to send a JSON payload bigger than a full HTML document containing a rendered representation of the same data.
Of course, this only really applies to apps. Static or infrequently changed content, you’re better off either server rendering or just serving static files.
You can also make the argument that it would be more efficient to serve mostly static HTML, with the bare minimum JavaScript required to fetch new data, but ultimately everything is a trade off :)
I don't mind highlighting and curating small sites for fun, that's neat. But calling larger sites a "cancerous growth on the web" just feels immature to me. Everything is just cost/benefit. There's no need to bring a black-and-white fanatical exaggerated mindset to it. You can celebrate something you like without having to make the alternative a disease , sheesh.
With all due respect. Modern news websites are a disease, and I find it pretty hard to disagree with the nomer cancerous growth since the behavior is spreading, and normalized by these websites. There is zero benefit to me in loading 20mb of garbage just so I can read 10kb of text.
Earlier quoted context omitted.
If general public even knew who to complain they would have surely yelled loudly. For now I hear non-tech people say 'Oh, our internet is slow even though we pay lot of money' Meanwhile valley bros keep helpfully reminding me to upgrade my computer to a reasonable 2020sh.
The general public likes to do things on the web other than reading minimalist hypertext. They like real-time chat and video and images and playing games in the browser. They would rather be able to do the things they like faster and more efficiently than abandon the last 20 years of technological progress.
In some ways it's interesting to think that a modern website is larger than most operating systems used to be. I can understand why (frameworks, rich assets, etc) but it puts us in an interesting place. I wonder what the web will look like in 2030?
Indeed, I remember running QNX from a floppy disk (1.44MB) complete with windowing system and utilities.