The Website Obesity Crisis | Hacker News Reader

The Website Obesity Crisis

idlewords.com

1,122 pointsjmduke367 comments

I think it is because people (designers, coders, etc) get bonuses and paychecks for creating stuff more than tearing down stuff.

Put this on your resume -- "Implemented feature x, designed y, added z" vs "Cut out 10k lines worth of crap only 10% of customers used, stripped away stupid 1Mb worth for js that displays animated snowflakes, etc". You'd produce a better perception by claiming you added / created / built, rather than deleted.

So it is not surprising that more stuff gets built, more code added to the pile, more features implemented. Heck, even GMail keeps changing every 6 months for apparently no reason. But in reality there is a reason -- Google has full time designers on the GMail team. There is probably no way they'd end the year with "Yap, site worked great, we did a nice job 2 years ago, so I didn't touch it this year."

That is most likely part of it. Likewise, the current structure of most companies simply cannot function in the face of something being 'done'. Someone has to keep the developers busy for the 40 hours a week they must be in their chairs to get paid. Even if that weren't an issue, you will always have someone who wants a promotion. And they will need to have something to show off to get it. So they will come up with a 'brave new direction' and use sheer force of will to make it happen.

I remember when I first realized that software companies had a fundamental problem with how they handled finished products. BulletProof FTP. It was a magnificent FTP client decades ago. I used it on my dialup connection to practice data hoarding. I paid for it because it was a trustworthy companion in my adventures through the net. But, that turned out to be its ownfall. It was feature-complete and it was excellent (although they never did fix the problem with quick reconnects resulting in a pre-existing binary transfer socket getting picked up for use as the command connection, spamming the thing with random binary data and confusing the hell out of itself and the user...). But clearly, that was unacceptable. They continued to shoehorn in irrelevant crap that nobody wanted. Eventually it got so bad that it wasn't even very good at being an FTP client any more. I've since seen that repeated innumerable times since. A product is completed, but people still have to be kept busy with fake work that destroys everything they built. The fact we still use the structures and ideas designed for factories and assembly lines for modern companies is ludicrous.

As written by the Conway of "Conway's law" in 1968:

As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization. This is an inappropriate motive in the management of a system design activity. Once the organization exists, of course, it will be used. Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

This is also the trajectory of Winamp. An application that was complete by v.2. But you couldn't just have an MP3 player. No, it needed to play videos and radio stations, plugins, skins, etc. By v.5 I barely recognized it and all the new Windows it opened when loaded.

See also iTunes, the Mac version, iTunes for Windows has always been shit.

> But clearly, that was unacceptable. They continued to shoehorn in irrelevant crap that nobody wanted.

It will be interesting to see if the SaaS subscription/rental model changes this. Or if they feel as beholden to adding features each release as people trying to sell software releases to get upgrade income.

That's very true. Sometimes I wonder what the team behind WhatsApp does all day. They released Web and voice calling, but nothing since, and there's nothing to keep us expecting new things. No new features are added. Yes, they have to squash bugs and that is endless. Maybe work on a better infrastructure and make it more stable, but we'll never know about. Other than that, it's solid already and doesn't need anything else.

But then again, there's a paradox: if they do nothing and someone shows up that, for some reason, steals their customers, they can get in trouble, like Orkut fell and was "replaced" by Facebook. If they do something that breaks the experience, they can loose users to another player (recently in Brazil, WhatsApp was banned for 48 hours and lots of users signed up for Telegram. It wasn't WhatsApp's fault, yes, but it's just one more showing of how easily users migrate when they're not pleased).

So what do you do? You have to be careful with where you take your service. But standing still is just waiting for someone to come and stab you.

> Someone has to keep the developers busy for the 40 hours a week they must be in their chairs to get paid.

I thought Hacker News and Reddit handled that. :

I think it takes a technical lead who has the vision & skill to balance house-keeping work with new feature development. It can be both technical as well as political skill.

One methodology that I employ is "visibility-based development" where we will save up some super easy tasks that may have a big visual impact. When we need a sprint or two to get some boring clean-up work done, we'll throw in a few of those easy tasks with it. We've had some releases that look like a big, major release but in reality we only spent 1/2 a day on the features that seem big. The rest of the time was under the hood cleanup.

In some cases it's not simply your customers that require the illusion, but the management team as well. If you have a management team that gets uneasy if they don't see new features happening with every release, I highly recommend using this technique.

It seems like technical debt. Lots of what causes bloated pages can be fixed with simple solutions like scaling down gigantic images. I agree there are still major design decisions that can have a big impact, but there are also lots of things that can be done in most cases without too much elbow grease. For example simply installing Pagespeed will optimize a page that previously would take many architectural and dev hours to fix. So maybe the debate should be are the automated tools like Pagespeed moving at the same rate as our appetite to create more bloated pages.

Also going back and cleaning up resources (css and js references). Lots of dead css is out there in the wild

I find in most cases it's not your customers that require this at all. The majority of Gmail probably don't want it to change.

Pretty much, the basic HTML version of Gmail they strongly advise you against using is closer to the Gmail I want than the Gmail that they push by default.

Heck, that goes for most of Google. Look at this beauty: https://www.google.com/?noj=1&gws_rd=ssl Why is this not still the default google.com?

> I think it is because people ... get bonuses and paychecks for creating stuff more than tearing down stuff. ... You'd produce a better perception by claiming you added / created / built, rather than deleted.

It's not about creating vs. removing "stuff". It's about value and advancing business objectives.

That's to say that your citation doesn't carry weak perception b/c it mentions removing stuff, but rather b/c it fails to mention the value that created. A better way of wording it might be something like:

"improved [site performance, or dev efficiency, or something else] by XYZ% by removing low-use features, without sacrificing revenue or customer satisfaction."

... b/c simply removing features (regardless of LOC) used by 10% of a user base, in and of itself, doesn't offer any justification or value. I'm not saying it can't, just that I'd be concerned if that happened without strong rationale and a measurable net positive.

And the same goes for adding or building stuff. E.g. If you wrote a project management system at your previous job, focus on citing the number of hours or projects it tracked, or how it reduced the number of meetings required. The fact that you "built" it isn't as interesting as the value it created for the team/company.

So if positive perception is what you're after, focus on presenting measured value. Then, whether it was created by adding or removing is a non-issue.

Not only designers and coders, but managers too.

Managers are rewarded and promoted based on everything they & their team "do", not on what they "undo" or "don't do"

So manager x adds 10 things to the website, gets rewarded and moves on, then their replacement adds 10 more things, gets rewarded and moves on etc.

It's in the interests of those managers future careers they don't allow anyone to remove the things that were added during their reign, otherwise the list of things they "did" won't be very impressive.

That reminds me of the story which I believe was posted on here (might've been somewhere else) a year or two back about LG TVs and their interface everybody loves - it was a total accident. LG had (might still have, dunno) a program in place where managers got a bonus for every feature they spearheaded which shipped in a product... this resulted in managers from many different teams shoehorning in whatever they could into the 'Smart TV' interface. There were 2 separate 'app stores', multiple inconsistent interfaces, it was slow as molasses, etc. LG acquired the WebOS team and they adapted WebOS to the LG sets just as an experiment... but someone took one of the TVs they had it running on to a trade show... and everybody absolutely loved it because it was simple, direct, uncluttered, and fast. It caused LG a huge problem because it clashed with their corporate policy that encouraged the other bloated interface.

I honestly think that a lot of companies should seriously re-evaluate how they function. Once a product is perfected, the developers should probably be switched over to being paid "on retainer", so that they continue to get paid but do not have to go into work constantly and maintain a 40 hour work week. Let them work from home, and just require them to be reachable. When maintenance is needed, ping them to do it.

I think hardware companies are especially bad at this. When I was young my parents had a colour TV that was 25 years old before they replaced it. Even then it still worked perfectly fine, they just wanted to get a flat screen that took up less room. Now it seems you are expected to replace TVs every couple of years...

I hadn't heard of the LG/webOS story, but it's a good read: https://gigaom.com/2014/08/28/a-failed-experiment-how-lg-scr...

Yap. It reflects not just directly on the product but on the team dynamics.

I have seen this happen at least twice in the past: start with a great team, smart people, self-sufficient. New manager comes in. What does the manager do? Stay by and watch the team do what they do best. Nope, start to set up meetings to improve communication, to streamline, to optimize, adds new rules , new Kanbans, some agile thing maybe, intensify devops a bit. "But why? it doesn't make sensse". Developers are wondering, watching their motivation and productivity get sucked out.

But it does make sense. The manager has a manager. When the end of the year comes, they'll have to report "I did X, implemented Y, facilitated Z etc". They are paid more than the average developer, their know it, the expectations are high. They have to do those things, so that behavior starts to make more sense.

Last two jobs I have been at the coder(s) were the ones wanting to refactor, and management just wanted new features, completely ignoring technical debt.

Be careful - you are generalizing which will lead to issues for your interactions with your superiors.

Good managers remove things when they serve no purpose (prevent extraneous development), when they aren't being used (reduce technical burden / debt) because they look at the data, and the changes they make are tied directly to the success of the business.

This assumes a bit of a functional work environment, but if you aren't inside of one, the problem you are dealing with isn't bloated webpages, its bad management.

Many industries have a similar curse. One very visible example is the satellite news gathering (SNG) trucks owned by many local TV stations. These things cost a lot of money, and are ideal for covering breaking news stories in some remote locale — impending hurricane, manhunt, fires, etc. Because those events don’t happen every day, what you see them used for are very pedestrian, boring stories that don’t require them. Why is there a shivering reporter standing out in the front of the statehouse or courthouse for the 10pm newscast, talking about some minor piece of legislation or arraignment that took place 12 hours earlier? Because they spent all of this money on the damn SNG truck and they’ve got to use it for something.

Actually, they are used because news directors want to be able to break up the show with outside broadcasts to avoid the news simply being two people talking from a desk.

In my opinion, that's the type of thing that a news director would say to justify the expense of a new truck. I am not trying to be snarky, that's my take based on previous work experience for a morning newscast and a long-time interest in the business of news.

I would add that modern broadcast news has always relied on other types of imagery to break up the anchor shot, chiefly prerecorded reports from the field (which do not require a truck -- at my station the photographers and reporters used ordinary cars) and weather screens. The SNG trucks are nice to have when something big does break, but most of the time they are simply not needed ... hence the contrived uses and excuses.

I think the sharp decline in costs for competing technologies are forcing a rethink of newsgathering costs. In recent years, helicopters have been replaced by in-studio CGI based on traffic maps and (on occasion) drones. This trend will accelerate, although I think one of the main expenses -- "talent" -- won't go away. Viewers do like personalities and on-screen charisma.

This seems so true. Another thing I've seen employed is the idea that constantly "improving" the product is necessary. I'm not sure if that's born out of fear of not being relevant anymore "when there's all these sweet websites that play hovering videos" or whatever the latest thing some product manager saw when (s)he was trying to figure out how to look like (s)he should still have a job, or what.

I think there's huge value in constantly asking if you can improve and asking how you can improve. But the keyword in that sentence is IF.

There's absolutely nothing wrong with considering a change, deciding it isn't a gain for your users, and then NOT doing it. It may not be a glamorous call, it may not be a resume item, but that's real product management right there.

Something analogous happened with GM cars. Engineering group prestige increased with the volume of your subsystem under the hood, so everything kept getting bigger, and cars kept getting bigger.

There is probably no way they'd end the year with "Yap, site worked great, we did a nice job 2 years ago, so I didn't touch it this year."

They should take a page from Toyota's book and have 10 separate teams with projects for Gmail's next version. Except, instead of evaluating with metrics, reduce to just 3 options and expose the next versions as public betas and take measurements on how well people like them.

Are you suggesting if something is used by 10% of users, developers should strive to make it go away? Although eliminating 10k lines is definitely good, what if removing that feature means that 10% of users who use it are no longer paying customers?

The business reality is when a feature is added, there's almost no way to remove it, because the result would be less money to pay salaries. Hopefully the benefit would result in more than 10% of additional sales with better features and changes.

I'm at a place where we have an extremely large app and there are probably a hundred features that are each used by 10% of our customers. It's a bit of a kitchen sink app for a vertical market.

I certainly would not say that we "strive" to make any feature go away. In some cases, though, a certain feature can actually prevent us from implementing new functionality. It's always a tough decision. We don't want to leave any customers behind, but at the same time we don't want a small minority of customers preventing us from moving forward either.

I don't think these kind of decisions should be left up to a lone developer to make on their own. The developers, sales, support, management and everybody should be working together to understand our customers and what our mission is. It's not easy.

> Are you suggesting if something is used by 10% of users

It was just an example.

> what if removing that feature means that 10% of users who use it are no longer paying customers?

I can think of scenarios where that feature for 10% of customers is causing issues for rest 90% of customers, or eating up all the support time or ops teams' time.

> The business reality is when a feature is added, there's almost no way to remove it,

Even code-wise. Once a framework is adopted, it is hard to rip it out to make things lean again without making a fundamental change.

Have to be realistic, today is an era where the bloat is the automotive equivalent of tailfins, spoilers, and 15 drink holders, not the trunk or the concept of the passenger seat.

This would seem to me to be a good reason to not have designers on staff that outweigh the needs of product development. If your designers are looking for change for the sake of change, you may have too many designers. I think Silicon Valley has gone a bit overboard on designers in recent years.

Google has a "VP of Design" now, and the one commonality of his tenure has been massively increased page load times, and buttons moving to different places regularly for no apparent reason.

I think Bill Gates and especially Steve Jobs got it right. They regularly tried out the products and critiqued the interface and after many iterations it turned out like all their products were created by a single well minded person. Win95 and iOS6 were so awesome at their time. (the same was true for the first few years of Facebook)

Whoever replaced gmail's edit widgets with the new stuff surely has never tried to use it. Basic stuff like selecting text is broken. Why can't they keep a HTML text edit widget for plain text mode? Because it would make too much sense.

Does reframing "cut out crud" to "saved $X in bandwidth" help? Or is this the kind of thing that customers / employers don't see?

In my experience it doesn't get prioritized. I worked on a product where everyone including product management complained about performance but it always took very long to get fixing that prioritized. In one case I spent my weekend adding pagination to some pages that everyone had been complaining about being slow but no one thought should be a priority to fix over new features.

If it's unexpected cost and an emergency fix, probably. But if the cost is already factored into the budget, it's unlikely to have a that big impact – worst case, management will be annoyed that you ruined all their budgeting.

Find me a company that actually is excited by a resume like that, and they'll rise to the top of my search when I look for my next job.

Like someone else said, highlight the value created or costs saved, not the work you performed.

I have "appraised transport policy to reduce the number of agency drivers employed, projected saving $50k annually with no loss of service" rather than "used linear optimisation of transport schedule in Excel".

> Put this on your resume...

I have the opposite opinion. If you're applying for a job with me and have something about cutting 10k lines of crap then you've got my attention.

Being able to recognize when to delete code is a very valuable and underrated skill.

It's not only due to the people working on the site, but those paying to have it made too. A lot of clients also associate 'fancy' and 'complicated' with good, and then end up demanding every every feature and gimmick you can imagine in some attempt to look 'modern'.

So you end up with the designers, developers, content editors, SEOs, managers and clients all wanting different things at once, and none of them want to remove what's already there to lighten the load.

I blame micro-managers for a lot of website bloat. These guys can't code and they can't manage, but for some reason we 'need' them so that clients cannot talk to developers, a game of Chinese whispers is needed via the micro-manager, on need to know basis.

Because micro-managers lack technical competence, they 'shop' for solutions. They have to buy into advertising claims from SaaS companies that will perform wonders all for a small, per-transaction fee.

Why use the reviews feature that came with the CMS system when you can just add some third party thing for doing the reviews? One simple script and a tag, job is done, Disqus is on the site and any problems with the reviews then becomes something 'supported' by Disqus. No developer of the front end variety is needed to theme up the reviews that came with the CMS. Megabytes of stuff gets added instead of a few lines of CSS and the text content of the reviews.

Need a slider/banner thing for the homepage? Forget the actual requirements for a small selection of images that click through to somewhere else with normal hyperlinks. Instead pay for some bloat, only $70 a year, chicken feed! Let the developers struggle to get this behemoth working and ignore their protestations that animating a simple carousel is not 'rocket surgery'.

That pesky search box at the top of the page... Why use the built in CMS search augmented by a few simple site specific rules to fix the things not found? Instead of doing that, go to some 3rd party SaaS app that cripples the server downloading stuff from one index to put in another, far, far away index. The SaaS service will do everything and better than what the in-house fixes will deliver, the advertising says so and they have pie charts to prove it.

Those stupid social network icons. Again, let's Add This and see if it will float with those lead balloons added. It make perfect sense to add thirty scripts to the page just in case someone needs a 'Tweet' button.

Usually these inept decisions are made in good faith by a manager who does not know what he/she is doing. But they have managed these sorts of projects before, right?

Those bloat items usually do have a knock on effect of implementation difficulty. But, by then, these 'agreed on' features have been paid for, approved by the client and handed down from on high by some micro-manager.

I have never met a developer that goes with the bloat out of choice, they just know that a job is just a job with a paycheck. Their little bit of the project, e.g. 'frontend' has no concern for page load time, they just have to implement designs handed down to them by some micro-manager that has got some other person that can't code to do some pretty pictures in Photoshop. It is paint by numbers for the 'frontend' guy, performance is not their thing. Same with the backend guy working on that API integration for pulling through those 'tweets'... Again, no responsibility for page load time, for their work is in the backend, not how the site renders.

Another layer of people that can't code gets added with the UX guy. They might get only as far as designing the pages the Photoshop newbie has to 'draw', adding 'lorem ipsum' text accordingly. Yet these UX guys never seem to roll up their sleeves and optimise the stack for a speedier UX experience. No, why do that when you can go to meetings and conferences to learn how other people do these things?

Then there is the outside SEO agency. Let's face it, the people in SEO didn't do degrees in anything involving difficult things like programming or science. Yet these guys want another dozen scripts added to the page so they can measure how their 'campaigns' are going. More bloat signed off by a middle manager.

Too often the figures that matter (sales) are far from accurate or completely missing from the SEO agency reports. All the numbers that matter are all there in the server logs and the sales order tables should they bother to check, but why do that when you can pay for yet another analytics SaaS? Who cares if a percentage of the site visitors use 'ad block' of some sorts, rendering all efforts at this type of frontend stats scraping useless.

Newsletters. Who is for a newsletter? Again, how hard can it be to send an email? Not that hard, add an SPF record, get the to and from bits correct and that is it, good to go. But no, only idiots do that, what you need is to pay a SaaS a small fortune per email sent and wow, again pretty pie graphs deep-stalking the readers. More bloat with yet more customer data shuffled across the internets.

This point about newsletters is a backend thing rather than page bloat however it is typical micro-manager FUD thinking. Everyone knows it is a nightmare running your own mailserver, everyone knows that it takes one customer to mark one email as spam once to make all future emails effectively go into a big spam filter forever more, never to be seen again. With this being the case, best pay $0.02 per email to some SaaS to 'do it properly'.

No micro-manager knows that a 'send only' server works pretty well with next to no configuration, that SPF record still has to be setup if using 'monkeychimp 360' or whatever and that these 'tracking benefits' are not beneficial at all except in theoretical edge cases. (All they do is remove limited focus away from the numbers that really matter and stop common sense being used).

Then there is the spamification of emails - does that really happen if not using the SaaS service? Find out first then move to the 'Saas' when one's server gets blacklisted for spewing out spam-tastic-click-bait? That would be the cost effective choice, but no, let's just rely on a third party service for something as basic as sending an email!!!

Helpless micro-managers, the same ones that 'never got fired for buying IBM' a generation ago are the culprits in small to medium sized enterprises. These guys can't code. And code IS important, it is not just something you get a programming resource to do. (okay it is).

These clueless micro-managers can't have confidence in their team to deliver because they have no confidence in themselves to do anything actually difficult, i.e. needing a textbook to learn or fundamentals to grasp. Consequently they are forever being less than cost effective buying cheap bloat instead of engineering something better.

The bloat add-ons are also bloated up to appeal to the micro-manager mindset. That homepage slider, let's sell a slider that does all those tacky DVE dissolves that television was cursed with in the 1980s!!! Rather than the simple transition people know, let's have 200 effects to choose from! So micro-manager buys the 200 effects slider because it is 'better'. Forget that only one effect was needed, go with bloat and don't step back and think for a moment that a banner slider can be done by mere mortals using things like hand-written code. Why reinvent the wheel when you can have two hundred on one of those caterpillar tracked things they used to have to move the Space Shuttle to the launch pad. We're enterprise too, right?

I don't believe there is a coder in the world that goes for bloat, unless they are useless. I also believe that coders go with whatever the team decides, i.e. what the micro-manager hands down from on high. They suffer the bloat to make others happy, a pragmatic thing and certainly not to get a 'bonus'.

I think you identify a lot of the causes of page bloat here, but I'm not convinced developers are blameless. Things we do:

  - Load all if jQuery when we just need a few functions
  - Load all of Bootstrap when we just need a grid system
  - Load a whole templating library for one little widget ("we'll need more later")
  - Load a whole icon don't when we're only using two of them
  - Load a whiz bang carousel library when we only need to roatate a few images
  - Use prefab themes that do all of these things and more (shudder, *parallax*) with the idea of providing nontechnical users with the ability to do anything they can imagine without learning to code a little bit

I don't think this is all incompetence (though plenty of it certainly is). Some of it is just needing to get shit out the door before the deadline, and some of it is attempting to plan ahead (eventually we're going to use more of jQuery, right?). Likewise with your examples - I don't think this is always micromanaging, sometimes it's just resource management. If you don't have the developers to manage an email server, why not pay a little money to a third party and let them manage it?

I saw some devs who slap a JQuery plugin there, another plugin there and so on and various other third party JS libraries. And then the page load involves 1MB.

Or SaaS websites that have a single-page web app with a 4MB JS file. And their user interface looks like designed by an committee. The single page web app has a long loading time, looking with DevTools it turned out it's a GWT+Ember ugly monster, that was slapped onto their old rusty Eclipse based Java product. The little information they can show is shown on a 7-times nested navigation page structure so they can advertise it as "drill down" whereas competitors show all info on a maximum of 2-3 times nested pages, and most info is visible without a single click. And the bad one is very much into enterprise with a huge sales stuff, the better competitor is a SaaS-only company.

NIH much?

Developers cost a lot of money. Mailchimp doesn't. Maybe your "clueless micro-managers" know a little more than you think.

As the "coder" in your description, I was always happy to refactor / simplify code, and remove unnecessary cognitive load (i.e. unused features). But management were not interested in that at all.

The simple solution seems to be to add the absolute value of the code subtractions to the value of the code additions.

This would weight code refactors with the weight they deserve...

I think those other things can be worded in a positive way though. That could make it worth it?

Optimized website. Improved loading time by .3 seconds on average for all users. Created cleaner and more efficient design and implementation. Etc...

> "Cut out 10k lines worth of crap only 10% of customers used, stripped away stupid 1Mb worth for js that displays animated snowflakes, etc"

Well, those 10% would probably be pretty pissed off if you did that...

justifying their own existence, it seems

It's also about the ads bubble:

> "Or the bubble is going to burst. [...] we need to ban third-party tracking, and third party ad targeting. Ads would become dumb again, and be served from the website they appear on."

It's already insane that many news well know websites load 25+ third party trackers with 4+MB of waste. All these poor battery powered devices have already a hard time.

The thing is, removing bloat and making site faster can be seen as feature. Too bad that many will start to look for the new framework and lib to do just that :(

"Cut page load time by 90%" is also an accomplishment.

Thewebsitereceivedanunexpecdtederror.Plesetryagainlater.com

I hope to see less of this in 2016.

Happy New Year!

> stripped away stupid 1Mb worth for js that displays animated snowflakes

I implemented this in 740 bytes uncompressed.

> It's like we woke up one morning in 2008 to find that our Lego had all turned to Duplo. Sites that used to show useful data now look like cartoons.

That is the best description I've heard of the recent trend of making every item cover 30% of the page so that you can only fit 2 data points. What is the deal with all this? Keeping the number of options down is one thing, but making repeated tables of data gigantic serves no purpose at all. It might look good in a thumbnail of a screenshot but actually using it is next to impossible.

I particularly like this quote:

These comically huge homepages for projects designed to make the web faster are the equivalent of watching a fitness video where the presenter is just standing there, eating pizza and cookies.

That is what we call fashion. With the bandwidth and CPU/monitor power, the utility part is no longer in focus, so fashion part dominates.

Fashion do not need to make sense. Sensible folks (the minority part of family) may choose to ignore fashion; but if you are criticizing fashion (with seriousness), then you are in the wrong game.

If we're using fashion as an analogy, it's kind of a mixed bag.

There's both this type of fashion: https://s-media-cache-ak0.pinimg.com/236x/c0/66/12/c06612029...

...and this type of fashion: http://img.izismile.com/img/img7/20140521/640/fashion_runway...

out there.

Things can be fashionable, yet crisp and usable. Things can also be crazy, stupid (to most), and groundbreaking (to a few). Put another way, fashion currently dominates, but that would be okay since we don't need to sacrifice good visual design in the name of performance any more.

Unfortunately:

* People get lazy. * People don't user test. * People like to follow trends. * Designers and developers get micromanaged.

...along with all of the other monkey wrenches that most developers and designers have gotten used to. People end up building cool-looking websites that aren't as usable as they should be.

On the other hand the creative, intellectual minority that wants and needs fast access to information is left behind which is a cultural and economic collateral damage of fashion.

That would explain why engineers often dress like shit.

He gave that talk in Sydney, Australia. Oh, but if only The Sydney Morning Herald had been there and reported on it! We could have read about it on 3.4MB of downloadable content (actually, not just "content").

Their beta website takes up 1.1MB. I highly recommend that you add the following Adobe busting filter though (given that in their "Satellite" script Adobe attempts to bust your ad-blocking, I think you should bust their busting...):

  http://assets.adobedtm.com/*$script,xmlhttprequest,domain=~assets.adobetm.com

This is the HN community's fault (not even web fora in general, it's HN specifically). Post a page with the default text size here and you'll get a raft of complaints that your text is "tiny". No, my text is the same size as web page text has been for decades. But users with enormous monitors don't set their DPI correctly and web browsers don't display pages at a sensible scale for the screen size.

A sensible scale is defined by the user's eyes, and most sites are not designed with impaired vision in mind. Web page text has never been set at a good size by default, and most designers make it smaller than the default because they have good eyes and aren't thinking about visual impairment.

I'm more likely to complain about the comically huge fonts on sites like Medium or various "modern web designer" blogs. When I browse on my old 1024x768 laptop, often there is literally less content on the screen than what used to fit on my old CGA monitor (80x25 characters). And about half the time they deliberately slow down the scrollbar to make it even harder to read. If I'm lucky, zooming out won't trigger an increase in font size, and then I can actually read the text for 30 seconds until "sign up for my newsletter" pops up and I leave.

The default text size in every browser, as far as I'm aware, is actually 16px. The text on Hacker News is 12px, because virtually every designer decides they know better than the browser settings.

Which one are you thinking of as the "default"?

I'm thinking the size you get when you literally do not specify a size. If you say that's 16px then I believe you.

And yes, HN itself is smaller than that.

Nobody should be specifying fonts in pixel sizes anyway. Just use ems everywhere and let the browser scale them for the current display resolution.

"Designers" hate this because they can't massage every pixel into just the right location on their cinema display and can't be bothered to accommodate different hardware. They'd rather just send users 300 DPI images of everything and let the proles deal with downsampling them on their ever so inadequate devices.

The CSS px unit is actually usually (for high-DPI devices) defined as 1/96″.

It doesn't matter how big my monitor is; I walk away from a lot of websites thinking I need a larger one.

I think it had to do with mobile. Things are scaled to screens, and mobile is the lowest common denominator of what can fit on a screen. Just blow that you to desktop on you have Duplo.

"Chickenshit Minimalism: the illusion of simplicity backed by megabytes of cruft."

This is not restricted to websites - a lot of software has suffered from the same trend, where newer versions look simpler - and often have reduced functionality - while for some reason still requiring more resources than the previous version.

Yes, Windows 95 run on 4MB RAM, Windows 2000 on 64MB. Than the bloat came, and nowadays Windows 10 looks more blant and has reduced UI than ever and still requires and runs as slow as Windows 7 which had a lot of themes and transparent effects and a rather modern and nice interface. No wonder several parts of the interface like the startmenu are now in dotNet. It was already a major mistake that lead to the restart of the Longhorn project which became Vista - the former dotNet based Explorer and shell and WinFS all were dotNet applications and very slow. I run WinFS beta 2 on WinXP on an high end PC at that time and it was promising but aweful slow. Instead of adding the database-like features to NTFS driver (parts of the object features from Cairo project are still there), they added an filesystem filter driver in userland and a dotNet service. Needless to say that idiotic design and relying on dotNet for a mission critical component never worked out. Vista shipped with an improved WinXP desktop search.

Windows 95 could almost run on 4MiB RAM, but that's with heavy swap use, as is the advertised minimum, 8MiB. 95 really needed 16MiB or so, to be fair to it.

Windows NT 4 could run in 16MiB but ideally had 32MiB.

And Windows 95 had no modern security checks in place, so good luck with Internet access. That stuff has performance costs. Also people seem to forget that we had to reboot those machines all the time due to crashes, more code that has performance hits. Yes there is definitely bloat but there is also a lot more going on underneath the seams than before.

95 perhaps. NT was rock-solid.

What kind of examples do you have in mind? I don't disagree entirely...but I've found that sometimes what seems like gratuitous weight is a result of the amount of code that has to be used to not only fix past bugs, but reconcile all the new standards and external mishmashes (such as interoperability with operating systems and other libraries that themselves have been upgraded) that have come into existence.

The magnitudes of increase in lines of code for the installers we download definitely outpace the increase in functionality, compared to 1 & 2 decades ago...but we have a lot more systems to interpolate with. That said, I'm always gobsmacked when I download a relatively new game from Steam and it weighs in at under 100MB...which would've been 70+ floppy disks back in the day :)

(though in the case of games, the increased weight is most often due to multimedia assets)

The Opera browser is an egregious example. It used to be a browser that had everything plus the kitchen sink, it was blazing fast, and really small (both in executable size and in RAM). It managed to keep that way for many years, constantly improving and packing more useful features while keeping the small footprint, I'd say until version 10 or so. Versions 11 and 12 starting removing features and introducing bloat, and then after version 12 the browser was switched to Blink and became a Chrome clone that didn't have even a quarter of the features of the previous versions.

I think probably one (not the only) reason for this was the "reconciling all the new standards and external mishmashes" you mention, but how does that make the weight less gratuitous? It only means that the blame is not exclusively on Opera but also on other companies, committees, etc., but it doesn't make the phenomenon any less ludicrous and sad.

Not the poster and not quite what you were talking about but I was recently impressed that the new Node version of the Wordpress control panel is 126 Mb whereas the old php version including that and the rest of wordpress is 24 Mb (both unzipped). I guess the Node thing includes Node and a browser but it still seems to have quite a good bloat to functionality ratio.

I wonder how much of that is simply npm duplicating libraries (at slighly different versions) due to its no-shared-dependencies approach?

https://github.com/Automattic/wp-calypso/blob/master/package... uses ~130 libs. After npm install (incl. dev deps), node_modules/ weighs 170M file size (and whopping 550M(!) disk size). Let's check duplication. Dirs: (Assuming equal size & name indicate equal content)

    $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | wc -l
    6259
    ~/wp-calypso (master) $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | uniq | wc -l
    3286
    ~/wp-calypso (master) $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | uniq --skip-fields=1 | wc -l
    2799
    $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | uniq --skip-fields=1 --count | numaverage 
    2.23615576991783

Bytes:

    $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | tr -d , | numsum | numfmt --grouping
    170,022,500
    ~/wp-calypso (master) $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | uniq | tr -d , | numsum
    117,107,993
    ~/wp-calypso (master) $ sed 's@\S*node_modules/@@' DU | sort -k2,2 -k1,1 | uniq --skip-fields=1 | tr -d , | numsum | numfmt --grouping
    91,895,673

=> dirs appear in ~2.2 places on average; ~31% of total size is wasted on exact dups, ~14% more spent on different versions on same lib.

    $ npm dedupe
    ...
    $ $ du --summarize --apparent-size node_modules/
    166,097,508	node_modules/

Underwhelming! Only 2%?! dedupe is constrained by npm lookup algorithm (can only lift equal versions to parent dir) but 2% is useless. Should have used sym/hard/reflinks.

Anyway, I now know npm's exact-duplication overhead is not huge (though could be linked); inexact-duplication is small enough to be easily worth the ability to mix versions; and that the new control panel is indeed bloated [however I assume it has more functionality than old?].

The entire iWork suite of Apple software suffered this. I used to use PAges and Numbers for a LOT of business stuff. Now it's not even an option. They don't do half the stuff the old versions did.

A recent example of this is buildbot. The current version (8.x) has a very no-frills, utilitarian python/jinja UI which has served me, personally, and many other open source projects well (chromium, mozilla, LLVM, etc). Version 9 is a rewrite two years in the making using angular with the modern JS toolchain for its frontend. I tried out the latest (beta) build, and from what I can see I think it's exactly what you describe: more resources with less functionality. Time will tell whether the final version lives up to its promises but I'm very skeptical at this point.

Google invented their own name for it - Material design.

I laughed at this harder than I should have.

It's funny because it's true.

For the most part this is a pretty good article. I find that the more removed someone is from the real, vanilla HTML the more bloat they will inadvertently bring in. Need to focus a form? Download an angular plugin because you're using angular, why would you want to do it natively!

The native DOM is pretty inelegant but at the same time it can't be ignored; it must be understood. You don't need a new plugin, font, css reset file to accomplish everything you want and you can even do it cleanly!

I was a little concerned about this part though:

> [...]ad startups will grow desperate[...]This why I've proposed we regulate the hell out of them now[1].

I'm all for downloading of your information but some of the other things are just a bit off the mark. Like deleting your data can be problematic in any type of collaborative / productivity app. The right to go offline is nice in theory but many devices may actually need the internet to work and without it it wouldn't be able to function. I mean yeah the examples given are good examples as to things that can be "smart" and "dumb" but what about similar things, like sensors and other types of trackers? Seems like market pressures would be better to change those items than regulation.

[1] http://idlewords.com/talks/what_happens_next_will_amaze_you....

> Need to focus a form? Download an angular plugin because you're using angular, why would you want to do it natively!

Otherwise known as CBDD -- "Code Bootcamp Driven Design"

Byte magazine had a cover feature 23 years ago entitled "Fighting Fatware".

We're doomed to repeat history...

https://archive.org/details/BYTE-1993-04

The article starts: Dave Brown, a Keene, New Hampshire-based entrepreneur, got his Christmas wish last year - a copy of Microsoft's Access relational database manager for Windows. Excitement turned to disappointment, however, once Brown tried to run the program. Despite the fact that his system had the 4 MB of RAM that Microsoft recommends, Access was "hideously slow." A call to Microsoft technical support revealed the truth: He needed at least 8 MB of RAM to achieve acceptable performance. Now Brown has two options: He can spend $200 for more RAM or wait for version 1.1, which Microsoft claims will run better with 4MB.

A second notable quote: One controversial aspect of the software-bloat problem is the increased use of high-level languages, particularly C and C++. While assembly programming can produce very tight code, the common belief is that with C or any other high-level language the code will be larger. However, a good programmer, says WordPerfect's LeFevre, can minimize the growth of code while making the most of a high-level language's advantages. Lotus Development (Cambridge, MA) ported 1-2-3 from assembly to C between versions 2.01 and 3.0. Consequently, the code size nearly tripled, from 1.4 MB to 4 MB. Not all of that growth is attributable to the difference between C and assembly-version 3.0, for example, included the printing utility Allways and had significantly more features-but it was a major contributor. The resulting product would not run acceptably under DOS until the company delayed its release to compress and optimize the code.

On Google's AMP, which endlessly reloads a picture carousel: "These comically huge homepages for projects designed to make the web faster are the equivalent of watching a fitness video where the presenter is just standing there, eating pizza and cookies."

On trying to fix the problem: "These comically huge homepages for projects designed to make the web faster are the equivalent of watching a fitness video where the presenter is just standing there, eating pizza and cookies."

Someone recently commented on one of my web pages for being unusual in that the pictures were all directly related to the copy.

> On Google's AMP, which endlessly reloads a picture carousel: "These comically huge homepages for projects designed to make the web faster are the equivalent of watching a fitness video where the presenter is just standing there, eating pizza and cookies."

> On trying to fix the problem: "These comically huge homepages for projects designed to make the web faster are the equivalent of watching a fitness video where the presenter is just standing there, eating pizza and cookies."

Did you mean to have the same quote in both paragraphs?

Oops, sorry.

A large part of the code bloat problem can be resolved if the JS ecosystem's most popular build tools had support for some of the advanced compilation features in Google Closure Compiler, like dead-code elimination and cross-module code motion [1].

ClojureScript makes heavy use of the Closure Compiler's advanced compilation features, and as a result generates code that is often orders of magnitudes smaller than what it would be without those features. Think of what a bloated mess a ClojureScript app would be if it had to include the entire ClojureScript standard library with every build. This is exactly what's happening in JS world, where developers include by default the entirety of any utility libraries they're using when they're only calling a handful of functions from them.

Before anyone starts suggesting "just use Closure Compiler for JS projects", it's really not that simple (at least when I last looked into it). There's a huge amount of friction involved in using the Closure Compiler for a regular JS project (most of which wouldn't apply to a ClojureScript project because its JS output is machine-generated, and its build chain is designed to work exclusively with the Closure Compiler and all its quirks), namely writing all your code as Closure Modules, defining externs for any third party libraries you use, and setting up the JVM-based compiler itself and integrating it with the rest of your build tools.

I hope to see some improvement in this area with the dawn of ES6 modules, since they were designed from the ground up with static analysis in mind. Robust and accessible dead-code elimination and cross module code motion for ES6 modules could easily bring about a revolution in JS code sizes on the web.

[1] https://developers.google.com/closure/compiler/

"A large part of the code bloat problem can be resolved..."

...with deflating the front left tire a little bit, putting a magnet on the gas cap, folding in the side mirrors.

I think you missed the point of the talk (or didn't read or watch it), and the kind of solution you proposed is mentioned there.

(PS I agree with what you said, though, regarding JS dead code elimination.)

I was only commenting on the first-party code bloat side of the problem mentioned in the article, and I realize this only addresses a part of it. Asset bloat and third party scripts are entirely different beasts that can only really be tackled on a case-by-case basis.

You're exactly right; ES6 modules can solve this. Rollup (an ES6 bundler) has tree shaking [1] and also smaller bundle sizes in general [2].

[1]: http://rollupjs.org/ [2]: https://github.com/nolanlawson/rollup-comparison

Beautiful!

And it looks like JSPM/SystemJS already has it integrated [1]! I'm wondering if there are any similar efforts in the Webpack ecosystem.

[1] https://github.com/systemjs/builder/pull/205

I think Webpack 2 will support tree-shaking as well.

The general term is "whole program optimizer". It what Google does to Chrome (but not Chromium IIRC), and what Proguard does to Java (e.g. Android) apps.

Define a couple entry points and use static analysis to pare down the code to that, for minification, obfuscation, and performance.

One nice part of ScalaJS... get the free dead code killer.

Overall, this was a good article and it had me eyerolling at some of the dumb...dumb things people do. Like the internet.org background logo continually downloading a movie. Whoever did that should not be making websites.

Likewise, I took a look at my project and was able to chop the JS size in half by yanking out some libraries I no longer use, so now the JS and CSS are each under 500K each. Still a 1.2MB load overall; but it's also cached and an app people will visit more than once.

I hate that my CSS is close to 500K though. The design itself isn't that complicated; but I'm basing it off of a bootstrap theme and until I know what I'm using I can't prune much.

And I think that's a source of some bloat: frameworks and libraries. But, It's a tradeoff; it's code I don't have to write, which lets me get a better product to market faster. Sure, I could really spend the time to prune all my assets; and i think one day that will be a good move to make. But for me, and for many other projects, it's a tradeoff.

Usually media is the big one to blame, and things like streaming a background movie and eating up hundreds of megabytes in bandwidth to display it is simply irresponsible.

In Apple's case, they probably want their images to be high resolution, which is understandable. But even then they could (may even already) run it through some compression filters to reduce the size without hurting the quality.

It's something we should all be mindful of. You can, but don't have to go to extreme lengths to reduce the size of the site. There are often some low hanging fruit you can reach for that get you 80% of the way there. And obviously if its site that people a lot versus a site that people will visit once, your priorities for optimization are going to be different.

For pruning your CSS: http://stackoverflow.com/a/3113120

The problem with CSS pruning is that you have to run it over ALL sites you have and all kinds of dynamic pages you generate - or you experience loss.

Oh that's awesome. Would be even better if you could "start a session" navigate through your website and then see amalgamated results at the end, rather than just a single page.

> The article somehow contrives to be 18 megabytes long, including (in the page view I measured) a 3 megabyte video for K-Y jelly, an "intimate lubricant".

(Warning. Swear words incoming, because the situation has grown far out of control)

Fuck websites with autoplay (or autoplay-on-hover) videos. Fuck them. Whoever has invented or implemented this crap, please resign from your post immediately.

Even in 1st world countries, people use 3G/4G with data caps to work or are in otherwise bandwidth-constrained environments (public hotspots, train/bus wifi) etc. You are screwing over your users and don't realize it.

Also, something especially Spiegel Online comes to mind: 30 secs video clip with a 25s advertising clip. Fuck you.

> Why not just serve regular HTML without stuffing it full of useless crap? The question is left unanswered.

Easy actually: because a well-defined restricted subset of HTML can be machine-audited and there is no way to abuse it. Also, Google can save resources at indexing.

> Easy actually: because a well-defined restricted subset of HTML can be machine-audited and there is no way to abuse it

This is why I personally use NoScript.

People often ask me "how can you stand to use NoScript on the modern web? Isn't it a huge pain to whitelist scripts? Isn't everything broken?"

Nope. Most of the web works perfectly fine without loading Javascript from 35 different domains (as my local news site does). You whitelist a few webapps and you're pretty much good to go. The difference is incredible. Your browser uses a fraction of the memory. Pages load faster than you can blink. The browser never catches up or lags. Pages scroll as you expect. Audio and video never autoplay and distract you. When I briefly used NoScript on mobile, it was a miraculous life-saver that made my battery live forever.

In the past couple years, however, I have noticed a new phenomenon. Remarkably - madly, in my view - there are webpages, webpages that should be simple, webpages by all appearances that consist of nothing more than a photo (maybe more than one), a byline, and a few hundred words of text, that require Javascript to load. As in, you will get a a blank page or an error message if you don't have their scripts enabled.

I don't understand it. I don't want to understand it. I just want it to stop.

I understand that you need Javascript and so forth to run a webapp. I'm not even asking for your webapp to be less than 5MB. Hell, make it 50MB (I just won't ever use it on mobile.) Making applications can be a lot of work, maybe yours is super complicated and requires tons of libraries or some crazy media loading in the background and autoplaying videos and god knows what else.

But please, please, don't require Javascript to simply load an article and don't make a simple article 5MB. Why on Earth would you do that? How many things have to go wrong for that to happen? Who is writing these frameworks and the pages that use them?

"In the past couple years, however, I have noticed a new phenomenon. Remarkably - madly, in my view - there are webpages, webpages that should be simple, webpages by all appearances that consist of nothing more than a photo (maybe more than one), a byline, and a few hundred words of text, that require Javascript to load. As in, you will get a a blank page or an error message if you don't have their scripts enabled."

I use noscript as default and I'm noticing the same thing. I post them to twitter. Here's a sample:

- 'Here are the instructions how to enable #JavaScript in your #web #browser.'

- 'For full functionality of this site it is necessary to enable #JavaScript.'

- You must enable #javascript in order to use #Slack. You can do this in your #browser settings.

- 'You appear to have #JavaScript disabled, or are running a non-JavaScript capable #web #browser.'

- 'Please note: Many features of this site require #JavaScript.'

- 'Tinkercad requires #HTML5/#WebGL to work properly. It looks like your #browser does not support WebGL.'

- 'Warning: The NCBI web site requires #JavaScript to function. more...'

- 'Whoops! Our site requires #JavaScript to operate. Please allow JavaScript in order to use our site.'

- 'The #media could not be played.'

- 'Notice: While #Javascript is not essential for this website, your interaction with the content will be limited.'

- 'Powered by #Discourse, best viewed with #JavaScript enabled'

It shouldn't be surprising that Tinkercad and Slack require JS.

Seriously, did they think Tinkercad was just going to be a pile of CSS transforms?

Seriously, I remember using a web chat client (might have been an old version of mibbit) which was "minimal" JS. Basically server side rendering of the incoming messages plus periodic page refreshes. It was a very poor user experience.

pomf.se used to have:

>Enable JavaScript you fucking autist neckbeard, it's not gonna hurt you

It always gave me a chuckle. Most of its clones still have it (e.g. pomf.cat).

From the FAQ at pomf.cat:

> All filetypes but exe, scr, vbs, bat, cmd, html, htm, msi files are allowed due to malware.

Yes, scripting in html never hurt anybody...

Back in the days of IE4/5 I discovered that turning JS off would very effectively stop pop-ups, pop-unders, pop-ins, slide-overs, and all other manner of irritating cruft, and it's been the default for me ever since. Conveniently, IE also provided (and AFAIK still provides) a way to whitelist sites on which to enable JS and other "high security risk" functionality, so I naturally made good use of that feature.

More recently, I remember being enticed by some site's "Enable JavaScript for a better experience" warning, and so I did, only to be immediately assaulted by a bunch of extra annoying (and extra-annoying) stuff that just made me disable it again and strengthened my position that it should remain off by default. That was certainly not what I considered "a better experience"... now I pay as little attention to those messages as I do ads, and if I don't see the content I'm looking for, I'll find a different site or use Google's cache instead.

Another point you may find shocking is that I used IE for many years with this configuration, and never got infected with malware even once from casual browsing, despite frequently visiting the shadier areas of the Internet and IE's reputation for being one of the least secure browsers. It likely is in its default configuration with JS on, but turning JS off may put it ahead of other browsers with JS on, since the (few) exploits which technically don't require JS are going to use it anyway to encode/obfuscate so as to avoid detection.

I think it is even the default on server versions of Windows since Server 2003.

> I post them to twitter.

Why?

"> I post them to twitter. ...Why?"

As a reminder to myself how lame some sites are and what happens when it's assumed JS is in use.

And on top of that, some redirect you to another page to display the no-js-warning. Then you enable JS for the site and reload but will get the same warning because you're no longer on the page you visited...

I think it is mod_pagespeed that's doing this, kinda silly.

NoScript, at least, has an option to catch and stop redirects of this kind. They can be quite funny when you can see a perfectly loaded page that wants to send you elsewhere.

>I just want it to stop.

You and I are kindred spirits.

I feel it's getting worse. A large % of the links (mostly start-ups landing pages, not articles) I click on HN just present me with a completely blank white page. No <noscript>, nothing! If you're lucky, you see enough to realize that it's probably just a page that relies on JS. It's never a good first impression.

It's getting progressively more annoying to whitelist the TLD as well as the myriads of CDNs that sites are using. Often it's a click gamble: a "Temporarily allow sketchy.domain.com", throwing in the towel and saying "Temporarily allow all this site".

Site embeds a video? Good luck picking which domain to whitelist out of a list of 35 different domains ;) Temporarily allow one, reload, repeat a few times, close tab in anger and disappointment.

It's sorta-kinda a good thing, implemented poorly. What's actually happening is that more things that used to serve HTML directly to the browser, are now just browser-oblivious HTTP REST-API servers. Which is good! API servers are great!

The correct thing to do, after implementing one, though, is to then make a "browser gateway" server that makes requests to your API server on the one side, and then uses that to assemble HTML served to the browser on the other side. (This is the way that e.g. WordPress blogs now work.)

What's happening instead is that the site authors are realizing that they can just get away with writing one static blob of Javascript to act as an in-browser API client for their API server, stuff that Javascript in an S3 bucket, put e.g. CloudFlare in front of it, and point the A record of their domain's apex at that CF-fronted-S3-bucket. Now requesting any page from their "website" actually downloads what's effectively a viewer app (that they don't have to think about the bandwidth costs of at all; they've pushed that entirely off to a third party), and then the viewer app starts up, looks at the URL path/query/fragment, uses it to make an API request to their server, and the response from that is then the rendered page.

Kind of ridiculous, no?

It does sort of make sense to me for sites like e.g. Twitter, where their bread-and-butter is running API servers and writing API clients that interact with those servers. The "web client" is just, then, another API client, written in Javascript and "zero-installed" into web browsers whenever they request a page from the site.

But for, say, a newspaper site, or a blogging engine? Those sites should definitely care about serving HTML directly, even if only for Googlebot's sake.

I think you really don't get the point of the article. This kind of crazy overcomplexity seems like one of the many things the article author would lump into excessive complexity for the sake of complexity.

Yes you can implement a REST API thingy and then an application server that templates it all, and maybe that logic is written in JavaScript and is the same code that executes on the browser so you basically have a sort of headless quasi-web-browser assembling pages to serve so you can reuse the same code on the client side to try and reimplement the browser's navigation logic with pushState etc. etc. in some dubious quest to outperform the browser's own navigation logic. I understand this sort of thing is actually done now.

Or you can just serve HTML.

And you miss the point of REST as well, I think. I'm increasingly convinced that nobody has the slightest clue what 'REST' actually means, but to the extent that I can determine what it means, it seems to essentially mean to design according to the original vision of at least HTTP. To use, e.g. content negotiation, HTTP methods, etc. as they were originally intended, rather than carving out some arbitrary path of what works arbitrarily choosing features of HTTP and bending them into some custom RPC system that you for some reason chose to implement over HTTP.

A consequence of this is that the same endpoint should be as happy to respond to Accept: text/html as Accept: application/json, surely. (And obviously, not just with some bootstrap page for your JavaScript web page-viewing web application.) It means your URLs represent resources and don't change. It means resources have canonical URLs. (If an API has a version prefix like "/v1/", it isn't RESTful no matter what its authors claim.)

I suppose you could proxy Accept: application/json requests without transformation to an API server, making the "browser gateway" server a conditional response transformation engine. In some ways that's kind of elegant, I think. But it also feels like overkill.

"Just serving HTML" assumes you have HTML to serve. If you're writing a CMS that consists of manipulating a bunch of /posts/[N] resources that are effectively un-rendered Markdown in the "body" field of JSON documents pushed into a document database/K-V store, though, then you've not got HTML. Coming from the perspective of writing the tools that allow you to manipulate the content, the simplest, cheapest extra thing you can do is to extend that tool into also being an API for getting the content. And nothing more. You don't want your flimsy document-management service to serve your content. You just want it to be spidered/scraped/polled through that API by whatever does serve your content. Exposing your flimsy hand-rolled CMS to the world, even with a caching reverse-proxy in front, would be a security nightmare.

And, even if you did want your CMS server serving up HTML to the world†, you don't want your CMS to serve up "pages", because deciding what combines to make a "page" is the job of your publishing and editorial staff, not the job of the people writing the content. This is an example of Conway's law: you want one component (the CMS) that your journalists interact with, that talks to another component (whatever themes and renders up the "website") that your line-of-business people work with, and you want them basically decoupled from one-another.

There's no reason, like you say, that the same server can't content-negotiate between the web version of a resource and the API version. I've implemented that sort of design myself, and a few years back, I thought it was the be-all and end-all of sensible web authoring.

These days, though... I've come to think that URLs are hateful beasties, and their embedding of an "origin" for their content (effectively making them {schema, namespace, URN-identifier} tuples) has broken the idea of having "natural" web resources before it ever got off the ground. The CA system and CORS have come together to make "origins" a very important concept that we can't just throw out, either.

What I'm talking about: let's say that the journalists are actually journalists of a subsidiary of the publishing company, recently acquired, kept mostly separate. So the journalists' CMS system is run by the IT department of the subsidiary, and the news website is run by the IT department of the parent company. This means that the CMS probably lives at api.subsidiary.com, and the website is www.parent.com.

Now, there's actually no "idiomatic" way to have the parent website "encapsulate" the subsidiary's API into itself. You can allow www.parent.com to load-balance all the requests, frontload content negotiation, and then proxy some of the API requests over to api.subsidiary.com... but api.subsidiary.com still exists, and now its resources are appearing non-uniquely through two publicly-available URLs. You can further try to hide api.subsidiary.com behind firewall rules so only www.parent.com can talk to it, but, now—disregarding that you've just broken the subsidiary's CMS tooling and that all needs to be recoded to talk to their own API through the parent's website—what if there's more than one parent? What if, instead of a parent company, it's a number of partners re-selling a white-labelled multi-tenant API service through their own websites? api.subsidiary.com still needs to exist, because it's still a public service with an indefinite number of public partners—even though it's denormalizing URL-space by creating a second, redundant namespace that contains the same unique resources.

And all this still applies even if there's no separation of corporations, but just a simple separation of departments. The whole reason "www." was a thing to begin with—rather than whatever's on the domain's apex just setting up a forwarding rule for access on port 80—is that the web server was usually run by a different department than whatever was on the apex domain, and each department wanted the ability to manage their resources separately, and potentially outsource them separately (which still happens these days; "blog." and "status." subdomains will quite often be passed off to a third-party.)

In short: REST is awesome, and content negotiation makes perfect sense... until there's multiple organizational/political entities who need to divide control over what would originally be "your" REST resources. You can try to hide all that complexity after-the-fact, but you're just hiding it; that complexity is fundamental to the current {origin, identifier}-based addressing model used for the web. We would need to switch to something entirely different (like, say, Freenet's SubSpace Keying approach) to enable REST resources to have canonical, unique identities, such that you could really encapsulate multiple REST "representations" served by multiple different third-parties into the same conceptural "resource", and have that "resource" only have one name.

---

† On a complete tangent, HTML is way cooler as a format—and far less of a hassle to generate (no templates!)—when you just use it as a pure flat-chunked unstructured markup language, like so:

    <html>hi <em>guys</em></html>

...instead of forcing it to be a container-format for metadata that should rightfully live in the HTTP layer. (Yes, the above is fully valid HTML. Validate it sometime!)

While it does make sense to request, say, the text/html representation of a BlogPost resource directly from the CMS server, what you should get in return is, literally, a direct HTML equivalent to whatever the JSON response you'd be getting is, instead of a "page"—that being an entirely different compound resource that you weren't talking about at all.

That's where people screw up REST—by thinking "send me text/html" means "send me a web page." Pages are a particular kind of "microformat" that the text/html representation is capable of! There are other kinds! Sometimes the unstructured HTML markup of a BlogPost-body might be all you want!

Now, that sounds all well and good as an argument for the sake of e.g. REST client libraries that want to get uncluttered HTML resources to chew on. But web browsers? It'd be crazy to feed unstructured markup directly to a web browser, right? Horribly ugly, for a start, and missing all sorts of important structural elements. It'd look like 1994.

Well, surprisingly, you can gussy it up a fair bit, without touching the Representation of the State itself. One thing people don't tend to realize is that the <link rel> tag is equivalent to sending a "Link" header in HTTP. This means, most importantly, that you can tell the browser what stylesheet it should use for a page as pure HTTP-response metadata, instead of embedding that information in the transferred representation.

With enough clever use of CSS :before/:after styles to insert whatever you like on the page, you can "build" a structure around some REST "State" that was "Represented" during the "Transfer" as completely unstructured markup. That's what you should be seeing as the result of letting a browser do content-negotiation directly with a RESTful API server.

(Now, you can't get any Javascript going that way, but shame on you for wanting to; the thing you're rendering isn't even a representation of a compound resource.)

Anyway, follow this kind of thinking far enough, and you realize that everything the "API CMS" server I just described does is something databases do (at least, the kind with constraints, views, triggers, stored procedures, etc.); and that the "website service" of the parent company is what's more traditionally thought of as a "webapp" server.

Now if you could only get your database to speak HTTP and serve HTML directly... oh, wait: http://guide.couchdb.org/draft/show.html :)

Maybe we need something like XSLT for JSON? /s

> But please, please, don't require Javascript to simply load an article and don't make a simple article 5MB. Why on Earth would you do that?

No Javascript => no tracking/ads => force users to enable JS and (sometimes) disable their adblocker. It's all about money, never about technology.

You can track without JavaScript, but you can't just include a 3rd party service, you actually have to do the work.

Same thing for ads, JavaScript isn't required (especially for text ads, although few networks will let you do server side ad requests)

No, you can still do a 3rd pay service without JavaScript. GA expressly supports it.

Not necessarily - a lot of the time it's just laziness and incompetence.

I've noticed quite a few simple article websites that have something like a class on the body that sets display: none - and then that class is removed only after all the JavaScript has loaded. It's very obnoxious.

There are also websites that show you a completely blank page if you have cookies disabled! That's amazingly terrible.

Probably to avoid the flash of unstyled content, but yeah, that could probably be handled better.

If you've found NoScript handy, try uMatrix.

It's not for the faint-of-heart, but if you know what CSS, cookies, JS, iframes, XHD, and Internet domains are, it'll make sense.

What you get is a matrix -- capabilities across the top, domains (and sites) down the side. Green is enabled, red disabled. You can save values.

Enable what's needed to get a site working, know just what it is you're nuking.

Much goodness to that feel.

uMatrix is a nice blocking tool, but it doesn't replace everything that NoScript does.

In my experience it replaces everything NoScript does (blocking scripts by site) and then some.

Or am I mistaken?

If so, could you clarify as to how?

Indeed. I have used Adblock and Noscript for years.

My browsing the web is not an invitation for websites to serve a webpage viewing webapp so that they can (poorly, buggily, in a more error-prone manner) reimplement a browser's navigation logic. (Ever had to reload a website which uses the pushState API because you clicked a link and for whatever reason the XMLHTTPRequest it made to fetch the page didn't work and it just hung and ignored all future link clicks? Dear chickenshit webdevs, if you think you can implement navigation better than an actual web browser, you're probably wrong.)

The vast majority of the time when I come to an article which is a blank page without JavaScript, I don't enable JavaScript; I just make a mental note that the web developers are beyond incompetence and move on.

I'm starting to respond to this trend with a more aggressive refusenik approach. For example, CSS is now so powerful that you can cause excessive CPU load with it alone. So I now have a shortcut configured to disable CSS for a site. This also makes many sites readable which otherwise wouldn't be, because they're doing something insane like blanking out content with CSS under the expectation that it'll be shown using JavaScript. And of course all of these recent 'ad-blocker-blockers' (http://youtu.be/Iw3G80bplTg) seem to rely on JavaScript.

Sometimes the content is loaded via JavaScript and so this won't work. Amazingly, for some years now there is a Blogger template which does this, which demonstrates that this brain-damaged approach has spread even to Google. But the greatest irony is that you can work around these sites, quite often, using the Google cached copy. Googlebot has supported JavaScript for some time (actually sort of unfortunate, in the sense that it removes an incentive for webdevs to design sites sanely), and it appears that cached copies are now some sort of DOM dump. Which has the hilarious consequence that you can now use Google to fix broken Google web design. There are *.blogspot.com sites which are blank pages, but the cached version is readable.

My own weblog is very spartan, being rather of the motherfuckingwebsite.com school of non-design. bettermotherfuckingwebsite.com was linked below, but I don't think I agree with it. Ultimately, in terms of the original vision of the hypertext web, I'm not sure web designers should be dictating the rendering of their websites at all; that is, I'm not sure web designers should exist.

So basically, imagine surfing the web with CSS disabled, but for your own user styles, that format absolutely all content the way you like it. Your own personal typographic practices are unilaterally adopted. bettermotherfuckingwebsite.com might be right as regards to typographic excellence, but it's wrong about where those decisions should be made.

Unfortunately it's undeniable that this is a lost battle. Browsers used to let you choose default background, foreground and link colours, as well as fonts, font sizes, etc. I think you can still choose default fonts. But the idea of the web browser as providing a user-controlled rendering of semantic, designless text is long abandoned. That ship died with XHTML2 - I think I'm about the only person who mourned its cancellation.

Well written, hlandau. People like you who really CARE about this stuff are why I come here.

Off topic: Thanks for the video link; the source of it, The Big Hit, looks to be something I might rent and watch today, given that the clip and another from the movie were rather funny.

A lot of times, that's just more effort than I want to deal with. I have Privacy Badger on a PC or two, and have reported things broken... probably a dozen times because I forgot I was on a computer with it enabled.

We shouldn't try to fix badly bloated websites. We should RIDICULE badly bloated websites, and take our business elsewhere.

I wrote a blog post about this:

http://softholmsyndrome.com/2015/08/28/your-blog-does-not-ne...

The problem with NoScript is that when you use a browser that doesn't have it installed, the internet seems so much noisier. :)

> Fuck websites with autoplay (or autoplay-on-hover) videos.

It's not just marketing. My personal favorite is how Twitter and (shudder) Facebook are doing this on their timelines now. At least they have the decency to mute the volume, but that doesn't help with data caps.

Both services offer to disable the auto-play, but unfortunately global and not only on a certain device or depending on network environment.

Hell, that 'd be a nice thing to have in HTML5 and OSes: allow the user to classify networks as "unrestricted" (fat DSL line, fibre,...) or "restricted" (mobile hotspots, tethering, metered hotspots), and expose this to websites so they can dynamically scale.

Android already supports this, but no other platform. A shame.

> Both services offer to disable the auto-play

Twitter specifically won't disable autoplay for everything:

The option text reads:

Videos will automatically play in timelines across the Twitter website. Regardless of your video autoplay setting, video, GIFs and Vines will always autoplay in Moments.

I removed Moments from the ui with Stylish the same day they launched it, and image/video previews entirely in the main timeline. The selectors you want to hide are ".expanding-stream-item:not(.open) .js-media-container", ".expanding-stream-item:not(.open) .js-adaptive-media-container", and ".moments"

The Facebook app for iOS lets you choose whether to auto play on wifi+mobile data, just wifi, or not at all. One app, but it's a start.

Could you explain some more? I'm looking for these settings on my iPhone 6S, but can't seem to locate them. Thanks.

Windows 8.1+ does at the OS level, I don't think it's exposed in the browser though.

http://windows.microsoft.com/en-my/windows-8/metered-interne...

PAYPAL frikkin has full-screen video autoplaying on page load... of course one can go directly to .com/login but it's mind-boggling that a financial services provider for the masses thinks that this is acceptable.

I bet they did a study of 100 random users, and got more engagement with the videos. Just because we hate them doesn't mean our mom's and grandpas hate them.

But, I thought noscript breaks the web? What it seems like is web-devs are breaking the web. Somehow, they have turned browsing the web into a worse situation than watching cable television.

Even in 1st world countries, people use 3G/4G with data caps to work...

_No_ mobile browser supports autoplay on videos in webpages. There used to be a hack on Android but it was closed in 5.1 (maybe earlier). Another reason to avoid native apps.

That sentence wasn't limited to mobile. People (I for example) use 3G/4G with laptops too. I don't have a data cap, but in other countries those are more common.

This is a pretty good extension, that will keep javascript going, while turning off autoplay (mostly).

Of course doesn't work with Flash videos, but you should disable those anyway.

https://chrome.google.com/webstore/detail/disable-html5-auto...

I find Flashcontrol good https://chrome.google.com/webstore/detail/flashcontrol/mfidm...

Kills almost all the annoying video stuff and one click when you do want to see something. Works on CNN etc.

(also if fixed horizontal junk on top of the page annoys you check out my own (5 LOC or so) thing to toggle them https://chrome.google.com/webstore/detail/zapfixed/jgiflpbko...)

Easy actually: because a well-defined restricted subset of HTML can be machine-audited and there is no way to abuse it. Also, Google can save resources at indexing.

But AMP isn't a subset of HTML, is it? They've replaced a bunch of HTML tags with their own amp-prefixed variants… IMHO it reeks of vendor lock-in, and could just as well have been made a proper HTML-subset.

Fuck CNN. Fuck them.

/rant

A surprising number of videos are served through a small number of video service provider sites (there's a different acronym for this, I can never remember it).

A half-dozen or dozen entries in your /etc/hosts file will block them quite effectively. I've posted this to HN in past.

https://news.ycombinator.com/item?id=10133969

(Including CNN. Fuck'em indeed.)

I've found Google's Pagespeed Insights[0] to be a great resource for keeping obese sites in check. Their site will give you stats on load time as well as instructions on how to optimize that time, which is very important especially on a user's first visit -- e.g., I will bounce from a new site in X seconds, but may give an established site (think Amazon) X + Y second time to load. It's easy to miss how important page load is when you've been working on a site a bunch, but every extra second of load time has been show to impact sites' bottom lines [1].

0 - https://developers.google.com/speed/pagespeed/insights/ 1 - http://www.fastcompany.com/1825005/how-one-second-could-cost...

I have been using slow internet more often lately, because I'm traveling full-time again, and only using 3G/4G broadband. It is remarkable how large some sites have gotten since I was last in this situation. Despite mobile broadband being somewhat faster now than a few years ago, the time to load (to usability) for many sites is much higher. HN is notable for loading instantly in these circumstances, not because the server (I'm guessing it still runs on one server, plus CloudFlare, but I might be guessing wrong) is blazing fast, but because it is so small.

I'm traveling as well. I've completely given up on some tech blogs. Because going to them is costing me too much money, i.e. The Verge.

I travelled through Spain where the largest data plan is 2GB for €20. Top ups were 100MB/€ and you could only top up 200MB at a time.

I'm currently in the Caribbean. Data roaming because some providers don't even offer data unless you are on a postpaid contract.

This is why I use opera mini on mobile. It really speeds up browsing.

I haven't tried Opera in many years. Will have to give it another look. But, I'm mostly not browsing on a mobile device...I'm using my laptop through a mobile broadband hotspot.

I think the primary reason for the rise of increasingly heavy sites is that animations and visuals can be used to attract and "hook" your reader.

Just as fish like shiny spoons and minnow lookalikes and monkeys like shiny objects, humans like pretty pictures and flashing visualizations.

Distraction is the same principle that drives the success of TV. It is so damn easy to just sit in front of the screen and grok out, never mind the fact that the signal to noise ratio is often astonishingly low.

Quality thought and challenging content consumption is much harder than simply letting yourself admire shiny visuals. Therefore, simple websites, while they may contain excellent and meaningful content, will often not stimulate the user's interest as much as animated websites with large pictures.

css animations can be done in only a couple of lines; so I wouldn't consider them to be the primary drive, or any significant factor, behind bloat.

But CSS animations are...rough currently, not standardized, and don't have about a decade worth's of knowledge behind them. I can sure make a element fade in on a webpage with CSS, but there's already a billion ways to do it in JQuery on StackOverflow, so it's a lot more appealing to use Javascript at first.

I did not mention "css animations" in my post. Animations in general are certainly a common cause of website bloat, as they are often effected with a mix of images, javascript, and css which combine to waste bandwidth and cpu cycles. The article lists numerous sites for which animations contribute strongly to large website size. One such site listed in the article is this one: http://pollenlondon.com/ .

My only concern about this is that a lot of the technologies identified as "adtech" on that diagram just... aren't:

* Vimeo

* Hootsuite

* LinkedIn

* UserTesting.com

Marketing != advertising. The overall point is really valid, but this is a dumb way to back it up.

It's bad enough to just take the ad-serving parts of the diagram he uses, which add up to hundreds of technologies (or use Ghostery on any news site).

I'm not with you on linkedin, that's not marketing, that's malware.

The whole adtech part is bad, the rest of the article had valid points but this author doesn't understand how advertising works and is theorizing about this bubble and the tech.

It's way easier to acquire stuff than it is to get rid of it, whether it's website bloat or personal possessions. It takes discipline to adhere to procedures that trim unneeded code / dependencies as they loses relevance. If you don't do it while the reason the code was put in in the first place was fresh in mind, there will be a natural tendency to kick the can down the road.

Not to mention, when they load up on all the new stuff, they try it out on fairly modern machines and it loads well enough, with a load time that's just good enough, so there's even less motivation to trim down.

I also would love to have leaner websites and less bloat, but I recognize that good enough still passes for good enough. It's only when they go past a tipping point do people pay attention, such as when iMore got called out by John Gruber.

Is it hypocritical that this website is over 1 MB and has over 100 requests? http://www.webpagetest.org/result/160101_KN_FH3/

No, it's not hypocritical: these 1 MB and 100 request are the content of this article, i.e. useful payload, as opposed to useless irrelevant junk which is on most websites these days.

Arguably, many of the "slide" images aren't directly relevant to the content, they're just there because you're expected to have images in a tech conference talk.

In fairness, that page is as clean as it gets, given that it uses tables for layout and it loaded really quickly on my resource constrained laptop. I thought it was an excellent translation of content from a slideshow presentation to the medium of the web. (From the mistakes in the source markup, I presume the HTML was manually edited).

I particularly enjoyed this self-reference:

> Examples!

> Here’s a self-righteous blogger who likes to criticize others for having bloated websites. And yet there's a gratuitous 3 megabyte image at the top of his most recent post.

> http://idlewords.com/2014/08/green_arabia.htm

    bash-4.3$ links -dump http://idlewords.com/talks/website_obesity.htm | wc
       1429    7698   78566

Seems like a better bloat-to-word ratio than many of the example sites the OA mentions (including one of his own blog pages by the way).

The little thumbnails of the slides from the original presentation do make up 990Kb of the roughly 1Mb but they are quite readable and do add value in my opinion.

+1 thanks for the reference to websitetest.org! I was looking for something that. I tested my major sites and they all tested good (0.1 to 0.3 megabytes) except for one that was 3.5 MB because of a banner image that does not add much to the site. I will fix that!

Yeah, websitetest.org looks like a terrible website on first glance, given the ads and all, but it's actually an amazing website.

I was having a good time, reading the article with a grin on my face. Until I got to

> On top of it all, a whole mess of surveillance scripts

And I just lost my cool and laughed out loud. Well written, sir.

Yeah, me too ;)

But he also says this:

> I bet if you went to a client and presented a 200 kilobyte site template, you’d be fired. Even if it looked great and somehow included all the tracking and ads and social media crap they insisted on putting in. It’s just so far out of the realm of the imaginable at this point.

If that's possible, I'm getting that bloat stems from sloppy implementation of all sorts. Fonts. Ads. Tracking. All of it. I suspect that the copy-and-paste approach accounts for a lot of it. And using third-party resources, such as Disqus for comments.

> And using third-party resources, such as Disqus for comments.

I actually kinda like disqus. Centralized notifications for replies and no more signing up in order to post a comment (for the users), and as a site op I don't have to deal with spam, people trying to XSS my comments and especially: I can statically cache ALL the content and even run without any database at all!

OK, so I shouldn't have included Disqus under sloppy ;) You do get secure managed comments. But isn't there a bloat cost, too? There are also security and privacy risks in using third parties.

Yep. Disqus is one of the more understandable shifts-to-bloat which developers have made in recent years. Understandable because spammers have made it so difficult to run our own comments. The selfish anti-social behaviour of this small minority of "SEO experts" ends up forcing everyone into tech choices we should otherwise be avoiding.

Disqus often shows a spinning wheel forever on mobile devices with no way to reload except reloading the whole page and waiting and scrolling down and crossing the finger that Disqus may display the comments this time, only to find out: nope. It seems Disqus peaked, and their product quality tanked. I cringle when I see embedded Facebook comments too, though they get less and less - nevertheless FB comments always worked on all devices.

Nowadays many websites don't offer comment sections at all. Probably because it was too much effort on their side to clean up the spam, etc - sad development. Often a captcha would preventvmost spam and idiots from posting shit.

I lost it at:

> Out of an abundance of love for the mobile web, Google has volunteered to run the infrastructure, especially the user tracking parts of it.

Most of the weight comes from images. The average website (Alexa top 1M) contains over 1.4 MB of image data:

http://httparchive.org/interesting.php

Be sure to pick the most suitable format and to optimize your images. You can also try to serve WebP to browsers which support it. When it replaces JPEG, you save about 30%. With PNG8, it's somewhere between 5 and 50%. And with PNG32, if you substitute it with a lossy WebP, easily 80%.

Scripts come 2nd with ~363 KB. ES6's will thankfully help with that. Creating the structure of your application declaratively enables better tooling. Not only does this make your editor a lot smarter, it also paves the way for tree-shaking.

If you tree-shake your application, only the actually used library features will be included in the shipped bundle.

Disclaimer: my own blog. If this is considered spamming here, feel free to remove

https://blog.thekyel.com/?anchor=Why_I_Block_Scripts_and_Ads

It won't be long before my site which literally downloads an entire Windows 95 disk image on every page load will be considered average-sized. It's a mere order of magnitude away.

Interesting analogy. I grew up using Commodore computers, but I'm not trying to race to the bottom of computing minima. I remember when (we) engineers got REAL WORK DONE on x86 PC's with 10 MB HDD's, running AutoCAD, Lotus 123, and Word Perfect. This was inarguably the beginning of the era of the useful, general-purpose computer. You could load a computer DOS 6.22, Windows 3.11, several of these programs, and still have room leftover for Doom. The author references Apple's iPad page at 51 MB. The last time I rebuilt my gaming PC, the MOUSE DRIVER was 150 MB! It makes me weep for where we are. I don't see that things have really changed all that much in 25 years, as far as getting "real work" done. It's just... more for the sake of "more." (The games are cool, though.) In my opinion, all the bells and whistles really haven't added anything to the web browsing experience for about 15 years.

It's not just an analogy, it's a real-world example!

http://win95.ajf.me/

The disk image is 47MB (when gzipped). This means that the page is actually smaller than Apple's iPad page!

I likewise weep for modern computing.

So I keep telling clients: if we use WP for your low traffic site is like renting an 18-wheeler to move a small box. Yet, I feel like doctors must feel when patients argue 'quoting' something they read on the Internet: suddenly they are the experts now :(

It depends on your point of view. The server load caused by WP is much larger than most alternatives, yes. But the development(and ops) time required to ship a WP site is much lower than any alternative I know of.

Yet WP does come by default with a lot of the cruft problems mentioned here. Lots of inefficient js and css added over the years.

Don't miss the video of this talk liked at the top:

https://vimeo.com/147806338

Aren't there page optimizers, that can factor html and css and make it smaller ?

Another simple way to solve this would be to just "compile" a webpage, like pre-parsing the dom tree, and write this tree file into a binary file. That would remove the parsing stage, which take a lot of CPU cycles, and is the reason why most web services have their own smartphone app instead of a simple combination of html+js.

Of course, if mozilla does it and creates such format, no developer will use it and it will die, so again it's up to something bureaucratic like the IETF.

It boils down from the fact that markup language were not really meant for web applications.

We are in 2016, and there still isn't a well designed, versatile document format for the web. I have completely zero clue how a browser displays a webpage, while there seems to be a lot of opportunity to optimize things there by moving away from a text-centered solution. I don't understand why there is nothing on this, all that is required is saving the intermediate data a browser has just after parsing a html file. Computers are not designed to eat raw text every time.

I think you've missed the point of the presentation. Optimization tricks such as these are fun for us nerds to work on but at the end of the day it's like adding another lane to a highway or deflating a tire on your jeep (to use 2 metaphors from the talk). Compilation of the dom won't reduce the size of images or JavaScript files. And lastly, the author makes a point towards the end that in addition to page size, there is also the notion that plain old HTML and CSS is something new people to the platform can easily learn from and work on themselves (mineceaft vs. call of duty was the author's analogy about this).

> Compilation of the dom won't reduce the size of images or JavaScript files.

The problem is not so much about images or js, it's more about webapps generating fat html and so much css.

As for javascript, to me it's not a good language choice for many reasons. It's being used extensively like a core language to build web applications, while it's just a scripting language. HTML was never meant to be used like this.

To be honest I don't really understand the analogy.

I think most of the problem is from images. Images, and especially videos, take up way more space than text. The Russian novel comparison is somewhat misleading in that regard.

But it shouldn't really be an issue because of progressive image loading. At the very least, the text should always load first. Back when I had dialup, it could take ages for a page to load completely because of the images. You could watch them slowly fill in, line by line. And if you didn't care about them, you could ignore them.

There's also now FLIF, which progressively loads images at higher and higher resolutions as more of the file downloads: http://flif.info/ The images look very good even at like 10%. Ideally once the image gets to the desired resolution, it wouldn't download any more of it. So it covers resizing issues too.

> But it shouldn't really be an issue because of progressive image loading. At the very least, the text should always load first. Back when I had dialup, it could take ages for a page to load completely because of the images. You could watch them slowly fill in, line by line. And if you didn't care about them, you could ignore them.

I remember the dial-up days too. You could only read the text around the images while waiting for the images to load.

Now we sort of have the opposite problem when pages use huge unnecessary web fonts; you can only look at the images while waiting for the font to load so the browser can render the text.

(I found sending fonts.googleapis.com to 127.0.0.1 in my hosts file helped a lot in that regard. Wish my browser had an option to block all fonts, though.)

FLIF looks like cool tech, but I won't hold my breath until it has wide browser support.

I will agree with you that web fonts are the stupidest thing ever. There seems to be some extensions to block them, though I haven't tried it yet. I don't know why the text isn't rendered normally until the font downloads, or why common fonts aren't cached locally.

Becuase web developers deliberately work around that (color text white or hide it) so the text doesn't display until font is loaded to avoid the text pop. Of course that makes the site unusable if font CDN is down.

The Russian novel comparison is indeed completely unfair. If Crime and Punishment was served by today's web publisher, the contextual ads for money lenders, lawyers, adult services and what-not would of course inflate the size of the page to hundreds of megabytes, significantly exceeding the size of the tiny pages shamed by the unfair comparison!

To his credit, he did make the point of most images and videos being superfluous in most pages, and of them wasting battery and bandwidth, even if they do so after the text was rendered.

I have no idea what your point is. If Crime and Punishment was illustrated, then it would take way more space. A single picture might take up more space than the entire book. It's just the reality digital images. And if you don't want images, well then you don't have to wait until they download.

He does make the point that most images are unnecessary. But then he puts dozens of unnecessary images into his web page! Even he doesn't follow that advice.

It's a talk transcript. AFAIK images are his slides, and anyway, I'd say they form an integral part of the content.

JPEG and PNG both have progressive modes, but they seems rarely to be used. It would be interesting to analyse that though.

And then you have http://okmij.org/ftp/ , S/N ratio : NaN

There's an ad on some pages:

"Converted from HSXML by HSXML->HTML"

Bloat!

Ads, uh, find a way.

I'm most fascinated by the slides on the bookmarking sites. I'd really, really like to know exactly how a bookmarking site with 3k daily users manages to rack up a $23,000 monthly AWS bill, that they only managed to reduce to $9,000. Did they try as hard as possible to split everything out among as many AWS services as possible? Yikes.

I just threw up a little blog and a few tinkering sites on AWS. Looked around at a few blogging systems. Guess I coulda used Wordpress or Ghost or some other DB backed thingy and used one, or two or three, of their database services for the backend, which would probably be much more expensive and hard to maintain. Decided to go with Jekyll instead. Don't need anything but a nginix now.

Developers in web companies get the latest Mac Book Pros, and it works okay on their machine.

They develop and make things without thinking about normal people.

I'm wondering what the collision between fat web pages and bandwidth caps will look like. Lots of sites have untold amount of garbage on them and I'm starting to notice that many of them have automatic page reloads running. So unless you remember to close the window, it can be back there sucking up bandwidth.

I also wonder what effect encryption on the pages will have. Lots of info should be cached, but most of us are behind proxy devices, how do they do with the encrypted ones?

His website is a good example, it's clean, total page is 1 Mbyte of text with 102 calls from the page (for the thumbnails). It's sad to see a single graphic as a banner taking up that much space.

> total page is 1 Mbyte of text with 102 calls

I don't think that this is commendable in any capacity. He should have put his money where his mouth is and package those thumbnails in maybe 5 - 10 sprite files and then serve them with CSS.

This way he would have cut considerably on the network latency and fetched those resources faster without relying that the visitor/user would stay near above the fold region as the page is loading and not experience those empty cells waiting for the corresponding image to fill it up.

His proposals like in everything with life, it's always easier said than done.

I feel like this is a really good diagnosis of the causes of page bloat and the harms, but the remedy is more nostalgia than anything. The web of the 90s, with amateur blogs and Geocities sites and what have you, the peer to peer content model, it's gone and it's not coming back. The thing about the Eternal September is it's eternal. The Web has transformed into a place where 99% consume and 1% produce. And that's game over. There may well be an adtech bubble bursting, but that's not going to bring the 90s back.

I agree with most of this article, but there are some basic problems.

1) Page size alone is not the same as user experience. This is easily explained by youtube or netflix. Videos are tens or hundreds of MBs but start instantly and you get the experience you need. Well made websites follow the same important content, navigation first approach and stream in the rest as necessary.

2) The comparison of page size and how you can fit entire Russian novels in the same size is just weird. The text of the site doesn't add up to megabytes, if it did then it would be an equivalent amount of text as those novels. The fact is that the modern web has lots of visual design and media. Even if you use CSS, people still want images, not just text. That's not a bad thing, it's just an evolution. Even this article has 1MB of images (even as just thumbnails and many not necessary). Whining about images is not helpful.

3) The thing about ad network model is just random and seems like the author has no experience in advertising itself. Either way, talk of bubbles and tracking without actually looking at all the angles and nuances is also not helpful and just derails the topic.

EDIT: author definitely loses some respect for this, I'd expect a legitimate reply: https://twitter.com/baconmeteor/status/683040882757505024

Page size is part of user experience, however. If you've ever visited another part of the world where Internet is awful or tried to use 3/4G on a mobile with bad signal, you immediately start to hate web sites that take forever to load what amounts to a page of text, which, if it were merely a HTML file containing the text, would still load immediately even on dial-up quality connection or less. Most people don't know this. Programmers do, and people who remember 90's Internet. Taking this into account, comparing against books is not too weird.

The point was that text is obviously much leaner and highly compressible - if you just discount the images like that then the web is already very fast. You have to take into account the entire experience and realize that images are a big part of the modern web.

I definitely agree there's a major cruft problem but I believe most browsers already have the ability to disable loading images which gives the client the power to adjust for their network connection.

Another huge annoyance with mobile devices is webpages that load some of it then crash the browser with all the JavaScript that it loads. So on an iPad 2 using Safari, load page, crash, reload, crash, reload ...

Things That Turbo Pascal is Smaller Than: http://prog21.dadgum.com/116.html

One factor might be that web pages are big enough that they begin to allow contributions from different, orthogonal origins.

The initial designer might do the first main layout and bolt in some menus and the main text area.

But other people then gradually want to add these extra panes, those hot videos, that extra image viewing layer, this advertisement, all kinds of scripting, new functionality that all comes together orthogonally but will together take megabytes of space. These can be added without going back to reworking the original design too much so people can go in, think "I don't know how the whole page is actually built but I can just add this little thing here and not mess with anything else", and copypaste one more of the latest features onto the page.

Or this mechanism could even be automated: new people just add extra page modules to a database and the original workhorse will go rebuilding the HTML with the new additions in it and nobody is left to oversee what all they're actually serving out on each page load.

Typo:

"The graphics card on my late-model Apple laptop could not literally not cope with the load."

Moving aside from said pedantic nitpick, a hilarious and brilliant essay. I'm definitely going to be stealing The Taft Test, perhaps somebody should make a web app that lets you perform this operation automatically?

Browsers are really, really good at rendering vanilla HTML.

Amen, brother. HTML, for all its layout flaws, is a gift to us developers. The fact we are moving away from leveraging the raw parsing and updating functionality written in C/C++ is a travesty.

Yeah, but just a few years ago when building a site you never needed an image wider than 1600px, and now you have lots of people with retina and 4K screens. Add just one full-width HQ image and it's 500+KB on top of everything else....

Except for IE, modern browsers support srcset, which allows you to define different image sizes for different screen sizes, and only the "right" size image will be downloaded.

If you need to support IE, you can use media queries with CSS background images. Typically, it's only background images that are bandwidth hogs anyway -- logos and such tend to be much smaller.

Media queries are supported by all modern browsers, including IE9+, and with a JS polyfill (respond.js), you can even support IE 6-8. So there's really no excuse for anyone who's supporting retina not to use media queries to minimize bandwidth for everyone else. It's only a few extra lines of CSS, and you can target any imaginable screen size (e.g., see this gist: https://gist.github.com/antonioreyna/5809553)

Based on Caniuse[0] data, it looks like that «srcset» is not supported on pre Lollipop stock browser on Android devices. So, it is still not a feasible solution.

[0]: http://caniuse.com/#feat=srcset

Progressive JPEGs have been touted as a solution to this, but still they are rarely used. The idea is the browser will download only as much data as it needs, and display the image as the data is received (so it renders a low quality version faster).

There is a small overhead in the full file, but if it means a mobile user is saving 200kb+ it's worth it. All modern browsers support it (even Safari on iOS which didn't a few years ago) [0], so I don't really know it isn't used more widespread.

[0] Demo page: http://pooyak.com/p/progjpeg/

Do browsers actually stop downloading a progressing JPG based once the required resolution is reached? The demo doesn't seem to work that way.

Well my mobile phone with fullHD really doesn't have to show a friggin 4K 1MB image when I'm looking for an address in a foreign country with a 200MB roaming data cap! -_-

A fantastic article.

When there is no penalty for over-consumption and it is far easier to do the stupid, inefficient thing, then the stupid, inefficient thing will be done.

To really combat this problem, we need:

- Good tools that ensure the easy thing is also the optimal thing.

- Penalties for pipe abuse (e.g. web browsers that make it really easy for users to see the Wall of Shame with the web sites most responsible for gobbling up their data plans and batteries). Sadly the only thing I have right now is the OS X app-shaming model that points out high-energy apps, and then Chrome or Firefox or Safari get all the blame for what is clearly the web sites themselves.

Nice timing... two days ago I've decided to lose the web fonts on my web pages (not implemented, yet).

I still think Equity Text is gorgeous, but the fonts are actually much bigger than any of my pages. Even the long ones with a few graphics.

For even more justification of your decision, check out this fantastic presentation by Jake Archibald: https://vimeo.com/145138876

Covers a lot of ground, but at one point he's exploring how to reduce page load times and web fonts turned out to take 4 seconds [out of 8 total] on a 3G connection. This was due primarily to the font hosting service (not necessarily the file size), so may or may not be pertinent to your situation... but really a wonderful talk if you're interested in these kinds of things.

Thanks!

My situation is indeed a bit different, since I'm hosting the fonts on my own webspace.

A big plus of Matthew Butterick's fonts: sane licensing. No need to estimate and document page views. No need to obfuscate fonts, in some vain exercise of thwarting font piracy. Just pay, host and serve.

"The way to keep giant companies from sterilizing the Internet is to make their sites irrelevant. If all the cool stuff happens elsewhere, people will follow. We did this with AOL and Prodigy, and we can do it again."

I love this grassroots empowerment, but the internet is mainstream now, and like pop music/tv/news and consumer product manufacturers like nestle, proctor n gamble, colgate-palmolive etc, big corps are fantastic at targetting it. Most people don't want cool stuff.

BTW turning off js and images solves a lot of this problem - unless you need to use the site.

All of this is true, from a technical standpoint, but does any of it really matter in the modern world?

This sounds a bit like a structural engineer designing an elegant, perfectly constructed shopping mall, and then complaining about the massive corporate/commercial, orgiastic takeover that occurred after the mall opened.

With the exception of bandwidth concerns on data-capped mobile plans and diehard *nix fans that do all their web browsing with Lynx, why does bloat matter? Every one of those linked sites loaded on my home 10Mbps connection in <1 second to my eyes.

Why should I, as a user, have to download all of this crap just to read a text article? I shouldn't. Maybe it takes 1 second to load an article for you, but if it also took 1 second to download a text file decades ago, then what am I as a user gaining?

Aside from that, data-capped mobile plans are extremely common, and in the developing world, they certainly aren't fast. But not only do network connections have limits, but so do the CPU and memory of mobile devices, especially cheap ones.

Your 10 Mbps connection is far from being a given.

Here's a different perspective: I live in a small city close to a major metropolis in Germany. It's small, but far from being at the end of the world.

My only internet options are

a) 1 Mbps DSL (yes, those are Megabits) uncapped or

b) about 25 Mbps (100 in theory) LTE with with a 30 GB cap.

After that cap I'm throttled down to 64 kbps (not joking, this is dial up basically). I can buy additional 30 GB of data at 15€. That's on top of the 45€ base price for the first 30GB.

Yes, it really matters.

< 1 second is good but 0.1 seconds is what we should really be aiming for: https://www.nngroup.com/articles/response-times-3-important-...

> With the exception of bandwidth concerns on data-capped mobile plans

That's most of the world.

I wish there was a tool that could follow a browser session and tell me what, specifically, I hadn't used in my bootstrap CSS.

Or a tool that could similarly tell me which parts of JQuery I could just delete.

I feel the sites I have produced are fairly trim and optimised, with the exception of the CSS and JS. Sites like https://www.lfgss.com/

Yes they're responsive, and they load fairly fast, and they're encumbered with web fonts... but it's the CSS and JS that is the real bloat.

For the JS, Google's Closure Compiler ( https://developers.google.com/closure/compiler/ ) may prove useful. It can be set to strip out all unused JS.

I'd be very interested to see the difference in average page size between online publishing/new media and other types of sites. I think so much of this crisis is driven by the economics of that business model. Theres so much incentive to track & analyse users with various scripts, a desire to have a pretty looking site with lots of images (the biggest factor in page bloat) and comparatively little in-house technical resources or spare cash to devote to something as relatively exotic as web performance.

For all the effort that browsers go to in order to make sites "scary" when there are bad certificates, etc. I would love to see a big, red, scary page that says "you are loading a web site that is consuming an unreasonable number of resources, are you sure you want to continue?". Make that the default, make the warning limit 400 K, and watch web sites (complain first, and then) change.

Purely in terms of Web page size ( and not loading speed ), images is the biggest problem. We have been stuck with Jpeg for far too long. I really wanted Bpg to take off. It should at least save 30 - 50% off images size, which is now the biggest weight in web pages.

Then there is Web Fonts, along with JS Library. Most of them should be cached already.

So really, we need to cut the images size down. That's it!

The problem is, if you focus solely on cutting down image size, it's an invitation for the designer to add even more images.

I certainly remember bragging about my well established single sprite for most resources. Soon enough it became 20 unmaintainable sprites with duplicate content.

Though more than this, is the app gluttonous crisis. Websites, sure, drown me in your fatty acids. The alternative is a "lean" app.

Yes it runs slimmer and faster. But why does every app I install need to know every facet of my existence, and every facet of what every other app knows about every facet of my existence, and so on? This is a much bigger problem.

I've had the same problem trying to find a WordPress theme for my weblog^. Well, I ended up hacking it myself. The reason? Despite hundreds of premium WordPress themes, they were all bloated. Even the ones claiming "Minimalist theme".

I wonder if there is a real market for such theme.

^ https://omarabid.com

I'd like to ask: why even go with Wordpress in the first place? Aren't you suffering from the heavy cloud problem that he speaks about?

On similar lines is http://deathtobullshit.com

Nice.

A worthwhile eco-hacking campaign might be to "de-bullshit" the worst offending websites. Hack in, remove bloated bullshit, leave main content untouched.

It seems spreading the word about bloat isn't working. Might need to turn the heat up.

Bloat is a health risk in that Bullshit is a health risk. Out senses assaulted, our minds numbed and taxed with the task of defending that assault.

Anonymous should be on the case. They like the media-attention projects, but how about de-bullshitting the web for us Anonymous before it's too late?

I think you should be able to choose and also the opportunity to declut your web Filter and declut your web! http://andreapaiola.name/magpie

Why isn't there a medium alternative to all this bloat? Do blogs or articles really need anything more than a pastebin-esque website for rendering markdown?

Sure it might not make much money without ads, but it would be cheap to host.

I think this hits a lot of points, but I kind of like having images on websites. It's kinda hard to do something under a meg and have many captivating images.

There's obviously a lot of stuff to fix for other stuff though.

Another thing I recall hearing during my days working in SEO. Is that more is better. The more words the more pictures the more content actually factors into the algorithms that put you at the top of the list.

SEO: the witch doctors of the web

But seriously: those guys at Google know how to show relevant results. Make your results relevant and don't do anything stupid like block googlebot, and it'll work.

Well, that's the whole point of SEO - you do it when you don't have anything relevant or valuable to offer, but still want the money. SEO as an industry is mostly about fucking up Google's ability to show relevant results.

I often get flak for my old-fashioned, boring web pages, even during my brief appearance on Romanian TV. They consist of text with very little HTML annotation. But they're small and load fast :-)

For the curious, this page that complains about large pages is 989K.

Yeah but justified so, it's 31 screen pages (for me) of content. No ads, no clutter, no junk. Only thing I have to complain is that the images don't have target=_blank set on their links. That sucks.

edit: The optimal solution would be to really compress (or sprite!) the small images and on a click, display a modal with the image in full size, limited to 100% height or width plus a bit of padding. You don't even need jQuery for this and only load the images you really want as fullsize.

104 of 138 resources are images, over 97% of the weight. Spot checking, they're almost all thumbnails for the slides.

Not bloated in the least. Pure content.

Better to not have target=_blank - then you can choose yourself if you want a new tab or not (left click vs middle click)

I tend to open new links with command-click, so I don't set target=_blank for that reason. Are you on an interface where you can't do something like that? It's an easy enough change to make.

I love your pages/presentations but I wish there was a way to save them with all the big images without having to use wget.

I have a habit of saving everything I read online. Incidentally, this is also made worse by bloat and especially sites that load some content via JS.

> Yeah but justified so

I wasn't making a judgment on the size, just posting it for the curious.

It is curious—however, I have a feeling that the offenders listed in the article aren't bumping up against the limitations of JPEG compression in their bloat. :-)

See how it's carefully just under a megabyte?

Here you go then: http://motherfuckingwebsite.com/ :)

also http://bettermotherfuckingwebsite.com/

I do agree that the original Times new roman font sucks but I don't understand why floating content in the middle with huge margins on both sides with huge fonts makes it a good design. Maybe its my personal preference to actually utilize my big ass macbook screen instead of having to page through 1 page of content

I disagree with most of his changes, but limiting line width is such a big improvement it wins out over the previous one. First page ever to inspire me to use custom CSS for HN.

And some guy: http://codepen.io/dredmorbius/pen/KpMqqB

It's the signal to noise ratio which matters. I would say the page is 100% signal and 0% noise.

1017kb on my end.

IMO a large majority of those images would be better off replaced by the Taft image (or not included at all).

Working my way up to giving a 50 minute all-Taft slide talk.

It was a great article. Loved the web pyramid. So, where's your link describing why Taft is the best and deserves this honor?

What metric are you using?

23 KB

http://seositecheckup.com/seo-audit/html-page-size-test/idle...

67 KB

http://smallseotools.com/website-page-size-checker/

Checking some of my own pages:

http://www.aetherltd.com 5726 bytes.

But if try the tool at "http://analyze.websiteoptimization.com/wso", I get 1276134 bytes, including all referenced files. The big items are fonts. The fonts are offered in three formats (.ttf, .woff, and .eot.), and the tool counts all of them, even though most browsers will only load one format.

That's what firebug told me. Using the built in inspector I get 1,356K.

Your tools are probably not loading images if they show such a small number.

Including images. Chrome reports loading 1017 kB for me.

HTML is 23KB gzipped (served that way).

Uncompressed, it's 67KB. This does not account for the remainder of the resources.

The right punishment is to force people who make bloated pages have Frontier as their internet provider.

Good developers are rare and cost a lot of money... Good managers are rare and cost a lot of money...

So we are here.

I know a lot of good developers that have shipped bloat. No one thinks about performance until something is too slow, with too slow being a moving target.

Can go down the same line of backend ruby vs C.

But good managers allow the good developers to do their magic... without good managers the endless battle between cost and quality go really really bed.

> The article somehow contrives to be 18 megabytes long, including (in the page view I measured) a 3 megabyte video for K-Y jelly, an "intimate lubricant".

I wonder if he realized this might have been a case of interest based ads following him around and whether he would have still mentioned it.

Whoa he admitted he has Sex?

Had to get one last one of these in for the year. The last dozen just weren't enough.

Nothing like tilting at windmills.

This. Made me wish I could upvote it twice! Or more...

The forum software "Discourse" is a good example of hugely over-engineered bloat and Javascript being required to display some text.

They even require that you have the latest smartphone hardware! To display a forum post!

As with the examples of Facebook and Google, these are intelligent people working at these companies. Yet they get it completely and catastrophically wrong...

Agreed. Jeff Atwood's not a bad guy, but the way he acts like he's going to lead web forums to the promised land with Discourse is really grating, particularly when all he's really doing is making them more obnoxious to use.

I guess I could make a Slack/IRC comparison, but maybe I don't need to go there.

Slack is at least in many ways an actual improvement over IRC, from what I've seen of Discourse it's pure loss.

If you can't build a site without bootstrap, jquery, 500 png's/jpegs.. please stop coding.

UBlock Origin will largely solve this - except for inline SVGs. But I understand that they have to do that due to technical limitations with current browsers.

I've grown accustomed to reading unstyled HTML, and I gotta say - I like it.

Sites which host their own CSS and JS look as the designer indended. For example the Washington Post. I just checked the size. The home page is about 200K but when you add everything else it comes to 3MB.

Why should I care about this "bloat"? I don't. Computers are faster (by several orders of magnitude). The internet is faster (by at least two orders of magnitude). I have Fios - if you can get it you should too.

As long as there has been an internet, people have been complaining about bloat. I remember articles like these in the 90s. They do absolutely nothing to improve the situation or stop the growth.

We need to accept that web pages will be even larger in the future, and start pushing the technology required to deliver those pages in a reasonable amount of time.

That means HTTP2, QUIC, zero-RTT TLS handshakes (in quic and tls 1.3), and other new technologies. CDNs certainly play a role here too with dynamic acceleration, better caching, and networking. (disclaimer: I'm working that last bit at NuevoCloud CDN)

That and improvements in connectivity are the only real ways to solve this issue.

Are you familiar with induced demand?[0] That would only encourage the problem to get worse.

[0] https://en.m.wikipedia.org/wiki/Induced_demand

absolutely.. but web pages are going to grow anyway. take a look at this chart covering 1995-2014: http://www.websiteoptimization.com/speed/tweak/average-web-p...

In just the past 3 years, the average size has more than doubled.

Which may well be a consequence of lazy developers taking advantage of faster internet. I'd bet if internet speed were to stop increasing today it would be more likely to solve the bloat problem, since developers would eventually realize they were ruining their UX with load times. It's the same with processor improvements in that they allow developers to write more inefficient code since their time is prioritized over CPU time.

Improving the network technologies is important but the people who build on top of them need to make an effort, too. Otherwise the Internet's pipes will be forever filled to bursting with sloppy code.

The problem is that web pages aren't growing larger for no reason. Web pages are larger because audiences are responding to richer graphics; because of business requirements (ie: ads); and because of js frameworks and other libs that decrease the labor required to create web pages.

Those are hard things to change. How can a business giving up its income; or making it's website worse for visitors (by removing graphics)... possibly be a solution?

Certainly there are legitimate reasons for sites to get larger. But too often it's because of poorly compressed media and poor library/framework choices.

For businesses, it does come down to time and resources. If the users don't complain about the browsing experience then it's good enough.

Reply on news.ycombinator.com