You're viewing old version number 3. - Current version

5 min

Tt post about web page bloat - mar 7, 2016

"BTW - some of the sites most laden with pop-up, banner, Flash, and stealth ads are newspaper sites. Even the New York Times and the Washington Post are so full of slow-loading commercial bloat that they are almost worthless to visit."

Oh man, I could launch into a days-long tirade about the massive bloat of websites, but I'll hold back. A little.

Single article "pages" can be several megabytes in size. And the UI/UX can be incredibly clunky. The media sites can bog down older machines because pounds of useless JavaScript, trackers, etc. get downloaded.

JavaScript is not the problem. The misuse and abuse of JavaScript is the problem. Media orgs have created reader-hostile websites.

historymike, disable JavaScript in your browser for ALL websites, including Toledo Talk, and note how much faster websites respond, especially professional media sites. Yes, some sites will be broken and won't display any content. Some will display images in strange ways. But for most sites, the text content should display okay, and the entire page will load fast.


For the curious, you can test web pages by entering URLs into http://www.webpagetest.org

This thread through historymike's comment loads too slow and is too fat for me. Here are the webpagetest.org results for the first part of this thread:

Fully Loaded:

  • Time: 1.935s
  • Request: 13
  • Bytes In: 195 KB
  • Cost: $

I could trim it down by minifying HTML and CSS content. I could eliminate the JavaScript that's used to display the menu across the top when viewing the site on a small screen or when the browser is resized.


For a comparison, here are the webpagetest.org results for yesterday's humorous Blade op-ed.

http://www.toledoblade.com/Featured-Editorial-Home/2016/03/06/Yes-on-Toledo-tax.html

Check these numbers out for loading a single op-ed.

Fully Loaded:

  • Time: 44.201s
  • Request: 952
  • Bytes In: 5,018 KB
  • Cost: $$$$$

A single page makes 952 requests and ends up being 5 megabytes in size. Holy hell. Media orgs are conducting a war on the web. That's probably why every damn site wants us to download fat-ass apps to our mobile devices.


I've created other websites for myself, and when I create or update a page, I store a copy into a caching server, which enables it to be served faster. But creating static HTML files with minimal assets can be faster still.


I'm always on the lookout for others who share my disgust with websites today.

October 2015 post: http://idlewords.com/talks/website_obesity.htm

Let me start by saying that beautiful websites come in all sizes and page weights. I love big websites packed with images. I love high-resolution video. I love sprawling Javascript experiments or well-designed web apps.

This talk isn't about any of those. It's about mostly-text sites that, for unfathomable reasons, are growing bigger with every passing year.

Here’s an article on GigaOm from 2012 titled "The Growing Epidemic of Page Bloat". It warns that the average web page is over a megabyte in size. The article itself is 1.8 megabytes long.

Here's an almost identical article from the same website two years later, called “The Overweight Web". This article warns that average page size is approaching 2 megabytes. That article is 3 megabytes long.

... consider this 400-word-long Medium article on bloat, which includes the sentence:

"Teams that don’t understand who they’re building for, and why, are prone to make bloated products."

The Medium team has somehow made this nugget of thought require 1.2 megabytes.

That's longer than Crime and Punishment, Dostoyevsky’s psychological thriller about an impoverished student who fills his head with thoughts of Napoleon and talks himself into murdering an elderly money lender.

And so on with that post.


Excellent post from May 2015

https://www.baldurbjarnason.com/notes/media-websites-vs-facebook/

The web doesn’t suck. Your websites suck.

All of your websites suck.

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken.

You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.

The lousy performance of your websites becomes a defensive moat around Facebook.

The web is capable of impressive performance and offers a dramatically vaster reach and accessibility than anything an app can offer.

The web is not the problem. Mobile web is not the problem. Mobile web browsers are not the problem.

100 percent of the problem belongs to website owners.


And just yesterday, I saw this post.

https://eev.ee/blog/2016/03/06/maybe-we-could-tone-down-the-javascript/

Do web developers actually use web browsers?

I also use NoScript, so I’ve seen some other bizarre decisions leak through on sites I’ve visited for the first time. Blank white pages are common, of course.

For quite a while, articles on Time’s site loaded perfectly fine without script, except that they wouldn’t scroll — the entire page had a overflow: hidden; that was removed by script for reasons I can’t begin to fathom.

Vox articles also load fine, except that every image is preceded by an entire screen height’s worth of empty space.

Some particularly bad enterprise sites are a mess of overlapping blocks of text; I guess they gave up on CSS and implemented their layout in JavaScript.

There’s no good reason for any of this. These aren’t cutting-edge interactive applications; they’re pages with text on them. We used to print those on paper, but as soon as we made the leap to computers, it became impossible to put words on a screen without executing several megabytes of custom junk?

Way to go, historymike. You got me cranky.

Disable JavaScript.

From JR's : articles
936 words - 5932 chars - 5 min read
created on
updated on - #
source - versions



A     A     A     A     A

© 2013-2017 JotHut - Online notebook

current date: Nov 19, 2024 - 9:24 a.m. EST