Web page bloat links - july 2016

http://www.npr.org/sections/thisisnpr/2015/10/27/451147757/npr-org-now-twice-as-fast
https://www.designernews.co/stories/58223-nprorg-now-twice-as-fast

http://digiday.com/publishers/washington-post-cut-page-load-time-85-percent/

http://tantek.com/2015/069/t1/js-dr-javascript-required-dead

http://www.webperformancetoday.com/2014/02/25/the-great-web-slowdown-infographic/

https://www.igvita.com/2016/01/12/the-average-page-is-a-myth/

http://mattgemmell.com/the-reader-hostile-web/

https://timkadlec.com/2015/05/choosing-performance/

http://daringfireball.net/2015/05/facebook_instant_articles

https://500ish.com/facebook-instant-karma-4a4bd4f3eca?gi=5cf41ca63561

---

https://medium.com/@sophie_paxtonUX/stop-gratuitous-ui-animation-9ece9aa9eb97#.2mnswhkkm

https://stratechery.com/2015/why-web-pages-suck/
https://news.ycombinator.com/item?id=9891927

http://blog.venanti.us/web-app-2015/
https://news.ycombinator.com/item?id=9865338

https://www.filamentgroup.com/lab/weight-wait.html

http://developer.telerik.com/featured/whats-wrong-with-the-web/

http://product.voxmedia.com/2015/7/22/9013731/we-design-websites-not-mobile-sites

http://digiday.com/publishers/gq-com-cut-page-load-time-80-percent/

http://www.web-crunch.com/stop-it/

Gee, what a shock that bloated, slow-loading websites that get trimmed end up loading faster. It's not only annoying ads. Simply disable JavaScript, which reduces the desired function of the site, but such an action increases the speed of the site.

"Tests of top 50 news sites with three ad-blockers on iPhone show significant decrease in load times for many sites, modest increase in battery life"

http://mediagazer.com/151001/p7#a151001p7

http://www.nytimes.com/2015/10/01/technology/personaltech/ad-blockers-mobile-iphone-browsers.html?_r=0

What's sad and somewhat bizarre is that people are surprised at the page load speed of a single article page when ads and JavaScript are disabled.

Better late than never in discovering their sites' UX problem.

http://pxlnv.com/linklog/safari-content-blockers-shit-ass-websites/

https://news.ycombinator.com/item?id=9897306 http://developer.telerik.com/featured/the-webs-cruft-problem/

http://www.mondaynote.com/2015/07/20/20-home-pages-500-trackers-loaded-%E2%80%A8media-succumbs-to-monitoring-frenzy/

http://www.mondaynote.com/2015/07/13/news-sites-are-fatter-and-slower-than-ever/

http://arnoldit.com/wordpress/2015/07/14/page-load-speed-let-us-blame-those-in-suits/

http://adamsilver.io/articles/the-disadvantages-of-single-page-applications/

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

http://blog.venanti.us/web-app-2015/

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

https://www.designernews.co/stories/52124-web-design-trends-that-ruin-the-user-experience

https://stratechery.com/2015/why-web-pages-suck/ - https://news.ycombinator.com/item?id=9891927

> I think there's too much blame being placed on programmatic advertising. That's no excuse for 14MB pages, fixed position ads, trackers pinging the network for a full minute, etc.

http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html

http://chase-seibert.github.io/blog/2014/05/30/rich-client-side-web-apps-gone-too-far.html

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

---

• My thoughts:

Some people believe that Facebook's Instant Articles will further hurt the web. Maybe, but the web began getting damaged years ago with bloated web designs that created slow, clunky, horrible user experiences.

Media sites would have functioned better with a plain, vanilla 1995 look with bare bones HTML. Add a smattering of CSS with media queries, and it would be possible to create small, lightweight, fast-loading web pages in 2015 that are still comfortable to read.

......

I also don't care for the overuse of images on websites' homepages and irrelevant images on article pages. And huge images are unnecessary most of the time, since most readers are accessing the sites on phones.

Over the past few years, media sites have redesigned to be responsively designed in order to have one website that functions well on all devices. This is good. But unfortunately, many of these sites bog down older computers with too much code bloat. Single web pages are slow to load and have a size in the megs. Absurd.

And I don't understand why many responsively-designed websites display in such a tiny font size on phones. It's an uncomfortable reading experience. What numskull opined about the need for small font sizes on phones with responsive design?

My prefs for media homepages and article pages:

No JavaScript.
Minimal CSS if possible. This is hard to do.
Small images most of the time.
Useful images that are related to the article.
Homepage with a stream or feed view.
Don't break the back button or create an abnormal action with clicking the back button like taking me back to the top of the site instead of where I left off.
Don't break the right-click or open in a new tab function. This occurs way to often, and it's infuriating. Repulsive.
Don't break highlighting and copying text for excerpting.

Since 2012 or 2013, the web experience has grown increasingly frustrating, thanks to bloated, obnoxious designs caused by the misuse of JavaScript. It seems like website owners have intentionally created miserable web experiences across all screen sizes in order to convince people to use their native mobile apps.

I'm sure that the bad user experiences on newly-designed websites is unintentional. I'm guessing that many site owners, designers, and developers deploy what's currently popular because it uses cool technology even though the tech does not always improve the reading experience.

"The user experience sucks but that animation is cool." - pointy-haired media boss

I definitely prefer a browser-based open web, including on mobile, but when obnoxious web experiences are created, this leads to Facebook innovating something new to improve the user experience.

I don't blame Facebook. I blame other site owners for building bloated, clunky websites over the past few years.

"the open web isn't well-suited for mobile devices"

"The mobile web is tough to navigate."

True for poorly-designed websites. Bloated and clunky with unnecessary JavaScript.

For pleasantly designed websites that are kept simple, the web works well on mobile, and the mobile web is easy to navigate.

Simplify and make the experience comfortable. Focus on the individual article page. Strip it down to the bare parts or skeleton:

article header:
title
maybe the author
maybe the created and updated dates
article body:
obviously, the content.
article footer:
maybe the author
maybe the created and updated dates
maybe a way to contact the author
maybe a way to share the article
Nothing else is needed on the page, except for a "Home" link, located in the upper left or upper right corner of the page.

Use little to nothing in the web site footer area of the article page.

Save all of the website header, navigation, and footer info and links for the home page. Why repeat all the crap on the article pages?

Keep the article pages as lightweight and simple as possible. Let the negative space shine.

Embedded images and videos that are part of the article body will get loaded in more slowly than the text, but at least the text displays quickly, especially if the article page is pulled from cache.

But media sites add dozens of trackers and other "things" to a single article page. It's offensive.

---

Google's AMP project may be proof that websites have been overly engineered to a massive fault for too many years. And it may be proof that website owners have been more concerned with displaying new tech skills, instead of exhibiting empathy for the readers.

Site owners should create a humane web experience.

The delicious irony here. The horribly bloated and slow-loading Verge.com [published a story](http://www.theverge.com/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview) about Google speeding up the mobile web.

> Today, the company announced a technical preview for a system called Accelerated Mobile Pages (or AMP), designed to fight many of the factors slowing and bloating mobile web pages.

Google is trying to fix the problems created by website designers, developers, and probably the ever-present "stakeholders."

> If the system works, users should see lighter, faster-loading mobile web pages as a result.

Website owners can do this on their own by limiting or eliminating JavaScript exposure to the browsing-only users and reducing the amount of giant images that get downloaded. With some effort and common sense, you don't need help from Google to make websites load quickly on the mobile web.

http://babyutoledo.com :

• no javascript for the browsing-only user
• smallish images and few images per page
• pages are cached with memcached

I created babyutoledo.com for a local non-profit group to be simple and lightweight. The focus is on the content and the org's purpose. I wanted the reading experience to be comfortable for the users on any device.

I'm sure that I can do more to streamline the pages and CSS to speed up page download speed.

Some of my niche blog sites also use memcached.

Keep it simple and lightweight, and the pages load well on mobile.

I created this static page with no JavaScript as an example of what I would like to see produced by the Toledo Blade. I would pay a hefty digital subscription if I could get pages like this.

<http://toledotalk.com/last-alarm.html>

It's interesting that website owners may be thrilled to receive a solution to a problem that they created.

If you are smashing your left hand with a hammer that you are holding in your right hand, you should not be thrilled to receive some padding to protect your left hand while you continue to hammer away at it. Obviously, the smart thing to do would be to drop the hammer. And don't blame the hammer manufacturer for your ailing left hand.

Don't misuse technology to create a problem. Don't whine about the technology. And don't hope that someone creates new technology to solve the problem that you created.

Thanks to Google AMP, does this mean that website owners, designers, and developers can continue to create poor UX experiences because they can rely on other services to do the work that they refuse to do?

Brilliant analysis.

https://mobile.twitter.com/om/status/651759921990647808

> Publishers embracing Facebook, Google & Apple platforms are merely shining light on their own technical incompetence

---

The Web or the web is not slow. Browsers on desktops, laptops, tablets, and phones are not the problem.

Bloated, poorly designed websites are the problem. And publishers create them. These stunningly huge article pages bog down old computers and cause slow downloads.

The solution is to create simpler websites.

My test site that's using my new formatting app to create static html pages loads fast and works fine on desktop and phone.

My other sites also load fast because the Nginx web server pulls the homepages and the article pages from Memcached. And if the article page was not cached, then my code is accessed, which pulls the content from the MySQL or CouchDB database, and then the content is cached before or after it's sent to the user. A refresh retrieves the newly cached page. But when I create or update an article, that page is cached. Other stream views, such as page 2 and on and search results, are not cached.

Make the web faster? No. Make your websites leaner. Make your websites reader-friendly instead of reader-hostile.

Memcached and Redis are simple to implement and use. Does every article page need to contain dynamic elements? The answer is probably 'Yes', especially for all the tracking, advertising, and analytics crap that users must download.

---

Here's my [simplified version](http://toledotalk.com/yes-on-toledo-tax.html) of the op-ed, stored on the ToledoTalk.com server. (Obvious copyright violation to make a point) and the webpagetest.org [results](http://www.webpagetest.org/result/160721_SN_1J87/).

From: Dulles, VA - Chrome - Cable 7/21/2016, 4:59:45 PM

First View Fully Loaded:

• Time: 0.516s
• Requests: 2
• Bytes In: 14 KB
• Cost: $

ToledoTalk.com is hosted on a shared server at HE.net, meaning that TT shares a computer that also hosts dozens of other websites. Obviously, I don't have root access. I cannot enable compression within the Apache web server.

Apache at HE.net must be adding some additional info because that
boring web page is a little over 8,000 bytes in size on the file system, due to the HTML tags and some CSS.

---

Another webpagetest.org [test](http://www.webpagetest.org/result/160723_8H_TKG/) of the same, basic HTML page.

From: Dulles, VA - Chrome - Cable - 7/23/2016, 4:33:04 PM

First View Fully Loaded:

• Time: 0.337s

#web #design