The Website Obesity Crisis (2015)
idlewords.com
idlewords.com
A fast-moving industry needs equally-fast solutions. If 6 months can pass and people are still talking about a problem as if it was yesterday, then not enough has happened. Some ideas of more that could be done: talk to your web-developer friends; have them talk to their managers; start publicly shaming bloated web sites; submit issues and/or pull requests to web browser projects with ideas for how to fix HTML; or something.
Website have always been to big. We've been using huge Javascript libraries for the last ten years to add minor functionality.
Even using Flash for websites was a common standard!
The problem is that speed and usability are almost always considered less important than flashy animations and other bullshit that no end user actually wants.
I think this post will be relevant for years to come. I don't think web developers will ever learn.
90% of website size is media (images, audio, video, etc). Discounting that and saying that a 1MB page is so much bigger than just the text it delivers is silly and doesn't really make a point. Maybe it's unnecessary, maybe not, but that's subjective and most people would rather have images and decent UI.
It's true that ads are another factor, and it's slowly being solved, but ultimately comes down to the wrong incentives across the industry. The more annoying/heavy ads work better and pay more so everyone from advertisers to agencies to publishers will continue to optimize toward them until something changes (which might be adblocking). This isn't a technical problem so much as business and politics.
However, the publishers these days *are pretty short on tech talent and mostly use off-the-shelf CMS systems like wordpress (which are already bad software) and then just layer on their plugins, themes, and ads to create the mess we have today. Again no easy way to solve that without talent either on the pub side or in the platforms themselves. Some progress being made here with things like facebook instant articles and medium.com hosting.
Overall, the web definitely has a cruft problem, but it's not really that bad considering all the various channels of information access, and it's all slowly getting better.
That's a commonsense assumption that, in my understanding, used to be true. But the article goes to great lengths to point out that it isn't true anymore. Some of the bloated multi-megabyte examples don't include any media at all.
If you look at what the unblocked version pulls in, it’s not just videos and banner ads, but file after file of javascript. Every beacon, tracker and sharing button has its own collection of scripts that it needs to fetch from a third-party server.
The javascript alone in "Leeds Hospital Bosses Apologise after Curry and Crumble On The Same Plate" is longer than Remembrance of Things Past.
There are lots of bloated and slow ad networks. It's not that they couldnt make faster tech but that it's not a priority. Same with publishers who don't have enough skills/resources to get it done and would rather focus what little they have on making sure the site and ads work in the first place.
The rise and success of cruft-stripping-as-a-service offerings like Readability, Pocket, Instapaper, etc., seems to indicate that a not-insignificant segment of consumers think that a "decent UI" is _less_ UI.
Otherwise we've had RSS readers and "reader" mode for browsers for a long time but they dont have significant usage.
Simply having a consistent typography, font selection, size, and readable contrast is a huge benefit. Web design isn't the solution, Web design is the problem.
(And asstasstic browser defaults is another problem: why an absolutely unstyled page cannot be perfectly readable and acceptable is a huge flaw. I blame the browser vendors and W3C for this.)
A tool which manages a large written archive is another hugely useful aspect. Tabs and bookmarking both suck.
Also: best I can tell, Readability seem to have died so far as any visible development or company activity goes. There's been none in years, though the service itself works for now. I'm in the process of moving 2000 articles to Pocket (Instapaper lacks necessary features IMO).
It's worth noting that Pinboard.io itself addresses some of these needs.
One of my computers is a netbook-ish Lenovo x131e from a few years ago. It runs everything I need it to very well, except for web browsing in Firefox. Many pages cause the browser to completely choke for a few seconds while the JavaScript does its thing.
I finally broke down and installed NoScript and it feels like I'm browsing the web on a brand new computer! Pages load fast and render quickly. If JavaScript is required, I can enable it on a site-by-site basis. There's also the privacy and security benefits, but my main issue was performance.
I used to think that people who browse with JavaScript disabled were being silly, but now I understand why someone would want to do that.
I know that part of the problem is Firefox and part of it is the under-powered computer. Browsing the same sites in Safari on a 6-year-old MacBook Pro isn't nearly as painful and, generally speaking, I leave the JavaScript alone on that computer.
But I agree, JS is a huge issue... I notice it most on click-bait type sites on my cell phone. It's really pretty sad, all things considered.
For the sake of fairness, the rough specs are:
The ThinkPad:
* Lenovo ThinkPad x131e, 11.6", purchased late 2013 * Core i3-3277U processor * 8GB RAM (aftermarket upgrade) * 500GB spinny drive * OpenSUSE Leap 42.1 * Embedded graphics * Firefox browser
The MacBook Pro:
* Mid-2010 MacBook Pro 15" * Core i7 - dual core, not sure which model * 8GB RAM (aftermarket upgrade) * 512GB SSD (aftermarket upgrade) * MacOS 10.11.4 * Embedded and discrete graphics * Safari browser
So yeah, it's hardly an apples-to-apples comparison.
I'm glad to hear Google are planning to label slow sites. We need this. Bloated websites need to be held accountable.
On mobile devices too, we need a browser option to stop loading any further data for a given site after a defined point. So if the browser has received 3 megabytes of a page so far, it stops and asks the user whether to continue with downloading. It might say how many cents this one website has cost them so far (if the user has setup this feature).
Fair enough "modern web, modern features" but most of the modern features we enjoy are improvements to browsers, servers and javascript. There's no reason why this can't mean keeping page size steady while enjoying new features.
It's pretty bad in a lot of ways.
Yes I agree some websites do really need to go on a diet, loading unused css, js and multimedia has to be removed, but 1-2MB is not a reason anyone should be throwing their hands in air screaming CRISIS!! Definitely I would applaud anyone who would spend their time optimising their websites to be as small as they can be, but Jesus Christ 2BM and we have a crisis... no way!
I for one think this is a sign we are making progress a very good thing, we are improving as a community and we are getting more out of our web.
If a web site is no longer readable because it layouts every 2 seconds to accommodate 145 ads, it does not have more functionality; it has less.
Yes, Adblockers to the rescue. But you know, Apple doesn't support Adblockers on an iPhone 5 for whatever stupid reason.
I think we should be complaining about developers and admins who doesn't enable gzipping, we should be angry with the fact some websites don't even bother setting headers to cache static resources. We should not be throwing out hands up in air screaming crisis because our web is becoming more useful.
You're forgetting that mobile devices quickly run out of cache memory. This includes iPads. You might visit a news site once every few days, but quite often the same resources need downloading again and again because your iPad has not kept them in cache memory because it ran out already. Desktop browsers have a lot more capacity to keep web resources cached.
Not only that, but RAM memory is also limited on mobile devices. Forget about expecting multiple websites to remain in memory across numerous tabs. My iPad3 can pretty much handle only one tab open. If I switch tabs to another website, then switch back, the whole page loads again. A less bloated web would help this issue.
And then there's accessibility for low-speed areas. Did you even read the article?
Optimizing images is a pretty huge thing, as is enabling gz compression on the streams... these two alone add up to far more saving than setting cache headers, not that they can't or shouldn't be set.
Also since when exactly did websites have a mandate to economise to the scale of mobile data? It's always been edge case unless you are specifically targeting that.
See, what this boils down to is this: People use Adblockers, because they're tired of all that shit that's consuming their bandwidth (at least on mobile). Content publishers complain about people using Adblockers. But they're not willing to get the technical side of their content consumption platform right in order to accommodate their very visitors. They cry foul but are part of the problem obviously.
Unfortunately, I don't get to see what links to avoid (size-wise) before I download all the bloat and waste my bandwidth.
The growth of website size has been fairly steady, if anything the growth has flattened over the last year or so. It is up to the infrastructure to keep up with that.
In the last year or two we've had the introduction 4G with 2-4 times the speed of 3G and you expect to have the same usage allowance?
You should expect to have to increase you dataplan every few years (because technology) whether that cost is absorbed by you or your phone company is a conversation to have with them.
Trends towards mobile-first have been a thing for a while. Especially in developing countries where mobile users outweigh desktop users.
Targeting desktop is slowly becoming the edge case for anything targeting a mass audience. Look at a lot of the recent high-value tech companies. Do Uber/Snapchat/Whatsapp/Instagram target desktop or mobile first?
Where are users in general spending the majority of their time? On a desktop/laptop, or on a phone/tablet?
Users, regardless of device used, are primarily on wifi and that is what is designed for. In modern countries most users don't really have data restrictions low enough to come into effect through websites so going into the future this will not be a problem.
Apart from laziness there is no reason for those websites to be so large.
Sure there's always room for an amount of optimization and good practice but it's insane to rely on that instead of fixing the problem. The growth in page size has been fairly linear and predictable.
The real headline here should be "German and US carriers cannot keep up with natural growth in technology"
You make it sound as if the natural growth in technology is what makes these websites huge. I run a web app, which is uptodate technology-wise. It has a responsive design with @2x images and @3x. It uses JS in a sensible manner. It's fast and easy to use. Top notch technology. Yet, the average request sums up to 200KB. And 60KB of that is a custom font.
This is not about the natural growth in technology, it is about 50-70% of the 2MB are entirely worthless to the user, because they are usually Ads, trackers, wrongly compressed images (ImageOptim does wonders here) and using 10 JS frameworks in parallel.
It's almost as if you're saying: See, img tags now support the width attribute, so let's upload a 10MB photo and just tell the browser to resize it to 100px, because technology.
So I go with a "those in glass houses" approach:
The only reason I can't see the terrible quality of your website's photos on my phone is that all the content is so damn small and zoomed out I can barely make out the text never-mind the picture pixels. I don't really want to zoom in because the shade of lime green you've chosen is so jarring it'll likely give me a migraine if it fills the screen.
I'm in the UK and the only network offering unlimited data is so slow you'll struggle to use more than 3GB in a month.
I've since given in and just paying through the nose for 16GB/month, so that I can not have to watch my data usage. (Un?)fortunately, the network is so fast I've found my data usage is already around 9-10GB/month, so I'm going to have to start watching that again soon.
https://medium.com/@tubikstudio/ui-animation-microinteractio...
Aside from the fact that it's impressive to make flat-styled animations that big in gif form, I think the people behind medium.com are just as much to blame for not giving feedback to the uploader about the size of the attached images, nor offering a non-destructive optimising pass or serving the gifs reencoded as .WebM for browsers that support it.
Not to mention that their sentiment is unoriginal by a factor of possibly a decade.
Well, the article disagrees that this is always what is going on, for example:
> Here's the PayPal website as it looks today. The biggest element on the page is an icon chastising me that I haven't told PayPal what I look like. Next to that is a useless offer to 'download the app', and then an offer for a credit card. I can no longer control the sort order, there are no filter tools, and you see there are far fewer entries visible without scrolling.
and
> 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. Interface elements are big and chunky. Any hint of complexity has been pushed deep into some sub-hamburger.
Of course many things improved, today you can make more with less, a lot more. But all of that can easily be undone by just piling on a bunch of hires stock photographs or even video, 20 ad networks and 5 tracking scripts. And one might also to consider the memory footprint and CPU usage of multiple open tabs, and how leet efficient pages and bloated crap alike get put into the browser cache which is of finite size and flushes out older things to make room. Then multiply that by number of visitors. Crisis or not, it's a LOT of waste if you really think it through.
What functionality do you have in mind when you're talking about the average read-only news-article type of web page?
I often react very positively when websites are super-fast today. Especially on a mobile device, it is worth a lot to me.
These Apple sites exemplify what I call Chickenshit Minimalism. It's the prevailing design aesthetic of today's web.
"Chickenshit Minimalism: the illusion of simplicity backed by megabytes of cruft."
Built a scraper and converted it to something using Markdown in a weekend, I barely used any of previous dev's "code."
Sometimes all you need to dig a hole is a shovel.
We need a bandwidth @media selector (that is kept up to date with recent conditions by the browser).
We need optional (viewport conditioned) lazy loading built into the spec.
It's time for these features to become part of the web stack, but maybe we need a codified mediaQuery.js first.
Someone in another thread suggested to colorize the address bar based on bytes transferred and/or requests made. Maybe it'll wake people up if they visit a website and it has some nice dark red color to show how much bandwidth is wasted.
I'm talking about improving those lightweight and beautiful websites even further. I implement some of those features on every project, to deliver the maximum content & experience quality in every network and device condition possible.
You can't seriously try to shoe-horn the entire platform into whatever your vision of beauty is. Please keep an open mind about a complex future medium, that can effectively accommodate Netflix, YouTube, Facebook, Wikipedia, Photoshop, Open Office, Google Maps, Skype, Auto CAD, Grand Theft Auto VR, ...
The NPR page about ad-blockers which was 12 megabytes without an adblocker and 1 megabyte when using an adblocker is now 1.4MB with an adblocker and "only" 1.9MB without -- to display about 1,100 words.
The medium article that was over a megabyte seems to have removed the pointless 0.9MB invisible image.
Something that compiles and runs java applications in pure JS is bound to use up a shit-ton of bandwidth.
One look at the function would cause severe ingestion in most people.
A really bad example to use for bloated pages.
That said, I was able to boilerplate Preact + Redux for creation of a control that will be used stand-alone and the payload is about 16k of JS (min+gz), and under 1k of CSS [1]. The methodology I used could very well be carried to more "full" applications. There's very little reason most modern web applications can't be way under 500kb payload (excluding images). In this case I wanted more modern tooling, workflow, but a fairly light datepicker modal... I feel most datepickers suck. Could it be lighter? yes[1], but I wanted a little bit of a different approach. In the end it works...
All of that said, the biggest points of code bloat are usually in bringing in an entire library instead of only the pieces needed, especially bad with UI controls... I really wish more people would use/extend bootstrap from source here. It's really easy to do... usually I copy the variables file, copy the bootstrap base file, create a mixins file, and then update all the references in the copied base. From there, I can comment out/in as needed, and be fairly light.
Of course, fonts are another source of bloat, I'd suggest people start leaning towards using svg resources embedded in JS strings, and only those icons needed... all modern browsers support svg well enough in this case. Other web fonts should be limited to 2-3 includes of 1-2 families... that's it. Any more and your design is flawed anyway.
With webpack + babel, it isn't so hard to keep your applications structured, and much more minimal.
[1] https://github.com/tracker1/md-datepicker [2] https://dbushell.github.io/Pikaday/
In my experience, most site slowness is related to slow loading ads. Since installing an ad blocker a few months ago, I really haven't had any complaints about web speed.
For my website (chemical databank) I was able to measure the benefits of reducing the page size with more visitors from countries with poor Internet connectivity.
So, just do it and enjoy the competitive advantage as long as you have it! This is the best way to get things moving.
http://www.httparchive.org/interesting.php?a=All&l=Apr%201%2...
Average of 2.3MB with 60% of that being images. 50% of that content can be cached for a least a day.
The right size for a web page depends less on the opinion of random developers, and more on the website's owners and users.
I think we're somewhere similar with the web. Internet is plentiful enough that we don't need to scrape and squeeze every last kilobyte. Maybe medium takes 3mb to render a simple plain page. That's ok.
(I do wish a lot of sites would up their information density though. Above all I wish I could get a full-width page, not a phone-width segment down the middle of my widescreen display. At home I've started using a stylesheet that disables max-width on all elements, and I've yet to see a site that looks worse that way)
For you and I, perhaps. For the people on 2G/3G or worse, trying to read a simple article, modern web pages are hilariously heavy. The whole point of the web was openness. This is why Facebook, Apple and Google have all developed their own solutions to this problem: FB Instant Articles; iOS News app; Google Accelerated Mobile Pages.
If these companies are taking it seriously enough to develop solutions, there must be a real problem or serious sections of the market being missed/obstructed by the failure of publishers to build their websites responsibly.
And in general, no matter that heavy pages can still load quickly for me on my privileged broadband connection, it still pisses me off when it takes 3-5 seconds for a page to load when I know it should fundamentally take a second (or less) to show me text and some associated images whenever they're in the viewport.
Google AMP is the best solution for the web so far, but it's a step backwards to XHTML/WAP and mobile subdomain sites. The correct thing would have been to hit websites with genuine SEO penalties for shit mobile performance. This is especially true because AMP doesn't even work on older mobile browsers.
The biggest reason why the web needs to care about every single byte of overhead? Because native apps barely have this problem. Neither side, native or web, is going to simply be killed by this, but the value of websites and web apps will decrease if they do not prove to be viable vehicles for content.
Layout frameworks (eg Bootstrap) tackle the problem of developing a site that's readable at resolutions from 320px wide on a two year old phone up to a 5K iMac. That is not a trivial task, especially if you need UI components.
Application frameworks (eg Angular) make it much faster, and consequently a nicer experience, to maintain user state, load content, navigate around template driven pages, etc.
Media content has grown with resolutions and pixel densities. 10 years ago we were looking at websites on 1280x1024 displays, with no rich media. Today a consumer facing website has retina quality video. That's going to impact the page weight.
Being wasteful is a minor problem; everyone has fast broadband. Everything is cached at various layers from the browser to the service worker to the CDN to the origin server. Browsers are really fast. With some clever "cutting-edge-even-though-its-been-around-for-years" stuff like http2 you can fetch things in parallel.
Obviously websites should be optimised. No one should be downloading media or libraries that aren't used. Animations should be hardware accelerated. Sites shouldn't be running in debug mode (ahemAngularJSahem). But all in all, what we get in a browser these days is far better, far faster, and far more functional than websites were a decade ago. We could go back to the "works without JS, stateless on the clientside, roundtrip to the server and a whole new page for every click" world I learnt web development in, but I really don't want to. It was rubbish.
Firstly, there is no such thing as "retina quality video". If you mean 4K, then say 4K. "Retina" is Apple marketing spin for their high density displays that you seem to be using to describe a standard of video. More to the point, websites are not pre-loading 4K video that is counted towards page weight.
To your claims about needing bootstrap for presenting a page on small to large screens. There are numerous easy methods for making a site readable on small and large screens that don't require shoving layout frameworks in and relying on them to make things look good. Learn HTML. Learn CSS.
> "Being wasteful is a minor problem"
That statement would be great as an ironic t-shirt, but otherwise is yet another facepalm.
> "everyone has fast broadband"
Great news. With that assumption out of the way, we can get on with pre-loading retina video and throwing page-weight caution to the wind.
> "Everything is cached"
The utopian world you live in sounds great, but mobile devices are known to be very bad at both long term resource caching and short term memory caching - as in multiple open browser tabs.
The point of the article is that even basic articles are bloated whales that waste precious bandwidth on mobile. On desktop, common sense design is replaced with "touch friendly mobile-first impressionism" for actually less accessibility. When spinning globe videos and 2000 pixel auto-playing slideshow presentations in a vast landscape with hamburger menu in corner is considered the "modern web", we need to take a hard look at what modern should be.
The improved functionality you're talking about does not need to mean bloat or excessive amounts of data to drive simple things on websites.
I don't mean 4K. I mean transcoding video assets to specific resolutions that match the website's responsive breakpoints, with 2X resolution versions for high pixel density displays (eg retina). Pushing a 4K video down to someone whose browser viewport is 800px wide is the sort of wastefulness people complain about.
Streaming video quality might be dynamically adjusted according to client bandwidth, but the topic here is unreasonable page weight and bloat. Streaming media has nothing to do with page weight.
I think I see the point you were trying to make though. Our devices have larger screens and more pixels, so fill every last one of those pixels up to the max with content, and then some. Many marketing and advertising folks would agree with you, while many developers are scratching their heads wondering why they just built a "chicken shit minimalist" website. Beer and a paycheck dissolves the care factor.
Displaying information readably has been solved by HTML for twenty years. It may not be pretty, but it will be readable.
> Application frameworks (eg Angular) make it much faster, and consequently a nicer experience, to maintain user state, load content, navigate around template driven pages, etc.
You know what's a better way to maintain state? HATEOAS. And there are no client-side libraries involved!
You know what's a better way to load content? Letting the highly-optimized browser do it!
You what's a better way to navigate around a page? Don't take over my space bar and cursor keys, and let me use my browser to browse!
I would add to this that you can make it pretty with less than 1k of css. You can make it REALLY pretty, and mobile ready as well. The fact that so few people in my profession know how to do so saddens me deeply.