"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"
Better late than never in discovering their sites' UX problem.
> 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.
- 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:
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.
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."
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:
maybe the author
maybe the created and updated dates
obviously, the content.
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.
- 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.
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?
> 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
Websites with a comfortable reading experience on the phone - Jul 28, 2016
Tt post about article design - mon, sep 8 and tue, sep 9, 2015 - Sep 09, 2015
How Development Seed builds websites - Sep 17, 2016
2015 posts about web page bloat - Jul 12, 2016